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 t
On Thu, Jun 27, 2019 at 06:30:27PM +, 黄乐 wrote:
> from: Huang Le
>
> In move_to_close_lru(), which only be called on path of nfsd4 CLOSE op,
> the code could wait for its stid ref count drop to 2 while holding its
> state owner replay mutex. However, the other stid ref holder (normally
> a p
from: Huang Le
In move_to_close_lru(), which only be called on path of nfsd4 CLOSE op,
the code could wait for its stid ref count drop to 2 while holding its
state owner replay mutex. However, the other stid ref holder (normally
a parallel CLOSE op) that move_to_close_lru() is waiting for might
from: Huang Le
In move_to_close_lru(), which only be called on path of nfsd4 CLOSE op,
the code could wait for its stid ref count drop to 2 while holding its
state owner replay mutex. However, the other stid ref holder (normally
a parallel CLOSE op) that move_to_close_lru() is waiting for might
4 matches
Mail list logo
