[lkml]   [2009]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH, RFC] Remove fasync() BKL usage, take 3325
    > On Thu, 22 Jan 2009 22:15:00 -0700 Jonathan Corbet <> wrote:
    > On Thu, 22 Jan 2009 06:51:04 -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.
    > >
    > > 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.

    Not a big deal, really. There's one of these for each presently-open file.
    It's not like dentries and inodes, which we cache after userspace has
    closed off the file handles.

    > 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.

    I don't know what "the fasync() problem" is?

     \ /
      Last update: 2009-01-23 06:35    [W:0.036 / U:40.292 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site