Messages in this thread | | | Date | Mon, 13 Feb 2006 09:20:02 +0100 | From | Helge Hafting <> | Subject | Re: 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/
| |