Fix panic in GEOM on forced devfs unmount

[trasz]

Summary

Fix panic that would happen on forcibly unmounting devfs (note
that as it is now, devfs ignores MNT_FORCE anyway, so it needs
to be modified to trigger the panic) with consumers still opened.

[mav]

I am not sure it is a proper place for workaround. Rather then documenting bug of vgonel(9), it should better be fixed. IMHO it is pointless to call VOP_CLOSE() without flags same as VOP_OPEN().

[trasz]

Konstantin, do you see a way to do this in a better way? In particular, is there any way for vgonel() to somehow retrieve the original file open flags (eg FREAD), or doesn't it make any sense, since it operates at vnode level and not file level?

[kib]

In D3050#62312, @trasz wrote:

Konstantin, do you see a way to do this in a better way? In particular, is there any way for vgonel() to somehow retrieve the original file open flags (eg FREAD), or doesn't it make any sense, since it operates at vnode level and not file level?

It is not pointless to call VOP_CLOSE() there, but it is also impossible to provide read/write flags. VOP_CLOSE() is helpful for filesystems which track opens vs close, like NFSv4. On the other hand, indeed we have no idea about the amount of readers or writers, since this information is kept at the file, and not vnode, level.

Well, there is v_writecount information for the vnode, but it is not directly mapped to the w counter. And there is no way to recover the r.

BTW, in the context of this patch, it causes the leakage of the r/w/e counters, am I right ?

[mav]

In D3050#62365, @kib wrote:

BTW, in the context of this patch, it causes the leakage of the r/w/e counters, am I right ?

In GEOM close() with zero counter triggers assertion. With proposed patch it will be a NOP, i.e. cause a leak.

[trasz]

So, can anyone propose a better way? Otherwise I'd like to commit it as is.