[PATCH] symlink 1/9: infrastructure and explanation
This patch-kit gets past the limit on nested symlinks, without incompatible API changes _and_ with killing code duplication in most of the readlink/follow_link pairs. And no, it's not the old ->getlink() crap - procfs et.al. are not special-cased there. Here's how it works: * ->follow_link() still does what it used to do - replaces vfsmount/dentry in the nameidata it got from caller. However, it can also leave a pathname to be resolved by caller. * we add an array of char * into nameidata; we always work with nd->saved_names[current->link_count]. nd_set_link() sets it, nd_get_link() returns it. * callers of ->follow_link() (all two of them) check if ->follow_link() had left us something to do. If it had (return value was zero and nd_get_link() is non-NULL), they do __vfs_follow_link() on that name. Then they call a new method (->put_link()) that frees whatever has to be freed, etc. Note that absolute majority of symlinks have "resolve a pathname" as part of their ->follow_link(); they can do something else and some don't do that at all, but having that pathname resolution is very, very common. With that change we allow them to shift pathname resolution part to caller. They don't have to - it's perfectly OK to do all work in ->follow_link(). However, leaving the pathname resolution to caller will a) exclude foo_follow_link() stack frame from the picture b) kill 2 stack frames - all callers are in fs/namei.c and they can use inlined variant of vfs_follow_link(). That reduction of stack use is enough to push the limit on nested symlinks from 5 to 8 (actually, even beyond that, but since 8 is common for other Unices it will do fine). For those who have "pure" ->follow_link() (i.e. "find a string that would be symlink contents and say nd_set_link(nd, string)") we also get a common helper implementing ->readlink() - it just calls ->follow_link() on a dummy nameidata, calls vfs_readlink() on result of nd_get_link() and does ->put_link(). Using (or not using) it is up to filesystem; it's a helper that can be used as a ->readlink() for many filesystems, not a reimplementation of sys_readlink(). However, that's _MANY_ filesystems - practically all of them. Note that we don't put any crap like "if this is a normal symlink, do this; otherwise call ->follow_link() and let it do its magic" into callers - all symlinks are handled the same way. Which was the main problem with getlink proposal back then. That covers almost everything; the only cases left are nfs, ncpfs and cifs. Those will go later - we are backwards compatible, so it's not a problem. First patch: infrastructure - helpers allowing ->follow_link() to leave a pathname to be traversed by caller + corresponding code in callers.
Showing
Please register or sign in to comment