I have re-uploaded this change to ftp://ftp.lmh.ox.ac.uk/incoming. This
version addresses concerns over limiting kernel data space the change
needs and the repeatability of symlink-to-inode translations over time.
What follows is the new readme.
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. To address kernel data space utilization concerns, a new
limit is introduced that defines the maximum number of symlinks that the kernel
may follow before returning an ELOOP error. This new limit is a compilation
option and defaults to 32. The new limit can also be disabled entirely or set
to 0 to disable symlinks entirely. If it is disabled, the effective limit
depends on the amount of kernel data space remaining at any particular point in
time.
I am making this change 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.
- 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 | |
+----------------------------------+-----------------------------------+