cifs hardlink misbehaviour in generic/002?

[David Howells <dhowells@redhat.com>]

[-- 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 --]