Thread (1 message) 1 message, 1 author, 2015-09-11

Re: [PATCH v4 03/16] fs: allow __fput_sync to be used by non-kthreads and in modules

From: Al Viro <viro@ZenIV.linux.org.uk>
Date: 2015-09-11 14:00:49
Also in: linux-fsdevel

On Fri, Sep 11, 2015 at 06:54:29AM -0400, Jeff Layton wrote:
We want nfsd to keep a cache of open files, but that would potentially
block userland callers from obtaining leases on them. To fix this,
we'll be adding a new notifier chain to the lease code that will call
back into nfsd on any attempt to set a FL_LEASE. nfsd can then close
any open files for that inode in advance of that.

The problem however is that since that notifier will run in normal
process context, the final __fput will be delayed a'la task_work and we
are still unable to set a lease. What we need to do is to put the struct
file synchronously so that the __fput runs before returning from the
notifier call.

The comments over __fput_sync and the BUG_ON in there mandate that it
should only be used in kthread context, but I see no reason why that
should be so. As long as the caller avoids holding locks that may be
problematic, it should be OK to use it from normal process context as
well.

Remove the __ prefix and the BUG_ON from that function and update the
comments over it. Also export it so that it can be used from nfsd code,
and move the export of fput just below the function definition.
I really don't like that.
	a) how deep in kernel stack will that thing run?
	b) what locking environment is expected in your case?

And opening it for use by any random driver that just feels like e.g.
using it to go parse its config over there in /lib/we/are/special/wank.conf
with 5Kb worth of kernel stack already eaten is a really bad idea.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help