> On Sun, 6 Jun 1999, Lou Grinzo wrote:
>
> > I'm trying to track down a specific detail about how Linux handles
> > circular link references. I know that certain system calls will return
> > [-]ELOOP when this condition is detected, but I need a little more
> > information:
> >
> > I've seen descriptions that say only a certain number of links will be
> > followed before Linux will assume it has a circular reference and give
> > up and return ELOOP. Is this true? If so, what's the limit? Is the
> > limit hard- coded, or can it be overridden programmatically?
>
> It's hard-coded. Apparently, go much higher than 5 and the kernel stack
> can overflow.
I've found a decent way to do it and I'll submit a patch this evening.
Startegy:
a) new method - k_readlink() and new field in struct inode -
i_link.
b) if i_link is non-NULL readlink() and follow_link() assume that
it contains the name in question and do a generic thing.
c) if it is NULL and k_readlink() is present we are grabbing
i_sem, check i_link (we might sleep in process) and if it's still NULL
we call k_readlink(), which must set the i_link. Then we release i_sem and
do a generic thing.
d) if it is NULL and k_readlink() is NULL too we are falling back
to the current strategy. It's the case only for /proc/self and
/proc/<pid>/* symlinks where we don't get any recursion anyway.
e) for symlink inodes clear_inode() should include appropriate
releasing of the i_link memory/buffer_head/whatever. We store the relevant
data in fs-specific part of inode.
It works and I want to test it a bit locally before posting the
thing on l-k/l-fsdevel for public testing.
Later,
Al
-
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/