Re: [PATCH 4/28] VFS: Stat shouldn't stop expire

[Mike Waychison]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Hellwig wrote:
> On Mon, Oct 25, 2004 at 10:40:30AM -0400, Mike Waychison wrote:
> 
>>This patch fixes the problem where if you have a mountpoint that is going to
>>expire, it fails to expire before somebody keeps stat(2)ing the root of it's
>>filesystem.  For example, consider the case where a user has his home
>>directory automounted on /home/mikew.   Some other user can keep the
>>filesystem mounted forever by simply calling ls(1) in /home, because the stat
>>action resets the marker on each call.
>>
>>Signed-off-by: Mike Waychison <michael.waychison@xxxxxxx>
>>---
>>
>> namei.c |   11 ++++++++++-
>> 1 files changed, 10 insertions(+), 1 deletion(-)
>>
>>Index: linux-2.6.9-quilt/fs/namei.c
>>===================================================================
>>--- linux-2.6.9-quilt.orig/fs/namei.c	2004-08-14 01:36:45.000000000 -0400
>>+++ linux-2.6.9-quilt/fs/namei.c	2004-10-22 17:17:34.762179488 -0400
>>@@ -275,7 +275,16 @@ int deny_write_access(struct file * file
>> void path_release(struct nameidata *nd)
>> {
>> 	dput(nd->dentry);
>>-	mntput(nd->mnt);
>>+	/*
>>+	 * In order to ensure that access to an automounted filesystems'
>>+	 * root does not reset it's expire counter, we check to see if the path
>>+	 * being released here is a mountpoint itself.  If it is, then we call
>>+	 * _mntput which leaves the expire counter alone.
>>+	 */
>>+	if (nd->mnt && nd->mnt->mnt_root == nd->dentry)
>>+		_mntput(nd->mnt);
>>+	else  
>>+		mntput(nd->mnt);
> 
> 
> Why only for the root dentry not any on stat()  This seems highly inconsistant.

I'm not sure.  I need help in understanding the different cases of
path_release: (please add any others/discrepencies you see)

 1) path walk (across a mountpoint)
 2) open / close (of a mountpoint)
 3) stat / xattr (of a mountpoint)

The first case, a path walk, will always touch a non-mountpoint root
dentry.  As such, the above snippet will always reset the expire counter
 as some other dentry got path_released.

Case 2, opening of a mountpoint happens when you readdir a the base of
the mounted filesystem.  In this case, you aren't path_releasing on
close, but are doing an explicit mntput(filp->f_vfsmnt).

Case 3, you are accessing meta information of the root of the
mountpoint.  Assuming the call is made from 'outside' the mounted
filesystem, the expire counter is currently ticking.  Access to grab
meta information of the base directory of the mountpoint shouldn't reset
the counter, and in all cases I looked at (minimal), they called
path_release when done.

The above hack^Wsnippet was intended to deal with case #3, but it may
make more sense to look into the matter further and perform the special
case in vfs_l?stat themselves.

Thoughts?

> Also while you're at it please give _mntput a more sensible name, e.g.
> mntput_no_expire (yes, I know that name isn't your fault)
> 

Will do.

- --
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFBf+q2dQs4kOxk3/MRAnlQAJ413gDuQLqF5HgOKSQ/S7LrtlaZqQCYix9y
ogHTca+0B+7+HIuSJsY9kQ==
=Qw5B
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/