This is the readme file for tsi.symlink.diff.gz which has been uploaded to
ftp://ftp.lmh.ox.ac.uk/incoming.
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.
At this writing, I am reluctant to submit this change for inclusion in a Linux
2.x kernel. But I am making it available so that others can "have a go at it".
My remaining concerns with this change are:
- follow_link is a fairly central part of VFS, and thus any change to
it needs thorough testing.
- There is some question in my mind as to what priority should be used
in allocating the pages used for the stack. For now, I use
GFP_KERNEL.
- Under certain circumstances, current kernels can treat pathnames
ending in "/" differently than those ending in "/.". This change
eliminates this discrepancy by treating both endings the same as "/".
- There is potential for current kernels to treat an inode differently
depending on whether or not it is accessed through a symlink. This
is because the part of open_namei after the follow_link call is often
redundantly and/or unnecessarily executed. Although my change
reduces such redundancy, it does not completely eliminate it.
The last two points deal with open_namei, and are not large concerns, but could
become so if open_namei is ever changed without regard for these
considerations.
Replies welcome.
Marc.
+----------------------------------+-----------------------------------+
| Marc Aurele La France | work: 1-403-492-9310 |
| Computing and Network Services | fax: 1-403-492-1729 |
| 352 General Services Building | email: tsi@ualberta.ca |
| University of Alberta +-----------------------------------+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply |
| CANADA | |
+----------------------------------+-----------------------------------+