Re: max symlink = 5? ?bug? ?feature deficit?

[Helge Hafting <helge.hafting@aitel.hist.no>]

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