On Tue, 13 Jun 2000, Alexander Viro <viro@math.psu.edu> wrote:
[...]
> a) open(name, O_CREAT, foo) is the *only* namespace-modifying
> operation that follows broken symlinks.
That seems fine.
[...]
> c) suppose we restore this insane semantics and somehow decide on
> procfs-style links. Fine, but then we have a nice set of kernel races
> to deal with. We follow the broken link. We need to lock the parent.
> During that time target might 1) become a file or directory. Fine. 2)
> become a (possibly broken) symlink. Desired behaviour? 3) become
> positive, be renamed away and there be removed. We are _deep_ in it,
> since the name of dentry might silently change under us with no
> evidence of such event. Moreover, if there is an evidence (parent had
> been changed) we either need to repeat the lookup or drop the lock on
> old parent and acquire the lock on new one. Lather, rinse, repeat. 4)
> be renamed over. Repeat lookup? It is unhashed now... .....
>
> If we repeat lookups we have to deal with possibility that symlink had
> been changed/removed - we have slept. There also is a slew of other
> funny races to deal with and the whole thing makes JCL look elegant in
> comparison.
I think that, if the kernel can be race-free internally, then exposing
the mess that can result to userspace is a fine and happy thing to do.
As a developer, I don't expect operations through symlinks to be atomic
WRT the rest of the system.
Following that logic, creating files through a symlink makes sense, but
I don't expect that to be race-free WRT the target of the symlink.
> Variants with follow_link() giving us parent + name of last component
> are also interesting due to procfs-style links. Same (even in worse
> form) goes for textual substitution of readlink() result.
>
> I really wonder whether we need this crapload of races at all.
The assumption that O_CREAT works through symlinks is build deeply into
XEmacs. Very deeply, in fact, and Linux 2.4 would be the only Unix-like
system where this was *not* possible to do (even if the risk of userland
races existed).
As an end-user of the code, I would like to see the old behavior - which
I freely admit to be insane in a number of fundamental ways - to be
restored. I know that XEmacs breaks if I run 2.4 on my machine - I don't
know what else makes these assumptions...
Thanks for looking at this (and putting up with bitching about it in
good grace :)
Daniel
--
You are more than the sum of what you consume.
Desire is not an occupation.
-- KMFDF, _Dogma_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:28 EST