Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

2007-04-17 Thread Alan Cox
> For /proc/mounts, one could argue that the admin might want to see > everything, > but then that's not actually true even today because /proc/mounts doesn't > show lazyily unmounted stuff or mounts from other namespaces, so that > everything is quite relative. The current state is not good e

Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

2007-04-16 Thread Rob Meijer
On Mon, April 16, 2007 23:57, Alan Cox wrote: >> > That is a fairly significant and sudden change to the existing >> > kernel/user interface. >> >> Well, this is not meant for 2.6.21. I hope it is possible to change it >> in >> early 2.6.22; otherwise if we can't fix mistakes from the past we are >

Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

2007-04-16 Thread Andreas Gruenbacher
On Monday 16 April 2007 23:57, Alan Cox wrote: > I don't believe the existing behaviour _IS_ a mistake. So what would be the arguments why this behavior makes sense, other than legacy? For /proc/mounts, one could argue that the admin might want to see everything, but then that's not actually tr

Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

2007-04-16 Thread Alan Cox
> > That is a fairly significant and sudden change to the existing > > kernel/user interface. > > Well, this is not meant for 2.6.21. I hope it is possible to change it in > early 2.6.22; otherwise if we can't fix mistakes from the past we are pretty > doomed. I don't believe the existing behav

Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

2007-04-15 Thread Andreas Gruenbacher
On Thursday 12 April 2007 11:58, Alan Cox wrote: > > Third, sys_getcwd() shouldn't return disconnected paths. The patch checks for > > that, and makes it fail with -ENOENT in that case > > That is a fairly significant and sudden change to the existing > kernel/user interface. Well, this is not

Re: [AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

2007-04-12 Thread Alan Cox
> Third, sys_getcwd() shouldn't return disconnected paths. The patch checks for > that, and makes it fail with -ENOENT in that case That is a fairly significant and sudden change to the existing kernel/user interface. > Fourth, this now allows us to tell unreachable mount points from reachable >

[AppArmor 31/41] Fix __d_path() for lazy unmounts and make it unambiguous; exclude unreachable mount points from /proc/mounts

2007-04-12 Thread jjohansen
First, when d_path() hits a lazily unmounted mount point, it tries to prepend the name of the lazily unmounted dentry to the path name. It gets this wrong, and also overwrites the slash that separates the name from the following pathname component. Second, it isn't always possible to tell from th