RFC: What to do about VOP_INACTIVE?

[Conrad Meyer]

Hi Konstantin,

On Mon, Feb 11, 2019 at 11:19 PM Konstantin Belousov
<kostikbel at gmail.com> wrote:
> Our close(2) always removes the file descriptor from the process table,
> regardless of the error returned, except for the EBADF situation.
> Due to this, if some filesystem like FUSE have to stop executing its
> VOP_INACTIVE due to signal, it does not change anything for the caller.

Sure.  Does it violate any contract that the kernel relies upon?  For
example, vgonel() will issue a VOP_INACTIVE() followed by
VOP_RECLAIM(); I guess this means filesystems with interruptible
INACTIVE cannot rely upon RECLAIMed vnodes being inactivated first.

> On the other hand, allowing unbound interruptible sleeps in the
> implementation of inactive or reclaim is very dangerous practice, since
> executing the VOPs on the vnode reclamation from VFS daemons would stop
> free vnode supply to the system, effectively blocking it.  In less
> dangerous situation, it would block unmount.

This is a good concern.  Even bounding sleep to some plausible time
per individual vnode would drastically restrict VFS daemons' ability
to process many vnodes in a timely fashion.  And eliminating sleeps or
bounding them to very short times may be undesirable the majority of
the time (userspace close).

I don't know what the best way to fix this is.  We could plumb a flag
argument down to INACTIVE and RECLAIM methods.  On the other hand, we
already have the 'td' argument.  Maybe that is a sufficient for VOP
methods to determine whether the caller is userspace or a kernel
daemon.

Either way, vinactive() and callers will not make any use of an EAGAIN
signal, so why have the 'int' return type?  It is misleading.

> I do not think that efforts to change VOP_INACTIVE() return type to void
> are worth the time.

It's trivial; I'm happy to do it.

Thanks,
Conrad