Messages in this thread | | | Date | Sun, 6 Jun 1999 14:46:31 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: 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/
| |