lkml.org 
[lkml]   [2020]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [GIT PULL] Please pull proc and exec work for 5.7-rc1
    From
    Date
    On 4/3/20 7:16 PM, Waiman Long wrote:
    > On 4/3/20 4:59 PM, Linus Torvalds wrote:
    >> On Fri, Apr 3, 2020 at 1:41 PM Waiman Long <longman@redhat.com> wrote:
    >>> Another alternative is to add new functions like down_read_unfair() that
    >>> perform unfair read locking for its callers. That will require less code
    >>> change, but the calling functions have to make the right choice.
    >> I'd prefer the static choice model - and I'd hide this in some
    >> "task_cred_read_lock()" function anyway rather than have the users do
    >> "mutex_lock_killable(&task->signal->cred_guard_mutex)" like they do
    >> now.
    >>
    >> How nasty would it be to add the "upgrade" op? I took a quick look,
    >> but that just made me go "Waiman would know" ;)
    >>
    >> Linus
    >>
    > With static choice, you mean defined at init time. Right? In that case,
    > you don't really need a special encapsulation function.
    >
    > With upgrade, if there is only one reader, it is pretty straight
    > forward. With more than one readers, it gets more complicated as we have
    > to wait for other readers to unlock. We can spin for a certain period of
    > time. After that, that reader can use the handoff mechanism by queuing
    > itself in front the wait queue before releasing the read lock and go to
    > sleep. That will make sure that it will get the lock once all the other
    > readers exits. For an unfair rwsem, the writer cannot assert the handoff
    > bit and so it shouldn't interfere with this upgrade process.
    >
    > If there are multiple upgrade readers, only one can win the race. The
    > others have to release the read lock and queue themselves as writers.
    > Will that be acceptable?

    Alternatively, we could assert that only one reader can do the upgrade
    and do a WARN_ON_ONCE() if multiple concurrent upgrade attempts is detected.

    Regards,
    Longman

    \
     
     \ /
      Last update: 2020-04-04 01:24    [W:2.665 / U:0.216 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site