Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8;
From:   Benjamin Coddington <bcodding@redhat.com>
To:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: Blocklayoutdriver deadlock with knfsd
Date:   Thu, 16 Nov 2023 12:17:55 -0500
Message-ID: <3A3EABED-888C-40B1-9929-B4CCDB646BA0@redhat.com>
In-Reply-To: <1CC82EC5-6120-4EE4-A7F0-019CF7BC762C@redhat.com>
References: <1CC82EC5-6120-4EE4-A7F0-019CF7BC762C@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On 16 Nov 2023, at 12:11, Benjamin Coddington wrote:

> I ran into this old problem again recently, last discussed here:
> https://lore.kernel.org/linux-nfs/F738DB31-B527-4048-94A7-DBF00533F8C1@=
redhat.com/#t
>
> Problem is that clients can easily issue enough WRITEs that end up in
>
> __break_lease
> xfs_break_leased_layouts
> ...
> nfsd_vfs_write
> ...
> svc_process
> svc_recv
> nfsd
>
> .. so that all the knfsds are there, and nothing can process the
> LAYOUTRETURN.
>
> I'm pretty sure we can make the linux client a bit smarter about it (I =
saw
> one LAYOUTGET and one conflicting WRITE in the same TCP segment, in tha=
t
> order).

Actually, I can't imagine any block/SCSI/NVMe server implementation that
would be fine with a client writing to the device at the same time the se=
rver
does, and so why shouldn't the client preemptively return the layout?

Ben