[lkml]   [2008]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 0/4] cifs: fix oopses and mem corruption with concurrent mount/umount (try #4)
    On Thu, 30 Oct 2008 12:51:03 -0500
    "Steve French" <> wrote:

    > On Thu, Oct 30, 2008 at 12:42 PM, Jeff Layton <> wrote:
    > > I think we want to resist having locks that protect too many things.
    > > With that, we end up with the locks held over too much code. Not only is
    > > that generally worse for performance, but it can paper over race
    > > conditions.
    > I agree that it is trivially worse for performance to have a single
    > spinlock protecting the three interrelated structures (cifs tcp, smb
    > and tree connection structs), but since they point to one another and
    > frequently have operations that require us to use all three lists -
    > to do things like iterate through all tree connections within a
    > particular smb session, or iterate across all cifs smb sessions within
    > each cifs tcp session - it makes code more complicated to have to grab
    > and unlock multiple spinlocks in the correct order every time across
    > all exit paths etc.

    A fair point, but most of that is in rarely-traveled procfile code. One
    thing we could consider is some helper macros or functions. For
    instance, a for_all_tcons() function or something that would take a
    pointer to a function that takes a tcon arg. It would
    basically just walk over all the tcons and handle the locking
    correctly and call the function for each.

    In any case, I don't see the benefit of not using fine grained locking
    here. deadlock is a possibility, but I think having well-defined
    locking rules mitigates that danger.

    Jeff Layton <>

     \ /
      Last update: 2008-10-30 19:05    [W:0.020 / U:0.492 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site