Marking inodes as stale can be wrong

[Olaf Kirch <okir@suse.de>]

Hi,

I've been debugging a strange problem with kmail on an NFS mounted
home directory. Attaching files to an outgoing message would cause
the mail to fail. For instance, after opening the file selection
dialog, kmail was no longer able to read the outbox.
This was 100 % reproduceable

The problem was caused by the following:

 -	a KDE component would invoke some silly setuid
 	helper program prior to displaying the file
	selection dialog. This helper would receive all
	open file descriptors, including those of the
	open mail boxes.

 -	the helper program itself did not access any of
 	these files, but for some reason, we still ended
	up calling revalidate_inode on the open files.
	I haven't quite found out why.

 -	nfs_revalidate_inode would do a GETATTR call to
 	the server (running the 2.4.22 kernel), using
	uid 0.

	The file system was exported with root_squash
	and subtree_check.

	fh_verify did the subtree check, and found that
	~/Mail was mode 700, and hence user nobody didn't
	have x permissions on the directory. So it would
	return ESTALE to the client.

 -	The client marks the file handle as STALE

 -	The next attempt to read from the file fails because
 	of this.

How should we fix this? I asked the KDE folks to mark their mail box
file descriptor FD_CLOEXEC, but that is just a workaround, as other
application may exhibit similar problems.

I think it's wrong to mark the file handle STALE for everyone; whether
GETATTR reports NFSERR_STALE can depend on the process doing the call.

What is the rationale behind making the stale-ness information sticky?
Can we safely get rid of the NFS_INO_STALE flag?

Olaf
-- 
Olaf Kirch     |  The Hardware Gods hate me.
okir@suse.de   |
---------------+ 


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs