[lkml]   [2009]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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 <> 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);
    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 ;)


     \ /
      Last update: 2009-01-28 04:19    [W:0.025 / U:0.944 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site