Messages in this thread |  | | Date | Tue, 11 Jun 1996 22:38:11 -0600 (MDT) | From | Marc Aurele La France <> | Subject | [Take II] Eliminating symlink recursion |
| |
Good day!
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 | | +----------------------------------+-----------------------------------+
|  |