Re: [d_path 0/7] Fixes to d_path: Respin

[Andreas Gruenbacher <agruen@suse.de>]

On Friday 20 April 2007 21:17, Ulrich Drepper wrote:
> On 4/20/07, Andreas Gruenbacher <agruen@suse.de> wrote:
> > The code also seems to stop at the first matching mount point. You can
> > have the same device mounted on the same mount point multiple times but
> > with different mount options, e.g., [...]
> 
> You can unfortunately do many stupid things.  That's the user's
> problem.  The point is that everything works fine in an environment
> which does not have such bogus mounts.

What I described is a supported feature, nothing more and nothing less. It's 
also relatively easy to handle this case correctly in glibc, e.g.,

--- a/sysdeps/unix/sysv/linux/internal_statvfs.c
+++ b/sysdeps/unix/sysv/linux/internal_statvfs.c
@@ -139,6 +139,7 @@ __statvfs_getflags (const char *name, in
 	      char *cp = mntbuf.mnt_opts;
 	      char *opt;
 
+	      result = 0;
 	      while ((opt = strsep (&cp, ",")) != NULL)
 		if (strcmp (opt, "ro") == 0)
 		  result |= ST_RDONLY;
@@ -157,9 +158,10 @@ __statvfs_getflags (const char *name, in
 		else if (strcmp (opt, "nodiratime") == 0)
 		  result |= ST_NODIRATIME;
 
-	      /* We can stop looking for more entries.  */
 	      success = true;
-	      break;
+	      /* Don't stop looking: the same device may be mounted several
+	         times with different options; in that case, the last entry
+		 is the topmost mount.  */
 	    }
 	}
       /* Maybe the kernel names for the filesystems changed or the

> > I gave a chroot example that showed that in the current implementation,
> > you can get pretty random clashes between mounts; there are other cases
> > with lazy unmounts as well. 
> 
> Irrelevant as well.  If you create chroot problems it's your problem.

There is no way to avoid these problems with chroots; it's not that anybody 
creates stupid problems on purpose.

The approach I'm proposing fixes these problems. It has a small disadvantage 
for statvfs / fstatvfs in some situations, which is due to the fact that the 
kernel doesn't offer a direct interface for querying the mount options of a 
file descriptor or path, and so glibc has to resort to messing 
with /proc/mounts. I don't see a nice way of fixing this without introducing 
[f]statvfs syscalls right now.

This is what POSIX says about statvfs / fstatvfs:
> It is unspecified whether all members of the statvfs structure have
> meaningful values on all file systems.

In my opinion, the advantage of not reporting bogus pathnames in /proc/mounts 
by far outweighs the problems is sometimes causes for fstatvfs(). Anyone 
relying on the information obtained from statvfs / fstatvfs is making false 
assumptions anyway, and in "normal setups" as you called them, nothing 
changes for fstatvfs and statvfs.

Andreas
-
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/