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).

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

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?

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

Oops, I should have closed #61 as a dup and worked on this here, but progress was already reported in #61 so I'll close this one.