Messages in this thread |  | | | Date | Wed, 13 Jan 1999 00:05:50 -0500 (EST) | | From | Alexander Viro <> | | Subject | Re: Should we have MAXSYMLINKS? |
| |
On Tue, 12 Jan 1999, H.J. Lu wrote:
> Hi, > > I got this. Should glibc/linux have MAXSYMLINKS? > > -- > H.J. Lu (hjl@gnu.org) > > --- > If you have not already done so, please add a definition for the constant > MAXSYMLINKS to the <sys/param.h> file, define it to some appropriate value > (FreeBSD uses 32), and then please try to get the kernel developers to use > it in all places where they are trying to decide when to stop chasing down > a chain of symlinks.
Looks like we already have it. Depending on what you mean, that is. If you are concerned about number of nested symlinks (traversed without eating new components of name) - it's 5. There is only one place where it is checked - see fs/namei.c::do_follow_links() for details. Limit is mostly due to our implementation of lookups. Linux doesn't use nameidata and thus symlink lookups are recursive. Kernel stack is limited... If you are after *total* number of symlinks traversed during a lookup - no such limit. IIRC, 4.4BSD doesn't limit it too (well, aside of the limitations on path length). It *does* use nameidata, so the limit is larger than our.
- 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/
|  |