From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Sat,  4 Apr 1998 16:25:36 -0500
From: Russ Cox rsc@plan9.bell-labs.com
Subject: [9fans] a problem with the 9p protocol?
Topicbox-Message-UUID: 739e3984-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19980404212536.qjWdL_RcP7s-GsZbFeeMm0SGsN2B2_q35mQcu4aY3Cg@z>

> Where is the problem?

Your problem arises from the way the mount driver handles
mounted file descriptors.  There is a flag CMSG on each fd (well,
each channel) that says whether or not it is mounted.
Once you mount(2) it, the flag gets set.  After the flag is
set, normal reads and writes (via the read and write system
calls) are disallowed, presumably to not interfere with the
9P calls by the mount driver.

> If I run it with:
> 	ramfs -s
> 	filter
> 	mount /srv/filter /tmp/mnt
> it seems to work: 

Right.  In this case, /srv/ramfs has never been mounted directly by the
system, so the associated channel doesn't have the CMSG flag set.
Reads and writes by filter work.

> But if I first mount and
> then unmount the ramfs with:
> 	ramfs -s
> 	mount -c /srv/ramfs /tmp/mnt
> 	unmount /tmp/mnt
> 	filter
> 	mount /srv/filter /tmp/mnt
> I get:
> 	client->server: Tsession tag 65535 		# (from dump)
> 	write server: inappropriate use of fd
> 	mount: mount /srv/filtre /tmp/mnt: fsession: i/o error during authentication

Right.  In this case, /srv/ramfs has been mounted directly,
so CMSG is set. The first time filter calls read or write
(it happens to be a write), it fails.

The phenomenon is more simply demonstrated by
	% ramfs -s
	% echo squeamish ossifrage >>/srv/ramfs
	% mount /srv/ramfs /tmp/mnt
	% unmount /tmp/mnt
	% echo squeamish ossifrage >>/srv/ramfs
	echo: write error: inappropriate use of fd
	%

Russ