public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@suse.cz>,
	ltp@lists.linux.it, NeilBrown <neilb@suse.de>,
	linux-nfs@vger.kernel.org, Jeff Layton <jlayton@kernel.org>
Subject: Re: [LTP] [PATCH v5 5/5] nfs: Run on btrfs, ext4, xfs
Date: Fri, 5 May 2023 01:23:21 +0200	[thread overview]
Message-ID: <20230504232321.GA25208@pevik> (raw)
In-Reply-To: <20230504220037.GB4244@pevik>

Hi all,

...
> Tomorrow I'll test this:

> check_umount()
> {
> 	local i
> 	local dir="$1"
> 	local type="${2:-lhost}"
> 	local cmd="grep -q $dir /proc/mounts"

> 	for i in $(seq 50); do
> 		if [ "$type" = "lhost" ]; then
> 			$cmd || return
> 		else
> 			tst_rhost_run -c "$cmd" || return
> 		fi
> 		tst_sleep 100ms
> 		tst_res TWARN "failed to umount '$dir'"
> 	done
> }

> 	for i in $VERSION; do
> 		local_dir="$(get_local_dir $i $n)"
> 		grep -q "$local_dir" /proc/mounts && umount $local_dir

> 		# instead of 'sleep 2' below check here:
> 		check_umount "$local_dir"

> 		n=$(( n + 1 ))
> 	done

> 	n=0
> 	for i in $VERSION; do
> 		type=$(get_socket_type $n)
> 		remote_dir="$(get_remote_dir $i $type)"

> 		if tst_net_use_netns; then
> 			if test -d $remote_dir; then
> 				exportfs -u *:$remote_dir
> 				check_umount "$remote_dir" # instead of sleep 1
> 				rm -rf $remote_dir
> 			fi
> 		else
> 			tst_rhost_run -c "test -d $remote_dir && exportfs -u *:$remote_dir"
> 			check_umount "$remote_dir" rhost # instead of sleep 1
> 			tst_rhost_run -c "test -d $remote_dir && rm -rf $remote_dir"
> 		fi

> 		n=$(( n + 1 ))
> 	done

I tried various code (not only the one - wrong - above), but nothing works.
With fuser -vm, I wonder if there is some bug in older nfs versions:

                     USER        PID ACCESS COMMAND
/tmp/LTP_nfs08.fncaxJum2W/mntpoint/4/tcp:
                     root     kernel mount /tmp/LTP_nfs08.fncaxJum2W/mntpoint
                     root     kernel knfsd /tmp/LTP_nfs08.fncaxJum2W/mntpoint/4

Looking at c6c7f2a84da4 ("nfsd: Ensure knfsd shuts down when the "nfsd" pseudofs
is unmounted"), maybe there are other bugs, which causes files are used.

I also tried to use /proc/fs/nfsd/unlock_filesystem and
/proc/fs/nfsd/write_unlock_ip which made things better a bit (6.2.12), but still
it's not 100% solution. Also, "Release all locks on a local file system"
(unlock_filesystem) and Release all locks used by a client (write_unlock_ip) are
unlikely what I'm searching.

		umount $local_dir
		echo "$local_dir" > /proc/fs/nfsd/unlock_filesystem
		# $(tst_ipaddr rhost) => IP of the server
		echo "$(tst_ipaddr rhost)" > /proc/fs/nfsd/write_unlock_ip
		...

		exportfs -u *:$remote_dir
		echo "$remote_dir" > /proc/fs/nfsd/unlock_filesystem

=> any hint is welcome.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  parent reply	other threads:[~2023-05-04 23:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-04 13:14 [LTP] [PATCH v5 0/5] NFS: test on btrfs, ext4, xfs filesystems Petr Vorel
2023-05-04 13:14 ` [LTP] [PATCH v5 1/5] nfs_lib.sh: Cleanup local and remote directories setup Petr Vorel
2023-05-04 13:58   ` Cyril Hrubis
2023-05-04 21:16     ` Petr Vorel
2023-05-05 10:42       ` Cyril Hrubis
2023-05-05 10:44         ` Petr Vorel
2023-05-04 13:14 ` [LTP] [PATCH v5 2/5] nfs_lib.sh: Unexport on proper side on netns Petr Vorel
2023-05-04 13:14 ` [LTP] [PATCH v5 3/5] nfs05.sh: Lower down the default values Petr Vorel
2023-05-04 13:14 ` [LTP] [PATCH v5 4/5] nfs03.sh: " Petr Vorel
2023-05-05 12:56   ` Petr Vorel
2023-05-04 13:14 ` [LTP] [PATCH v5 5/5] nfs: Run on btrfs, ext4, xfs Petr Vorel
2023-05-04 14:01   ` Cyril Hrubis
2023-05-04 22:00     ` Petr Vorel
2023-05-04 22:02       ` Petr Vorel
2023-05-04 23:23       ` Petr Vorel [this message]
2023-05-05 11:08         ` Cyril Hrubis
2023-05-05 12:59           ` Petr Vorel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230504232321.GA25208@pevik \
    --to=pvorel@suse.cz \
    --cc=chrubis@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=ltp@lists.linux.it \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox