Messages in this thread | | | Date | Fri, 10 Apr 1998 01:36:21 -0400 | From | Peeter Joot <> | Subject | Re: patch: new sysctl to remove hardcoded ELOOP limit |
| |
>I didn't see the original patch, but I don't think it's a good idea to make >ELOOP variable.The reason that there's a hard-coded limit in the first place >is that symlink traversal uses >recursion, and the kernel stack has a hard-coded limit. In addition, it's not >that easy to >figure out worst-case stack usage, since you don't know what various file >systems may >need to do to resolve symlinks. > >Hence a hard-coded safe limit is called for here.
Hi Bill,
Having made the original patch myself I have a favourable bias towards it. I did have a valid need at one point for it being slightly higher(only by one in fact), and didn't really want to have to recompile a kernel and reboot to fix it, since I was at work at the time, and had a number of things on the go at the time.
Those are my reasons for thinking that it should be dynamically configurable. When I got home later I coded up a patch that would have allowed me not to have had to do this.
However, David Todd mentioned that he thought max_symlinks should be an unsigned int. I didn't think there was too much point to this because if it was set to some low (positive) number such as 0, or 1 then you would still be in trouble.
I think that the best solution is to allow ELOOP to be variable, but to additionally implement some sort of bounds checking functionality for sysctl parameters where possible and desirable. Then make the bounds hard-coded safe limits.
Peeter
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |