lkml.org 
[lkml]   [2019]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] nfsd4: fix a deadlock on state owner replay mutex
Date
It's safe because when we reach move_to_close_lru(), we know we are the
*logical* last call among all racing calls, it is actually the reason we
do the waiting here at fist place. Now just because of racing, we gain
the rp_mutex first and have a *lower* seqid value, so it is what we need
exactly to let the seqid bump with other racing calls before we continue,
that ensures possible future CLOSE call could be replayed correctly.


On Wed, Jul 10, 2019, bfields@fieldses.org wrote:
> I don't understand why that's safe.  Maybe it is, but I don't understand
> yet.  If we take the mutex, bump the seqid, drop the mutex, someone else
> comes in and bumps the seqid again, then we reacquire the mutex... what
> happens?
>
> --b.
\
 
 \ /
  Last update: 2019-07-10 20:43    [W:0.120 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site