[lkml]   [2009]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[rfc] "fair" rw spinlocks

    Last time this issue came up that I could see, I don't think
    there were objections to making rwlocks fair, the main
    difficulty seemed to be that we allow reentrant read locks
    (so a write lock waiting must not block arbitrary read lockers).

    Nowadays our rwlock usage is smaller although still quite a
    few, so it would make better sense to do a conversion by
    introducing a new lock type and move them over I guess.

    Anyway, I would like to add some kind of fairness or at least
    anti starvation for writers. We have a customer seeing total
    livelock on tasklist_lock for write locking on a system as small
    as 8 core Opteron.

    This was basically reproduced by several cores executing wait
    with WNOHANG.

    Of course it would always be nice to improve locking so
    contention isn't an issue, but so long as we have rwlocks, we
    could possibly get into a situation where starvation is
    triggered *somehow*. So I'd really like to fix this.

    This particular starvation on tasklist lock I guess is a local
    DoS vulnerability even if the workload is not particularly

    Anyway, I don't have a patch yet. I'm sure it can be done
    without extra atomics in fastpaths. Comments?

     \ /
      Last update: 2009-11-23 15:57    [W:0.018 / U:24.768 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site