Date: Thu, 14 Feb 2019 09:50:55 -0800 From: Conrad Meyer <cem@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: RFC: What to do about VOP_INACTIVE? Message-ID: <CAG6CVpVjfTBH_=ctM=ck1q5Yw8J7CVpViQ=2DEinjgw2CZzaOg@mail.gmail.com> In-Reply-To: <20190212071929.GB24863@kib.kiev.ua> References: <CAG6CVpU8J=G8za8W2uan8SAGEbe4PD=SXwMow=E_mkJnMGB96A@mail.gmail.com> <20190212071929.GB24863@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Konstantin, On Mon, Feb 11, 2019 at 11:19 PM Konstantin Belousov <kostikbel@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpVjfTBH_=ctM=ck1q5Yw8J7CVpViQ=2DEinjgw2CZzaOg>