Re: [PATCH] nfsd4: fix a deadlock on state owner replay mutex

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx 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.




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux