Thread (9 messages) 9 messages, 3 authors, 2023-01-29

Re: [PATCH] nfsd: fix race to check ls_layouts

From: Jeff Layton <jlayton@kernel.org>
Date: 2023-01-28 15:20:31

On Sat, 2023-01-28 at 14:15 +0000, Chuck Lever III wrote:
[ Cc'ing the original author of this code. ]

Proposed patch is here:

https://lore.kernel.org/linux-nfs/979eebe94ef380af6a5fdb831e78fd4c0946a59e.1674836262.git.bcodding@redhat.com/ (local)
quoted
On Jan 28, 2023, at 8:47 AM, Jeff Layton [off-list ref] wrote:

On Sat, 2023-01-28 at 08:31 -0500, Benjamin Coddington wrote:
quoted
On 27 Jan 2023, at 13:03, Jeff Layton wrote:
quoted
On Fri, 2023-01-27 at 11:42 -0500, Benjamin Coddington wrote:
quoted
On 27 Jan 2023, at 11:34, Chuck Lever III wrote:
quoted
quoted
On Jan 27, 2023, at 11:18 AM, Benjamin Coddington [off-list ref] wrote:

Its possible for __break_lease to find the layout's lease before we've
added the layout to the owner's ls_layouts list.  In that case, setting
ls_recalled = true without actually recalling the layout will cause the
server to never send a recall callback.

Move the check for ls_layouts before setting ls_recalled.

Signed-off-by: Benjamin Coddington <redacted>
Did this start misbehaving recently, or has it always been broken?
That is, does it need:

Fixes: c5c707f96fc9 ("nfsd: implement pNFS layout recalls") ?
I'm doing some new testing of racing LAYOUTGET and CB_LAYOUTRETURN after
running into a livelock, so I think it has always been broken and the Fixes
tag is probably appropriate.

However, now I'm wondering if we'd run into trouble if ls_layouts could be
empty but the lease still exist..  but that seems like it would be a
different bug.
Yeah, is that even possible? Surely once the last layout is gone, we
drop the stateid? In any case, this patch looks fine. You can add:

Reviewed-by: Jeff Layton <jlayton@kernel.org>
Jeff pointed out that there's another problem here.  We can't just skip
sending the callback if ls_layouts is empty, because then the process trying
to break the lease will end up spinning in __break_lease.

I think we can drop the list_empty() check altogether - it must be there so
that we don't race in and send a callback for a layout that's already been
returned, but I don't see any harm in that.  Clients should just return
NO_MATCHING_LAYOUT.
The bigger worry (AFAICS) is that there is a potential race between
LAYOUTGET and CB_LAYOUTRECALL:

The lease is set very early in the LAYOUTGET process, and it can be
broken at any time beyond that point, even before LAYOUTGET is done and
has populated the ls_layouts list. If __break_lease gets called before
the list is populated, then the recall won't be sent (because ls_layouts
is still empty), but the LAYOUTGET will still complete successfully.

I think we need a check at the end of nfsd4_layoutget, after the
nfsd4_insert_layout call to see whether the lease has been broken. If it
has, then we should unwind everything and return NFS4ERR_RECALLCONFLICT.
Shall I drop this fix from nfsd-next, then?
No, I think Ben's fix is still valid. The problem I'm seeing is a
different issue in the same area of the code. A follow-on patch to
address that is appropriate.

-- 
Jeff Layton [off-list ref]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help