Date: Thu, 14 Feb 2019 20:35:25 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Conrad Meyer <cem@freebsd.org> Cc: "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: RFC: What to do about VOP_INACTIVE? Message-ID: <20190214183525.GK24863@kib.kiev.ua> In-Reply-To: <CAG6CVpVjfTBH_=ctM=ck1q5Yw8J7CVpViQ=2DEinjgw2CZzaOg@mail.gmail.com> References: <CAG6CVpU8J=G8za8W2uan8SAGEbe4PD=SXwMow=E_mkJnMGB96A@mail.gmail.com> <20190212071929.GB24863@kib.kiev.ua> <CAG6CVpVjfTBH_=ctM=ck1q5Yw8J7CVpViQ=2DEinjgw2CZzaOg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 14, 2019 at 09:50:55AM -0800, Conrad Meyer wrote: > 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. VFS does not guarantee that VOP_INACTIVE is always called when the use count reaches zero. Look e.g. at vputx() where we only call the inactive method when we were able to upgrade to exclusive lock, and look at vget() where we only call it when we locked exclusive. In other words, the reclaim method of a filesystem must be prepared to do the work, it is typically done by calling internal inactivation function from VOP_RECLAIM. > > > 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?20190214183525.GK24863>