lkml.org 
[lkml]   [1999]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ELOOP help needed


On Sun, 6 Jun 1999, Matthew Kirkwood wrote:

> 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.024 / U:1.632 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site