Messages in this thread | | | Date | Wed, 28 Jan 2009 04:14:39 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH, RFC] Remove fasync() BKL usage, take 3325 |
| |
On 01/27, Andrew Morton wrote: > > On Fri, 23 Jan 2009 05:56:46 +0100 > Andi Kleen <andi@firstfloor.org> wrote: > > > On Thu, Jan 22, 2009 at 03:32:49PM -0500, Christoph Hellwig wrote: > > > On Thu, Jan 22, 2009 at 06:51:04AM -0800, Andrew Morton wrote: > > > > OK, replacing a lock_kernel() with a spin_lock(&global_lock) is pretty > > > > straightforwad. But it's really really sad. It basically leaves a great > > > > big FIXME in there. It'd be better to fix it. > > > > > > > > > Umm, we've been discussiong this in and out a guestimated million times. > > > > > > Let's go forward with Jon's patch which is on obvious improvement and > > > if it shows problems later on we can revisit it. > > > > The point was that we already have a better patch from Oleg. > > > > Where is this patch?
I didn't send the actual patch. The idea is,
can't we use O_LOCK_FLAGS bit? I agree, it is a bit ugly, and I won't insist if you don't like is.
static inline int try_lock_f_flags(struct file *file) { return !test_and_set_bit(O_LOCK_FLAGS, file->f_flags); }
static inline set_f_flags(struct file *file, unsigned int flags) { file->f_flags = flags & ~O_LOCK_FLAGS; }
Now, nobody should change ->f_flags directly (except create/open pathes. For example, ioctl_fionbio() should be changed:
if (try_lock_f_flags(filp)) { if (on) set_f_flags(filp, filp->f_flags | flag); else set_f_flags(filp, filp->f_flags & ~flag); }
If try_lock_f_flags() fails we do nothing, as if the current owner of O_LOCK_FLAGS changes ->f_flags after us.
and, from another message,
No need to disable preemption, we never spin waiting for the lock bit. If it is locked - somebody else updates ->f_flags, we can pretend it does this after us. This can confuse F_GETFL after F_SETFL (if F_SETFL "fails"), but I think in that case user-space is wrong anyway, it must not do F_GETFL in parallel.
I'll try to make the patch tomorrow, but the problem is that I am not sure this is not too ugly. At least Jonathan dislikes this approach, and I do understand him ;)
Oleg.
| |