lkml.org 
[lkml]   [2009]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH, RFC] Remove fasync() BKL usage, take 3325
    On Thu, 22 Jan 2009 06:51:04 -0800
    Andrew Morton <akpm@linux-foundation.org> 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.
    >
    > We don't have a handy lock in struct file which could be borrowed.

    Yeah, I noticed that too.

    > - We could add one

    The problem there is that this bloats struct file, and that seemed like
    something worth avoiding. It could easily be done, but I don't know
    why we would before knowing that the global spinlock is a problem.

    But... it's *already* protected by a global spinlock (the BKL) which is
    (still) more widely used.

    > - We could borrow file->f_path.dentry->d_inode->i_lock

    I didn't think of that one. Using a lock which is three indirections
    away seems a little obscure; again, I guess we could do that if the
    global spinlock actually turns out to be a problem.

    > - We could convert that field to long and use bitops (sounds nice?)

    I did think of that one. Reasons not to include growing struct file
    and the fact that there are places which set more than one flag at
    once. So we'd replace assignments with loops - and we still don't
    solve the fasync() problem.

    So that was my thinking.

    I'll address your other comments when I get back home.

    Thanks,

    jon


    \
     
     \ /
      Last update: 2009-01-23 06:17    [W:5.993 / U:0.192 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site