lkml.org 
[lkml]   [1998]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.090 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site