| Message ID | 20161011053352.27645.83962.stgit@pluto.themaw.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Ian Kent <raven@themaw.net> writes: > For the autofs module to be able to reliably check if a dentry is a > mountpoint in a multiple namespace environment the ->d_manage() dentry > operation will need to take a path argument instead of a dentry. Taking a quick look overall I see no issues with this series. Overall it seems straight forward. On the nit side I expect saying const struct path * in the functions that now take a struct path would be useful. I suspect it would also be useful to say const struct path *path; path = &file->f_path; In the one part of the code where you do that. Instead of copying the path out of the struct file. Overall I expect that will keep down bugs at no reduction in usability. Just a statement that the struct path won't change when it is passed to various functions. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2016-10-11 at 11:04 -0500, Eric W. Biederman wrote: > Ian Kent <raven@themaw.net> writes: > > > For the autofs module to be able to reliably check if a dentry is a > > mountpoint in a multiple namespace environment the ->d_manage() dentry > > operation will need to take a path argument instead of a dentry. > > Taking a quick look overall I see no issues with this series. Overall > it seems straight forward. > > On the nit side I expect saying const struct path * in the functions > that now take a struct path would be useful. > > I suspect it would also be useful to say > const struct path *path; > path = &file->f_path; > > In the one part of the code where you do that. Instead of copying the > path out of the struct file. > > Overall I expect that will keep down bugs at no reduction in usability. > Just a statement that the struct path won't change when it is passed > to various functions. Thanks Eric, that's a good suggestion for a follow up patch, will do. Ian -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 11 Oct 2016 13:33:52 +0800 Ian Kent <raven@themaw.net> wrote: > For the autofs module to be able to reliably check if a dentry is a > mountpoint in a multiple namespace environment the ->d_manage() dentry > operation will need to take a path argument instead of a dentry. This patchset contains lots of ViroStuff. I'll queue it up for some testing and will go into wait-and-see mode. Some patches had an explicit From: Ian Kent <ikent@redhat.com> and some did not. I assumed that this was intended for all patches. So all patches now have different From: and Signed-off-by: email addresses. Unclear if this was your intent ;) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2016-10-19 at 12:40 -0700, Andrew Morton wrote: > On Tue, 11 Oct 2016 13:33:52 +0800 Ian Kent <raven@themaw.net> wrote: > > > For the autofs module to be able to reliably check if a dentry is a > > mountpoint in a multiple namespace environment the ->d_manage() dentry > > operation will need to take a path argument instead of a dentry. > > This patchset contains lots of ViroStuff. I'll queue it up for some > testing and will go into wait-and-see mode. Thanks Andrew. Maybe Al has been too busy to comment, he has been on the Cc from the start. Hopefully this email will prompt a review, Al? > > Some patches had an explicit From: Ian Kent <ikent@redhat.com> and some > did not. I assumed that this was intended for all patches. So all > patches now have different From: and Signed-off-by: email addresses. > Unclear if this was your intent ;) Umm ... sorry about that, I didn't pay enough attention to the From of the patches when I resurrected them from an earlier attempt at this. Since the time I did this with an earlier patch series I have elected to not change my git config and set these in the local tree config so it shouldn't happen for new work. I'll pay special attention to this if I need to resurrect any other older patches too. I know this looks confusing and isn't the best but both email addresses have been present on my gpg key for a long time so it's verifiable the patches are from me. Once again sorry about that. Ian -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 21, 2016 at 07:39:36AM +0800, Ian Kent wrote: > Maybe Al has been too busy to comment, he has been on the Cc from the start. That's... a very mild version of what's been going on. Let's just say that the last few weeks had been really interesting. Not that the shit has settled, but there was some slackening in the shitstorm last few days. Unlikely to last, I'm afraid, but... > Hopefully this email will prompt a review, Al? Aside of the Eric's note re constifying struct path (strongly seconded), I'm not sure if expiration-related side of that is correct. OTOH, since the expiration happens from userland... How much testing did it get? I've several test setups involving autofs, but they are nowhere near exhaustive and I don't have good enough feel of the codebase to slap together something with decent coverage... -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2016-10-27 at 03:11 +0100, Al Viro wrote: > On Fri, Oct 21, 2016 at 07:39:36AM +0800, Ian Kent wrote: > > > > > Maybe Al has been too busy to comment, he has been on the Cc from the start. > That's... a very mild version of what's been going on. Let's just say that > the last few weeks had been really interesting. Not that the shit has > settled, but there was some slackening in the shitstorm last few days. > Unlikely to last, I'm afraid, but... > > > > > Hopefully this email will prompt a review, Al? > Aside of the Eric's note re constifying struct path (strongly seconded), > I'm not sure if expiration-related side of that is correct. OTOH, > since the expiration happens from userland... Sure, I have a follow up series to do the constifying as recommended by Eric and now yourself. > > How much testing did it get? I've several test setups involving > autofs, but they are nowhere near exhaustive and I don't have good > enough feel of the codebase to slap together something with decent > coverage... It got my standard testing. For that I use a modified version of the autofs Connectathon system. It's more about testing a wide variety of syntax and map setups and so exercises a large number of different types of autofs mounts. It's meant to check normal operation but not so much stress testing even though it does perform quite a few mounts (around 250-300, not to mention the autofs mounts themselves). I have another standard test I call the submount-test and it was originally done to stress test the most common problem I see, concurrent expire to mount. I didn't see any problems I couldn't explain in these but I might need to re- visit the submount-test to see if it is still doing what I want. OTOH, the pattern of mount and umount I see when the submount-test is run does look like it is doing what I want but it might not be getting all the way to the top of the tree of mounts enough times over the course of the test. So I'm happy with my testing, just not as happy as I could be. Ian -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2016-10-27 at 10:47 +0800, Ian Kent wrote: > On Thu, 2016-10-27 at 03:11 +0100, Al Viro wrote: > > > > > > How much testing did it get? I've several test setups involving > > autofs, but they are nowhere near exhaustive and I don't have good > > enough feel of the codebase to slap together something with decent > > coverage... > It got my standard testing. > > For that I use a modified version of the autofs Connectathon system. > > It's more about testing a wide variety of syntax and map setups and so > exercises > a large number of different types of autofs mounts. > > It's meant to check normal operation but not so much stress testing even > though > it does perform quite a few mounts (around 250-300, not to mention the autofs > mounts themselves). > > I have another standard test I call the submount-test and it was originally > done > to stress test the most common problem I see, concurrent expire to mount. > > I didn't see any problems I couldn't explain in these but I might need to re- > visit the submount-test to see if it is still doing what I want. > > OTOH, the pattern of mount and umount I see when the submount-test is run does > look like it is doing what I want but it might not be getting all the way to > the > top of the tree of mounts enough times over the course of the test. > > So I'm happy with my testing, just not as happy as I could be. Well, almost happy with my testing. Naturally I also tested the specific case this series is meant to fix. Basically: ls /mnt/foo # do the initial automount unshare -m sleep 10 & # hold the automount in a new namespace umount /mnt/foo # pretend the mount timed out ls /mnt/foo # try to access it again ls: cannot open directory '/mnt/foo': Too many levels of symbolic links as seen on the autofs mailing list. My specific test was a little different but verified this was resolved. Now that Al seems reasonably OK with the series, with some changes, I'll test some other use cases, mainly to verify the expire still functions as required. That might need more work. Ian -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2016-10-27 at 14:50 +0800, Ian Kent wrote: > On Thu, 2016-10-27 at 10:47 +0800, Ian Kent wrote: > > > > On Thu, 2016-10-27 at 03:11 +0100, Al Viro wrote: > > > > > > > > > > > > How much testing did it get? I've several test setups involving > > > autofs, but they are nowhere near exhaustive and I don't have good > > > enough feel of the codebase to slap together something with decent > > > coverage... > > It got my standard testing. > > > > For that I use a modified version of the autofs Connectathon system. > > > > It's more about testing a wide variety of syntax and map setups and so > > exercises > > a large number of different types of autofs mounts. > > > > It's meant to check normal operation but not so much stress testing even > > though > > it does perform quite a few mounts (around 250-300, not to mention the > > autofs > > mounts themselves). > > > > I have another standard test I call the submount-test and it was originally > > done > > to stress test the most common problem I see, concurrent expire to mount. > > > > I didn't see any problems I couldn't explain in these but I might need to > > re- > > visit the submount-test to see if it is still doing what I want. > > > > OTOH, the pattern of mount and umount I see when the submount-test is run > > does > > look like it is doing what I want but it might not be getting all the way to > > the > > top of the tree of mounts enough times over the course of the test. > > > > So I'm happy with my testing, just not as happy as I could be. > Well, almost happy with my testing. > > Naturally I also tested the specific case this series is meant to fix. > > Basically: > ls /mnt/foo # do the initial automount > unshare -m sleep 10 & # hold the automount in a new namespace > umount /mnt/foo # pretend the mount timed out > ls /mnt/foo # try to access it again > ls: cannot open directory '/mnt/foo': Too many levels of symbolic links > > as seen on the autofs mailing list. My specific test was a little different > but > verified this was resolved. > > Now that Al seems reasonably OK with the series, with some changes, I'll test > some other use cases, mainly to verify the expire still functions as required. > That might need more work. I have done some further tests, specifically for (what I believe are) the two most common use cases. First, using automount(8) entirely within a container, as expected works fine. But the second case, one where automount(8) is run in the root namespace and has automount directories bound into a container does have a problem. The problem is due to may_umount_tree() only considering mounts in the root namespace and leads to expire attempts on mounts even if they are in use in another namespace. It's not a serious problem as the umount attempt fails because the mount is busy but it would be good to avoid the call back overhead. Unfortunately it looks like transforming may_umount_tree() to use a similar check to may_umount() introduces a race (picked up by my submount-test) which I'm struggling to understand, I'll continue to work on it. Ian -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index fe15682..1949ac4 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -20,7 +20,7 @@ prototypes: void (*d_iput)(struct dentry *, struct inode *); char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen); struct vfsmount *(*d_automount)(struct path *path); - int (*d_manage)(struct dentry *, bool); + int (*d_manage)(struct path *, bool); struct dentry *(*d_real)(struct dentry *, const struct inode *, unsigned int); diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index bc3b8e0..db70d71 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -934,7 +934,7 @@ struct dentry_operations { void (*d_iput)(struct dentry *, struct inode *); char *(*d_dname)(struct dentry *, char *, int); struct vfsmount *(*d_automount)(struct path *); - int (*d_manage)(struct dentry *, bool); + int (*d_manage)(struct path *, bool); struct dentry *(*d_real)(struct dentry *, const struct inode *, unsigned int); }; diff --git a/fs/autofs4/root.c b/fs/autofs4/root.c index a11f731..5cbd4e1 100644 --- a/fs/autofs4/root.c +++ b/fs/autofs4/root.c @@ -32,7 +32,7 @@ static int autofs4_dir_open(struct inode *inode, struct file *file); static struct dentry *autofs4_lookup(struct inode *, struct dentry *, unsigned int); static struct vfsmount *autofs4_d_automount(struct path *); -static int autofs4_d_manage(struct dentry *, bool); +static int autofs4_d_manage(struct path *, bool); static void autofs4_dentry_release(struct dentry *); const struct file_operations autofs4_root_operations = { @@ -421,8 +421,9 @@ static struct vfsmount *autofs4_d_automount(struct path *path) return NULL; } -static int autofs4_d_manage(struct dentry *dentry, bool rcu_walk) +static int autofs4_d_manage(struct path *path, bool rcu_walk) { + struct dentry *dentry = path->dentry; struct autofs_sb_info *sbi = autofs4_sbi(dentry->d_sb); struct autofs_info *ino = autofs4_dentry_ino(dentry); int status; diff --git a/fs/namei.c b/fs/namei.c index a7f601c..704766a 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -1200,7 +1200,7 @@ static int follow_managed(struct path *path, struct nameidata *nd) if (managed & DCACHE_MANAGE_TRANSIT) { BUG_ON(!path->dentry->d_op); BUG_ON(!path->dentry->d_op->d_manage); - ret = path->dentry->d_op->d_manage(path->dentry, false); + ret = path->dentry->d_op->d_manage(path, false); if (ret < 0) break; } @@ -1263,10 +1263,10 @@ int follow_down_one(struct path *path) } EXPORT_SYMBOL(follow_down_one); -static inline int managed_dentry_rcu(struct dentry *dentry) +static inline int managed_dentry_rcu(struct path *path) { - return (dentry->d_flags & DCACHE_MANAGE_TRANSIT) ? - dentry->d_op->d_manage(dentry, true) : 0; + return (path->dentry->d_flags & DCACHE_MANAGE_TRANSIT) ? + path->dentry->d_op->d_manage(path, true) : 0; } /* @@ -1282,7 +1282,7 @@ static bool __follow_mount_rcu(struct nameidata *nd, struct path *path, * Don't forget we might have a non-mountpoint managed dentry * that wants to block transit. */ - switch (managed_dentry_rcu(path->dentry)) { + switch (managed_dentry_rcu(path)) { case -ECHILD: default: return false; @@ -1392,8 +1392,7 @@ int follow_down(struct path *path) if (managed & DCACHE_MANAGE_TRANSIT) { BUG_ON(!path->dentry->d_op); BUG_ON(!path->dentry->d_op->d_manage); - ret = path->dentry->d_op->d_manage( - path->dentry, false); + ret = path->dentry->d_op->d_manage(path, false); if (ret < 0) return ret == -EISDIR ? 0 : ret; } diff --git a/include/linux/dcache.h b/include/linux/dcache.h index 5beed7b..798bc04 100644 --- a/include/linux/dcache.h +++ b/include/linux/dcache.h @@ -139,7 +139,7 @@ struct dentry_operations { void (*d_iput)(struct dentry *, struct inode *); char *(*d_dname)(struct dentry *, char *, int); struct vfsmount *(*d_automount)(struct path *); - int (*d_manage)(struct dentry *, bool); + int (*d_manage)(struct path *, bool); struct dentry *(*d_real)(struct dentry *, const struct inode *, unsigned int); } ____cacheline_aligned;
For the autofs module to be able to reliably check if a dentry is a mountpoint in a multiple namespace environment the ->d_manage() dentry operation will need to take a path argument instead of a dentry. Signed-off-by: Ian Kent <raven@themaw.net> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Omar Sandoval <osandov@osandov.com> --- Documentation/filesystems/Locking | 2 +- Documentation/filesystems/vfs.txt | 2 +- fs/autofs4/root.c | 5 +++-- fs/namei.c | 13 ++++++------- include/linux/dcache.h | 2 +- 5 files changed, 12 insertions(+), 12 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html