Re: [PATCH] cifs: Fix support for creating SFU socket

[Pali Rohár]

I have asked Google Gemini AI:

"Is WSL using "LnxSOCK" for storing AF_UNIX socket on NTFS?"

and I got answer:

"No, WSL does not use the tag LnxSOCK to store AF_UNIX sockets on NTFS.
Instead, WSL relies on native Windows features and specific metadata
attributes to handle AF_UNIX sockets on NTFS:
1. The Native Windows afunix.sys Reparse Point
[... longer explanation of reparse points ...]
2. WSL Metadata Extended Attributes
[... longer explanation of $LXMOD and $LXDEV EAs ...]"

This is just an experiment.

I have feeling that with longer AI discussion or formed questions it is
possible to receive from AI everything... from AI hallucination and
wrong answers, or semi-correct answer to fully correct answers.
Sometimes AI answers what people wants to hear...

On Wednesday 08 July 2026 20:35:23 Pali Rohár wrote:
> WSL does not use "LnxSOCK". This looks like an AI hallucination.
> 
> WSL stores data in NTFS reparse points:
>  IO_REPARSE_TAG_AF_UNIX    - 0x80000023
>  IO_REPARSE_TAG_LX_FIFO    - 0x80000024
>  IO_REPARSE_TAG_LX_CHR     - 0x80000025
>  IO_REPARSE_TAG_LX_BLK     - 0x80000026
>  IO_REPARSE_TAG_LX_SYMLINK - 0xA000001D
> And also in NTFS EAs:
>  "$LXUID"
>  "$LXGID"
>  "$LXMOD"
>  "$LXDEV"
> 
> All tests which I have done with WSL's DrvFs resulted in above reparse
> points (or in native Windows symlinks).
> 
> Some sources which confirms those my testing:
> https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/c8e77b37-3909-4fe6-a4ea-2b9d423b1ee4
> https://learn.microsoft.com/en-us/windows/wsl/file-permissions
> 
> WSL does not recognize "-o sfu" things at all.
> 
> So here I bet that AI "mixed" SFU and WSL formats and parts together and
> created that hallucinated answer.
> 
> On Wednesday 08 July 2026 08:51:40 Steve French wrote:
> > AI query made it sound like "LnxSOCK" is still used by WSL.  Is this
> > change safe?
> > 
> > "Yes. WSL (particularly WSL 1 and WSL 2 when interacting with NTFS via
> > DrvFs) uses the Lnx* metadata family to represent Linux special file
> > types, including:
> > 
> > LnxSOCK
> > LnxFIFO
> > LnxCHR
> > LnxBLK"
> > 
> > On Tue, Jul 7, 2026 at 4:13 AM Pali Rohár <pali@xxxxxxxxxx> wrote:
> > >
> > > SFU sockets are natively supported by Interix 3.0 subsystem and also by
> > > later versions. It is part of Microsoft SFU (Windows Services for UNIX) and
> > > Microsoft SUA (Subsystem for UNIX-based Applications). They can be created
> > > and existing (stored on local disk or remote SMB share) can be recognized.
> > >
> > > SFU sockets are recognized also by NFS server included in Windows Server.
> > > Windows NFS server versions since Windows Server 2012 uses new reparse
> > > point format for storing new sockets, but still can recognize this old
> > > format (also in the latest Windows Server 2022 version).
> > >
> > > SFU-style socket is a regular file which has system attribute set and
> > > content of the file is one zero byte.
> > >
> > > These SFU-style sockets are already recognized by Linux SMB client.
> > >
> > > But Linux SMB client is currently creating new SFU socket in different
> > > format which is not compatible with all those SFU applications. Fix this by
> > > creating new sockets in correct SFU format which would be recognized by all
> > > SFU, SUA, NFS and existing Linux SMB clients.
> > >
> > > This change affects only creating new sockets when mount option -o sfu is used.
> > >
> > > Signed-off-by: Pali Rohár <pali@xxxxxxxxxx>
> > > ---
> > >  fs/smb/client/smb2ops.c | 7 +++----
> > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
> > > index 4f7eefa7a683..e59fda1b2230 100644
> > > --- a/fs/smb/client/smb2ops.c
> > > +++ b/fs/smb/client/smb2ops.c
> > > @@ -5288,10 +5288,9 @@ int __cifs_sfu_make_node(unsigned int xid, struct inode *inode,
> > >                 data = (u8 *)symname_utf16;
> > >                 break;
> > >         case S_IFSOCK:
> > > -               type_len = 8;
> > > -               strscpy(type, "LnxSOCK");
> > > -               data = (u8 *)&pdev;
> > > -               data_len = sizeof(pdev);
> > > +               /* SFU socket is system file with one zero byte */
> > > +               type_len = 1;
> > > +               type[0] = '\0';
> > >                 break;
> > >         case S_IFIFO:
> > >                 type_len = 8;
> > > --
> > > 2.20.1
> > >
> > >
> > 
> > 
> > -- 
> > Thanks,
> > 
> > Steve