[lkml]   [1996]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Eliminating symlink recursion
On Tue, 4 Jun 1996, Ingo Molnar wrote:

> > All Linux kernels so far resolve symbolic links recursively. To
> > prevent kernel stack page overflows, most file systems limit the
> > recursion level to 5. This limit also means that the kernel does not
> > need to deal with symbolic link loops because these will eventually
> > exceed the limit.

> > This change introduces a rewrite of VFS's follow_link function to
> > eliminate recursion and detect symlink loops. This is done in such a
> > way that changes to the FS layer itself are not required, although a
> > "cleanup" change wouldn't hurt after this change has been suitably
> > tested.

> > This new follow_link uses a stack-like data structure to keep track of
> > symlink inodes it visits and partial pathnames that still need to be
> > resolved. This data structure resides in kernel data space and grows
> > and shrinks (in PAGE_SIZE chunks) as required. Thus the new limit
> > depends on the amount of kernel data space remaining at any particular
> > point in time.

> I find your idea is cool. I have one (small) observation. Any
> unlimited automatic kernel-memory allocation is a potential "deny of
> service" attack. You should limit the maximum depth of symbolic links.
> Pages allocated with GFP_KERNEL are >not< swappable. They are a very
> valuable resource. (the kmalloc call might just sleep, to wait >for<
> swapping activities to finish, but the pages dont swap after this). I
> dont know what the limit should be, but I guess you will get other
> comments from the list.

You raise a valid concern. It appears, from a quick perusal of the
source, that no kernel data space page is swappable, regardless of
priority. But I don't have an answer yet, as I need to ruminate this one
for a bit.



| Marc Aurele La France | work: 1-403-492-9310 |
| Computing and Network Services | fax: 1-403-492-1729 |
| 352 General Services Building | email: |
| University of Alberta +-----------------------------------+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply |
| CANADA | |

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