Supporting deeper symbolic links

Posted Jul 1, 2004 12:31 UTC (Thu) by nathan (subscriber, #3559)
Parent article: Supporting deeper symbolic links

Why can the recursion not be turned into iteration? There must be something
else going on that I'd like to know about.

to post comments

Supporting deeper symbolic links

Posted Jul 1, 2004 14:40 UTC (Thu) by jeremiah (subscriber, #1221) [Link] (5 responses)

It does seem kinda strange, that the stack would grow at all. You only care about the start point and the end point, not the actual path you took to get there. Why wouldn't you just discard the most of the path as you went along?

Supporting deeper symbolic links

Posted Jul 1, 2004 19:22 UTC (Thu) by bronson (guest, #4806) [Link] (3 responses)

I agree. Applying a tail recursion optimization seems an obvious solution!

Does anybody know why this isn't an option?

adjusting the problem vs fixing it

Posted Jul 2, 2004 3:25 UTC (Fri) by giraffedata (guest, #1954) [Link]

Given that the lookup does not fail gracefully if you run out of stack (behavior is undefined), there really ought to be a more formal control on the amount of stack space used. Just saying, "About 5 should be safe" is not adequate, and lowering the stack usage and saying, "now 8 should probably be OK" is shamelessly perpetuating the problem.

Requiring the filesystem code and VFS code to be so intimately familiar with each other's use of stack space to avoid crashing the kernel is asking too much.

I too would expect an iteration to be the right fix. But if that's not practical, then the limit should be on the amount of stack space left, not the number of times a symbolic link has been followed. And it's actually cleaner to check how much stack space is left than to do the count. The code today doesn't do pure recursion; it has a special global (per-process) variable (current->link_count) it uses to determine when this particular recursion has hit its limit.

Supporting deeper symbolic links

Posted Jul 2, 2004 3:54 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

Think about /usr/bin/gcc where /usr is symlink to /mnt/somewhere/else and then ../bin/.. part is symlink as well and gcc too is symlink...

Now please about that tail recusion thingy again if you can. Heh.

Unfortunatelly you do care about path - just not path you though about...

As "track for stack usage" - it'll be nightmare to administer: sometimes you can compile this program but if b-tree in filesystem is changed somewhat you're suddenly can not do it. Gosh.

Supporting deeper symbolic links

Posted Jul 5, 2004 16:15 UTC (Mon) by jschrod (subscriber, #1646) [Link]

char real_name [path_max+1] = "";
char *s = link_name;
char *path_elem;
while ( path_elem = strstr(s, '/') ) {
    char r [path_max+1] = strcpy(real_name);
    int size;
    strcat(r, "/");
    strcat(r, path_elem);
    while ( (size = readlink(r, real_name)) != -1 ) {
        real_name[size] = NUL;
    }
    if ( size != EINVAL ) do_error_handling();
    s = NULL;
}

No recursion, mom. (Not tested either... :-) Add a few overflow checks, please. And exchange libc functions by kernel ones. But none of them need dynamic memory, so there is no stack issue.

Cheers, Joachim

Supporting deeper symbolic links

Posted Jul 2, 2004 9:59 UTC (Fri) by joern (guest, #22392) [Link]

Remember -ELOOP?