tests/kern: make check lock

[fredefab]

make check works for both misc/user but keeps locking
during kernel testing (from t05) in root mode with latest linux-next
kernel and debian 8 on ext4 partition.
Problem appears for all tests (CTRL-C to quit)
in runtest when calling kconjoin.

IMHO t00 also has the same problem:
cd tests/kern
make check TESTS=t00
works because it does only execute bash but when typing exit,
we're locked as well.

end of t05.diod before CTRL-C:

diod: P9_TWALK tag 1 fid 1 newfid 2 nwname 1 '.Trash'
diod: P9_RLERROR tag 1 ecode 2
diod: P9_TWALK tag 1 fid 1 newfid 2 nwname 1 '.Trash-1000'
diod: P9_RLERROR tag 1 ecode 2

t05.out
kconjoin: diodmount exited with rc=0
kconjoin: t05 exited with rc=0

[garlick]

Hmm, diod is not seeing the root fid clunked. It looks like this for me when I type exit from the t00 shell:

[root@jimbo tmp.yUSM8oDTPd]# exit
kconjoin: t00 exited with rc=0
diod: P9_TCLUNK tag 1 fid 1
diod: P9_RCLUNK tag 1
diod: P9_TCLUNK tag 1 fid 0
diod: P9_RCLUNK tag 1
kconjoin: diod exited with rc=0
PASS: t00

Here's what lsof shows right before I type exit:

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
bash    12870 root  cwd    DIR   0,30     4096 6354507 .
lsof    12897 root  cwd    DIR   0,30     4096 6354507 .
lsof    12898 root  cwd    DIR   0,30     4096 6354507 .

Do you see anything different e.g. that might be preventing the file system from being unmounted? I don't understand how the .Trash handling has managed to get wired in here (due to my ignorance probably) since these mounts are in a private namespace established with unshare (CLONE_NEWNS).

[fredefab]

t00 exit is the same as t05 for me:
kconjoin: t00 exited with rc=0
locked

I tried umount -f 9p partition from another shell after typing exit in t00 and I've got the prompt again.
What looks strange is lsof | grep "/tmp/tmp" gives relevant bash before exit and nothing after so there's no reason for this lock. I also tried 3.13 kernel and it's the same behaviour...

Reverting b2dd33b ("Run tests/kern on a pair of pipes (issue 68)")
and run with socketpair gives the same result.

ls -l /proc//fd only gives the pipe and 0/1/2 dev/pts/0

[garlick]

The .Trash stuff is concerning. Who is looking up those files at unmount time? Maybe some mechanism initiated by your window or file manager and executed from within the kernel?

What happens if you ssh back into the machine (thereby getting a shell outside of your windowning environment) and try the test. Does that change anything? Or maybe exit back to a console and try it?

[fredefab]

Still the same starting in console mode. No .Trash but test is locked as well...