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

AI search says that "LnxFIFO" is used by WSL?  Have you verified this recently.

On Tue, Jul 7, 2026 at 4:13 AM Pali Rohár <[email protected]> wrote:
>
> SFU fifos are natively supported (created and recognized) at least by:
> - Microsoft POSIX subsystem
> - OpenNT/Interix subsystem
> - Microsoft SFU (Windows Services for UNIX)
> - Microsoft SUA (Subsystem for UNIX-based Applications)
> - Windows NFS server (up to the Windows Server 2008 R2)
>
> Windows NFS server since Windows Server 2012 uses new reparse point format
> for storing new fifos, but still can recognize this old format (also in the
> latest Windows Server 2022 version).
>
> SFU-style fifo is empty regular file which has system attribute set.
>
> These SFU-style fifos are already recognized by Linux SMB client.
>
> But Linux SMB client is currently creating new SFU fifos in different
> format which is not compatible with all those SFU-style consumers. Fix this
> by creating new fifos in correct SFU format which would be recognized by
> all those applications and also by existing Linux SMB clients.
>
> This change affects only creating new fifos when mount option -o sfu is used.
>
> Signed-off-by: Pali Rohár <[email protected]>
> ---
>  fs/smb/client/smb2ops.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c
> index e59fda1b2230..1261b928edee 100644
> --- a/fs/smb/client/smb2ops.c
> +++ b/fs/smb/client/smb2ops.c
> @@ -5293,10 +5293,8 @@ int __cifs_sfu_make_node(unsigned int xid, struct inode *inode,
>                 type[0] = '\0';
>                 break;
>         case S_IFIFO:
> -               type_len = 8;
> -               strscpy(type, "LnxFIFO");
> -               data = (u8 *)&pdev;
> -               data_len = sizeof(pdev);
> +               /* SFU fifo is system file which is empty */
> +               type_len = 0;
>                 break;
>         default:
>                 rc = -EPERM;
> --
> 2.20.1
>
>


-- 
Thanks,

Steve