> > 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. > > The fact is that if you have a normal setup the code works fine. All > other situations cannot be handled with the current kernel interface. > > This does not give anybody the right to say "since the code doesn't > always work we can break it completely". That's completely > unacceptable.
I'm not sure I understand the situation completely. What exactly is broken in libc by removing unreachable mounts from /proc/mounts? Is it the situation when - file descriptor is opened - process does chroot - process does fstatvfs on file descriptor ? In that case currently fstatvfs() _usually_ gives the correct results, but can give wrong results if mounts paths accidently clash in /proc/mounts? Also isn't it the case, that fstatvfs() or statvfs() performed within the chroot could also give incorrect result for a _reachable_ mount if it clashes with an unreachable mount? If this is the case, I would think that removing the unreachable mounts from /proc/mounts, would actually be fixing this second case, which is more likely to be used anyway. BTW, this patch, or at least a predecessor is in -mm, and it very much feels the Right Thing(tm). The /proc/mounts under a chroot environment actually looks sane, instead of some random crap, that it was previously. While we should make every effort to keep the kernel interfaces stable, this shouldn't prevent us from fixing bugs. And this one is clearly a bug, even if not a very serious one. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
