lkml.org 
[lkml]   [2006]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: max symlink = 5? ?bug? ?feature deficit?
Willy Tarreau wrote:

>On Sun, Feb 12, 2006 at 04:54:23PM -0800, Linda Walsh wrote:
>
>
>>Al Viro wrote:
>>
>>
>>>On Sun, Feb 12, 2006 at 02:54:33PM -0800, Linda Walsh wrote:
>>>
>>>
>>>
>>>>Al Viro wrote:
>>>>
>>>>
>>>>
>>>>>Care to RTFS? I mean, really - at least to the point of seeing what's
>>>>>involved in that recursion.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>Hmmm...that's where I got the original parameter numbers, but
>>>>I see it's not so straightforward. I tried a limit of
>>>>40, but I quickly get an OS hang when trying to reference a
>>>>13th link. Twelve works at the limit, but would take more testing
>>>>to find out the bottleneck.
>>>>
>>>>
>>>>
>>>Sigh... 12 works at the limit on your particular config, filesystems
>>>being used and syscall being issued (hint: amount of stuff on stack
>>>before we enter mutual recursion varies; so does the amount of stuff
>>>on stack we get from function that are not part of mutual recursion,
>>>but are called from the damn thing).
>>>
>>>
>>>
>>---
>> Yeah, I sorta figured that. Is there any easier way to
>>remove the recursion? I dunno about you, but I was always taught
>>that recursion, while elegant, was not always the most efficient in
>>terms of time and space requirements and one could get similar
>>functionality using iteration and a stack.
>>
>>
>
>I don't know exactly why recursion is used to follow symlinks,
>which at first thought seems like it could be iterated, but
>I've not checked the code, there certainly are specific reasons
>for this. However, there's often an alternative to recursion, it
>consists in implementing a local stack onto the stack. I mean,
>
>
Sometimes, there are better ways than implementing your
own stack. For example, not having any kind of stack.
That means memory usage don't increase with the number of
chained symlinks.

>when you need recursion, it is because you want to be able to
>get back to where you were previously (eg: try another branch
>in a tree).
>
Yes, but what if we don't need the ability to go back?

Consider this approach to symlinks:
1. We have a path component to resolve
2. It turns out to be a symlink. So look it up, then
loop back to (1)

This goes on until what we find isn't a symlink, or till some
overflow counter decides that we probably have a symlink loop.
With no memory of where we came from, there is no
recursive use of memory. And no way of going back in
single steps, but I assume that isn't necessary here.
I could be wrong about that though.

Helge Hafting





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-02-13 09:17    [W:0.048 / U:0.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site