[lkml]   [2009]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] configfs: Silence lockdep on mkdir(), rmdir() and configfs_depend_item()
    Thank you both for keeping up on this.  I owe Louis some review that I'm
    going to try to get to.

    On Mon, Jan 26, 2009 at 03:55:36PM +0100, Louis Rilling wrote:
    > On 26/01/09 15:19 +0100, Peter Zijlstra wrote:
    > > On Mon, 2009-01-26 at 15:00 +0100, Louis Rilling wrote:
    > >
    > > > > Its not a locking correctness thing, but simply not being able to do it
    > > > > from the vfs calls because those assume locks held?
    > > > >
    > > > > Can't you simply punt the work to a worklet once you've created/removed
    > > > > the non-default group, which can be done from within the vfs callback ?
    > > >
    > > > I'm not sure to understand your suggestion. Is this:
    > > > 1) for mkdir(), create the non-default group, but without its default groups,
    > > > and defer their creation to a worker which won't have constraints on locks held
    > > > by any caller;
    > > > 2) for rmdir(), unlink the non-default group, but without unlinking its default
    > > > groups, and defer the recursive work to a lock-free context?
    > > >
    > > > For mkdir(), this may work. Maybe a bit confusing for userspace, since mkdir(A)
    > > > returns as soon as A is created, but A may be populated later and userspace may
    > > > rely on A being populated as soon as it is created (current behavior). As a
    > > > configfs user, this makes my life harder...
    > >
    > > Right, so that is the whole crux of the matter?

    The "appearance" of the entire default group hierarchy should be
    atomic. When mkdir(2) returns, it is all there. This does make our
    lives a little difficult inside configfs, but it makes everyone else's
    lives much easier.

    > Probably not. I'm not the maintainer of configfs, but I guess that Joel is a bit
    > reluctant to deeply rework parts of something that actually works (conflicts
    > with lockdep excepted).

    That is true - it works, and safely, and the lockdep conflict is
    the only real known issue. I'm not wary of changing it, I'm only wary
    of breaking it. That is, I want to understand what is being changed and
    be sure that we're keeping the correctness we have so far. I don't want
    to change it and "hope" we got it right, you know? This makes me
    cautious, but don't think I'm against change. As I stated, having
    lockdep work for us is a good thing.

    More replies to the other mails coming.



    You can use a screwdriver to screw in screws or to clean your ears,
    however, the latter needs real skill, determination and a lack of fear
    of injuring yourself. It is much the same with JavaScript.
    - Chris Heilmann

    Joel Becker
    Principal Software Developer
    Phone: (650) 506-8127

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