Re: [PATCH] cifs: Fix support for creating SFU socket
Pali Rohár <[email protected]>
| Newsgroups | org.kernel.vger.linux-cifs,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <20260708195052.lppgfsvgxwhjlivu@pali> |
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 <[email protected]> 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 <[email protected]> > > > --- > > > 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