[PATCH v3 0/4] smb: smbdirect/client/server: relax WARN_ON_ONCE(SMBDIRECT_SOCKET_*) checks

[Namjae Jeon]

On Thu, Nov 27, 2025 at 1:03 AM Stefan Metzmacher <metze at samba.org> wrote:
>
> Am 26.11.25 um 16:18 schrieb Stefan Metzmacher via samba-technical:
> > Am 26.11.25 um 16:17 schrieb Namjae Jeon:
> >> On Wed, Nov 26, 2025 at 4:16 PM Stefan Metzmacher <metze at samba.org> wrote:
> >>>
> >>> Am 26.11.25 um 00:50 schrieb Namjae Jeon:
> >>>> On Tue, Nov 25, 2025 at 11:22 PM Stefan Metzmacher <metze at samba.org> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> here are some small cleanups for a problem Nanjae reported,
> >>>>> where two WARN_ON_ONCE(sc->status != ...) checks where triggered
> >>>>> by a Windows 11 client.
> >>>>>
> >>>>> The patches should relax the checks if an error happened before,
> >>>>> they are intended for 6.18 final, as far as I can see the
> >>>>> problem was introduced during the 6.18 cycle only.
> >>>>>
> >>>>> Given that v1 of this patchset produced a very useful WARN_ONCE()
> >>>>> message, I'd really propose to keep this for 6.18, also for the
> >>>>> client where the actual problem may not exists, but if they
> >>>>> exist, it will be useful to have the more useful messages
> >>>>> in 6.16 final.
> >>>> First, the warning message has been improved. Thanks.
> >>>> However, when copying a 6-7GB file on a Windows client, the following
> >>>> error occurs. These error messages did not occur when testing with the
> >>>> older ksmbd rdma(https://github.com/namjaejeon/ksmbd).
> >>>
> >>> With transport_rdma.* from restored from 6.17?
> >> I just tested it and this issue does not occur on ksmbd rdma of the 6.17 kernel.
> >
> > 6.17 or just transport_rdma.* from 6.17, but the rest from 6.18?
> >
>
> Can you also test with 6.17 + fad988a2158d743da7971884b93482a73735b25e
> Maybe that changed things in order to let RDMA READs fail or cause a
> disconnect.
The kernel version I tested was 6.17.9 and this patch was already applied.
>
> Otherwise I'd suggest to test the following commits in order
> to find where the problem was introduced:
> 177368b9924314bde7d2ea6dc93de0d9ba728b61
I don't have time to do this right now due to other work.
Did you test it with a Windows client and can't find this issue?
>
> After this it gets more tricky.
>
> metze
>
>
>