cifs hardlink misbehaviour in generic/002?

cifs hardlink misbehaviour in generic/002?

[David Howells]

[-- Attachment #1: Type: text/plain, Size: 1994 bytes --]


Hi Steve,

I've seeing some weird behaviour in the upstream Linux cifs filesystem that's
causing generic/002 to fail.  The test case makes a file and creates a number
of hardlinks to it, then deletes those hardlinks in reverse order, checking
the link count on the original file each time it removes one.

However, I'm seeing the original file disappear when the most recent link is
removed, leading to the check for the link count to fail due to $x evaluating
blank and the '[' program complaining about syntax.

I've distilled the testcase down to a small shell script:

	#!/bin/sh
	TEST_DIR=/xfstest.test/tmp/
	top=3
	if [ ! -d $TEST_DIR ]
	then
	    mkdir $TEST_DIR || exit $?
	else
	    rm $TEST_DIR/foo.*
	fi
	touch $TEST_DIR/foo.1
	for ((l=2; l<=$top; l++))
	do
	    ln -v $TEST_DIR/foo.1 $TEST_DIR/foo.$l
	done
	ls $TEST_DIR
	for ((l=$top; l>=1; l--))
	do
	    if [ ! -f $TEST_DIR/foo.1 ]
	    then
		echo "Arrgh, foo.1 is missing!"
		ls $TEST_DIR
		exit 1
	    fi
	    x=`stat -c %h $TEST_DIR/foo.1`
	    if [ "$l" -ne $x ]
	    then
		echo "Arrgh, incorrect link count"
		$here/src/lstat64 $TEST_DIR/foo.1
		status=1
	    fi
	    rm -v -f $TEST_DIR/foo.$l
	done

that I'm running on a Linux v6.6 ksmbd share mounted with:

	mount //192.168.6.1/test /xfstest.test -o user=...,pass=...,noperm,vers=3.1.1,cache=loose

The server includes the following settings:

        server role = standalone server
        log level = 1
        security = user
        load printers = no
        #smb3 encryption = yes
        netbios name = SMBD
        server multi channel support = yes
        smb2 leases = yes

The output I see is:

	'/xfstest.test/tmp//foo.2' => '/xfstest.test/tmp//foo.1'
	'/xfstest.test/tmp//foo.3' => '/xfstest.test/tmp//foo.1'
	foo.1  foo.2  foo.3
	removed '/xfstest.test/tmp//foo.3'
	Arrgh, foo.1 is missing!
	foo.1  foo.2  foo.3

I've attached a wireshark trace of the script being run.

I see a lot of STATUS_DELETE_PENDING apparently being applied to foo.1.

David


[-- Attachment #2: pcap.gz --]
[-- Type: application/gzip, Size: 3760 bytes --]

Re: cifs hardlink misbehaviour in generic/002?

[Paulo Alcantara]

David Howells <dhowells@redhat.com> writes:

> I've seeing some weird behaviour in the upstream Linux cifs filesystem that's
> causing generic/002 to fail.  The test case makes a file and creates a number
> of hardlinks to it, then deletes those hardlinks in reverse order, checking
> the link count on the original file each time it removes one.

I could also reproduce it in ksmbd but not in Windows Server 2022 or
samba v4.19.

Re: cifs hardlink misbehaviour in generic/002?

[David Howells]

Paulo Alcantara <pc@manguebit.com> wrote:

> David Howells <dhowells@redhat.com> writes:
> 
> > I've seeing some weird behaviour in the upstream Linux cifs filesystem
> > that's causing generic/002 to fail.  The test case makes a file and
> > creates a number of hardlinks to it, then deletes those hardlinks in
> > reverse order, checking the link count on the original file each time it
> > removes one.
> 
> I could also reproduce it in ksmbd but not in Windows Server 2022 or
> samba v4.19.

Yeah - works for me with samba also; just not with ksmbd.

David

Re: cifs hardlink misbehaviour in generic/002?

[Jeremy Allison]

On Fri, Dec 01, 2023 at 02:29:41PM -0300, Paulo Alcantara wrote:
>David Howells <dhowells@redhat.com> writes:
>
>> I've seeing some weird behaviour in the upstream Linux cifs filesystem that's
>> causing generic/002 to fail.  The test case makes a file and creates a number
>> of hardlinks to it, then deletes those hardlinks in reverse order, checking
>> the link count on the original file each time it removes one.
>
>I could also reproduce it in ksmbd but not in Windows Server 2022 or
>samba v4.19.

Looks like a ksmbd bug where it's not checking for multiple
opens on close with DELETE_ON_CLOSE set, and just removing
the file.

Re: cifs hardlink misbehaviour in generic/002?

[Paulo Alcantara]

Jeremy Allison <jra@samba.org> writes:

> Looks like a ksmbd bug where it's not checking for multiple
> opens on close with DELETE_ON_CLOSE set, and just removing
> the file.

Interesting.  Using 'nolease' mount option on the client make the issue
disappear.

Re: cifs hardlink misbehaviour in generic/002?

[Namjae Jeon]

2023-12-02 1:15 GMT+09:00, David Howells <dhowells@redhat.com>:
>
> Hi Steve,
Hi David,

We have already sent the fixes on this week, So It has been in the
latest linus master.
Could you please check it on the latest master or after applying
commit 4274a9dc6aeb "ksmbd: separately allocate ci per dentry" ?

Thanks.
>
> I've seeing some weird behaviour in the upstream Linux cifs filesystem
> that's
> causing generic/002 to fail.  The test case makes a file and creates a
> number
> of hardlinks to it, then deletes those hardlinks in reverse order, checking
> the link count on the original file each time it removes one.
>
> However, I'm seeing the original file disappear when the most recent link
> is
> removed, leading to the check for the link count to fail due to $x
> evaluating
> blank and the '[' program complaining about syntax.
>
> I've distilled the testcase down to a small shell script:
>
> 	#!/bin/sh
> 	TEST_DIR=/xfstest.test/tmp/
> 	top=3
> 	if [ ! -d $TEST_DIR ]
> 	then
> 	    mkdir $TEST_DIR || exit $?
> 	else
> 	    rm $TEST_DIR/foo.*
> 	fi
> 	touch $TEST_DIR/foo.1
> 	for ((l=2; l<=$top; l++))
> 	do
> 	    ln -v $TEST_DIR/foo.1 $TEST_DIR/foo.$l
> 	done
> 	ls $TEST_DIR
> 	for ((l=$top; l>=1; l--))
> 	do
> 	    if [ ! -f $TEST_DIR/foo.1 ]
> 	    then
> 		echo "Arrgh, foo.1 is missing!"
> 		ls $TEST_DIR
> 		exit 1
> 	    fi
> 	    x=`stat -c %h $TEST_DIR/foo.1`
> 	    if [ "$l" -ne $x ]
> 	    then
> 		echo "Arrgh, incorrect link count"
> 		$here/src/lstat64 $TEST_DIR/foo.1
> 		status=1
> 	    fi
> 	    rm -v -f $TEST_DIR/foo.$l
> 	done
>
> that I'm running on a Linux v6.6 ksmbd share mounted with:
>
> 	mount //192.168.6.1/test /xfstest.test -o
> user=...,pass=...,noperm,vers=3.1.1,cache=loose
>
> The server includes the following settings:
>
>         server role = standalone server
>         log level = 1
>         security = user
>         load printers = no
>         #smb3 encryption = yes
>         netbios name = SMBD
>         server multi channel support = yes
>         smb2 leases = yes
>
> The output I see is:
>
> 	'/xfstest.test/tmp//foo.2' => '/xfstest.test/tmp//foo.1'
> 	'/xfstest.test/tmp//foo.3' => '/xfstest.test/tmp//foo.1'
> 	foo.1  foo.2  foo.3
> 	removed '/xfstest.test/tmp//foo.3'
> 	Arrgh, foo.1 is missing!
> 	foo.1  foo.2  foo.3
>
> I've attached a wireshark trace of the script being run.
>
> I see a lot of STATUS_DELETE_PENDING apparently being applied to foo.1.
>
> David
>
>

Re: cifs hardlink misbehaviour in generic/002?

[David Howells]

Namjae Jeon <linkinjeon@kernel.org> wrote:

> We have already sent the fixes on this week, So It has been in the
> latest linus master.
> Could you please check it on the latest master or after applying
> commit 4274a9dc6aeb "ksmbd: separately allocate ci per dentry" ?

Yep.  That fixes it.

David