[lkml]   [2011]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Important for fs devs: rcu-walk merged upstream
    On Sat, 8 Jan 2011, Nick Piggin wrote:
    > The vfs-scale branch is now upstream. If you haven't
    > looked yet, your filesystem is likely to have been
    > touched, so check it out.
    > Also look at Documentation/filesystems/porting and
    > path-lookup.txt.
    > The dcache_lock stuff should have been all done for you
    > (for in-tree filesystems, I can help out of tree fses with
    > conversions there if you ping me offline).
    > The rcu-walk stuff can be more tricky for your filesystem
    > to take advantage of.
    > If you supply a .d_revalidate, .permission, or .check_acl,
    > then path walking is going to be slow and unscalable for
    > you.
    > Out of tree filesystems: you _have_ to at least add a line
    > of code to the above functions in order to specify that
    > you don't want to participate in rcu-walk.
    > Otherwise, you don't have to care about rcu-walk if you
    > have a legacy or special filesystem like configfs then I'd
    > advise against anything fancy. But if you have a
    > userbase and you expect them to actually do any path
    > lookups into your filesystem, please take a look.

    One other thing: I know ECHILD is safe since no sane filesystem will
    return it in its permission or revalidate callbacks, and even if it
    does that's just a loss of optimization.

    But it would be better from a readability and grepability standpoint
    if it was a kernel internal errno (ERESTARTNORCU or whatever)
    similarly to ERESTARTSYS and the like.


     \ /
      Last update: 2011-01-13 16:01    [W:0.019 / U:12.516 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site