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

From: Mike Waychison (Michael.Waychison_at_Sun.COM)
Date: 10/27/04

  • Next message: Daniel Phillips: "Re: Some discussion points open source friendly graphics [was: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?]"
    Date:	Wed, 27 Oct 2004 14:36:38 -0400
    To: Christoph Hellwig <hch@infradead.org>
    
    

    -----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@sun.com>
    >>---
    >>
    >> 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Daniel Phillips: "Re: Some discussion points open source friendly graphics [was: HARDWARE: Open-Source-Friendly Graphics Cards -- Viable?]"

    Relevant Pages

    • Need some help on a pivot_root() syscall implementation
      ... Moves the root file system of the current process to the directory put_old, ... i.e. the mountpoint /mnt with the old root ... but it panics when I do 'ls /mnt' ...
      (freebsd-hackers)
    • Re: SMB Connections
      ... I created the mountpoint as root, but was able to read/write to the ... The mountpoint is "covered up" by the filesystem you are ... hanging over it. ...
      (AIX-L)
    • Re: [9fans] Newbie question
      ... Hence the -c flag on mount and bind. ... mount -c /srv/x mountpoint ... I bet your root file system isn't mounted with the -c flag. ...
      (comp.os.plan9)
    • Re: Newbie loop device question
      ... And where does the mountpoint write its data to? ... The mountpoint is somewhere below root '/' okay? ... Memory fault -- brain fried ...
      (comp.os.linux.misc)