Re: [RFC] readlink()-related oddities

On Fri, Nov 20, 2015 at 09:59:05AM +, David Howells wrote: > There's an AFS userspace command that could be used to query a mountpoint that > was going to use it. However, I suspect readlink() will now always trigger > the automount. It won't, actually. All we are passing to

Re: [RFC] readlink()-related oddities

Al Viro wrote: > All of them? I see two kinds there - one is magical symlink (recognized > by contents in afs_iget()), another is this autocell thing, the latter > having no ->readlink(). Both serve as automount points, don't they? The "autocell" thing is where you don't have an AFS file of

Re: [RFC] readlink()-related oddities

On Fri, Nov 20, 2015 at 09:59:05AM +, David Howells wrote: > Al Viro wrote: > > > 3) normally, readlink(2) fails for non-symlinks. Moreover, according to > > POSIX it should do so (with -EINVAL). There is a pathological case when > > it succeeds for a directory, though. Namely, one of the

Re: [RFC] readlink()-related oddities

Al Viro wrote: > How would those tools know that this particular pathname _is_ a magical > symlink? Sure, if you see a symlink with body that starts with % or #, > you could figure out that it's not a regular one and go parse the body, > but for stat(2) it looks like a directory. Do those

Re: [RFC] readlink()-related oddities

Al Viro wrote: > 3) normally, readlink(2) fails for non-symlinks. Moreover, according to > POSIX it should do so (with -EINVAL). There is a pathological case when > it succeeds for a directory, though. Namely, one of the kinds of AFS > "mountpoints". All AFS mountpoints are magic symlinks

Re: [RFC] readlink()-related oddities

Al Viro wrote: > 3) normally, readlink(2) fails for non-symlinks. Moreover, according to > POSIX it should do so (with -EINVAL). There is a pathological case when > it succeeds for a directory, though. Namely, one of the kinds of AFS > "mountpoints". All AFS

Re: [RFC] readlink()-related oddities

Al Viro wrote: > How would those tools know that this particular pathname _is_ a magical > symlink? Sure, if you see a symlink with body that starts with % or #, > you could figure out that it's not a regular one and go parse the body, > but for stat(2) it looks like a

Re: [RFC] readlink()-related oddities

Al Viro wrote: > All of them? I see two kinds there - one is magical symlink (recognized > by contents in afs_iget()), another is this autocell thing, the latter > having no ->readlink(). Both serve as automount points, don't they? The "autocell" thing is where you

Re: [RFC] readlink()-related oddities

On Fri, Nov 20, 2015 at 09:59:05AM +, David Howells wrote: > Al Viro wrote: > > > 3) normally, readlink(2) fails for non-symlinks. Moreover, according to > > POSIX it should do so (with -EINVAL). There is a pathological case when > > it succeeds for a directory,

Re: [RFC] readlink()-related oddities

On Fri, Nov 20, 2015 at 09:59:05AM +, David Howells wrote: > There's an AFS userspace command that could be used to query a mountpoint that > was going to use it. However, I suspect readlink() will now always trigger > the automount. It won't, actually. All we are passing to

Re: [RFC] readlink()-related oddities

On Thu, Nov 19, 2015 at 07:16:32PM -0800, Linus Torvalds wrote: > .. it's not necessarily just readlink() either. I still think it might > be a perfectly fine idea to allow non-directories to act as > directories in some case (by exposing "readdir" and "lookup"). As soon as we expose ->lookup(),

Re: [RFC] readlink()-related oddities

On Thu, Nov 19, 2015 at 7:09 PM, Linus Torvalds wrote: > > So there is *potential* for just making it generic, but that doesn't > mean that it necessarily has to act that way. .. it's not necessarily just readlink() either. I still think it might be a perfectly fine idea to allow non-directories

Re: [RFC] readlink()-related oddities

On Thu, Nov 19, 2015 at 6:57 PM, Al Viro wrote: > > How would those tools know that this particular pathname _is_ a magical > symlink? Like maybe just the AFS management tools? By design you'd only run them on the mountpoint in question. Not everything has to be "generic". Sometimes its' good

Re: [RFC] readlink()-related oddities

On Thu, Nov 19, 2015 at 06:13:53PM -0800, Linus Torvalds wrote: > > 3) normally, readlink(2) fails for non-symlinks. Moreover, according to > > POSIX it should do so (with -EINVAL). > > I don't think POSIX is necessarily relevant here. > > We have had magic file behavior outside the scope of

Re: [RFC] readlink()-related oddities

On Thu, Nov 19, 2015 at 3:26 PM, Al Viro wrote: > > 1) atime updates, according to POSIX, should happen in case of success. > For example, giving readlink(2) an unmapped buffer should _not_ touch > atime. Neither should calling readlink(2) in case if ->readlink() method > returns e.g. -EIO or

[RFC] readlink()-related oddities

I'd been looking through ->readlink() callers, and there are several areas where behaviour looks wrong. 1) atime updates, according to POSIX, should happen in case of success. For example, giving readlink(2) an unmapped buffer should _not_ touch atime. Neither should calling readlink(2)

[RFC] readlink()-related oddities

I'd been looking through ->readlink() callers, and there are several areas where behaviour looks wrong. 1) atime updates, according to POSIX, should happen in case of success. For example, giving readlink(2) an unmapped buffer should _not_ touch atime. Neither should calling readlink(2)

Re: [RFC] readlink()-related oddities

On Thu, Nov 19, 2015 at 3:26 PM, Al Viro wrote: > > 1) atime updates, according to POSIX, should happen in case of success. > For example, giving readlink(2) an unmapped buffer should _not_ touch > atime. Neither should calling readlink(2) in case if ->readlink() method

Re: [RFC] readlink()-related oddities

On Thu, Nov 19, 2015 at 06:13:53PM -0800, Linus Torvalds wrote: > > 3) normally, readlink(2) fails for non-symlinks. Moreover, according to > > POSIX it should do so (with -EINVAL). > > I don't think POSIX is necessarily relevant here. > > We have had magic file behavior outside the scope of

Re: [RFC] readlink()-related oddities

On Thu, Nov 19, 2015 at 7:09 PM, Linus Torvalds wrote: > > So there is *potential* for just making it generic, but that doesn't > mean that it necessarily has to act that way. .. it's not necessarily just readlink() either. I still think it might be a perfectly

Re: [RFC] readlink()-related oddities

On Thu, Nov 19, 2015 at 6:57 PM, Al Viro wrote: > > How would those tools know that this particular pathname _is_ a magical > symlink? Like maybe just the AFS management tools? By design you'd only run them on the mountpoint in question. Not everything has to be

Re: [RFC] readlink()-related oddities

On Thu, Nov 19, 2015 at 07:16:32PM -0800, Linus Torvalds wrote: > .. it's not necessarily just readlink() either. I still think it might > be a perfectly fine idea to allow non-directories to act as > directories in some case (by exposing "readdir" and "lookup"). As soon as we expose ->lookup(),