Date: Tue, 12 Feb 2019 01:33:40 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: "freebsd-arch@freebsd.org" <arch@freebsd.org>, "cem@freebsd.org" <cem@freebsd.org> Subject: Re: What to do about VOP_INACTIVE? Message-ID: <QB1PR01MB353763DA398D1089E162CB3DDD650@QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAG6CVpU8J=G8za8W2uan8SAGEbe4PD=SXwMow=E_mkJnMGB96A@mail.gmail.com> References: <CAG6CVpU8J=G8za8W2uan8SAGEbe4PD=SXwMow=E_mkJnMGB96A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Conrad Meyer wrote: >The nominal return type of the VOP_INACTIVE vnode method is 'int', but >in practice any error returned is silently discarded. > >The only caller is vinactive(), which is also a void routine. >vinactive ignores the return value of VOP_INACTIVE(). (vinactive >tends to be called by other void routines, like vput(), so propagating >an error up the stack is non-trivial.) > >In practice, most filesystems in the kernel unconditionally return >zero for INACTIVE. The exceptions are: msdosfs, ext2fs, nandfs, and >(notably) ufs. > >The problem (as I see it) is that the return type makes it appear that >INACTIVE is allowed to fail, but it is not. One important >ramification of this is that interruptible sleeps in INACTIVE are >basically not permitted. > >This seems problematic because INACTIVE is invoked as part of >close(2), and we can potentially block that user process indefinitely >when the kernel filesystem is stalled on a network resource, or >something like a FUSE userspace filesystem (which can also access >network resources). > >Can we live with the current behavior (INACTIVE cannot fail)? In that >case, I think we should change its return type to void to match. > >Thoughts? Well Kostik is the expert, but my understanding is that a file system canno= t assume that VOP_INACTIVE() will actually be called for a vnode. As such, th= e file system needs to do anything it does in its VOP_INACTIVE() in its VOP_R= ECLAIM() as well, if it must be done before the vnode is reused. As such, a failed VOP_INACTIVE() doesn't seem to be meaningful, since it mi= ght not get called at all? Having said that, making sure file system implementors know the above seems more important than whether it returns int vs void. (ie. Returning 0 seems harmless to me and may be useful in the future. Sinc= e changing the VFS/VOP interface can only be done for major releases and req= uires all file systems to be changed, I leave it, but this is not a strong opini= on.) rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?QB1PR01MB353763DA398D1089E162CB3DDD650>