On Tue, May 25, 2010 at 12:01:09AM +0100, Al Viro wrote: > Client question: what stops you from stack overflows in that area? Call > chains you've got are *deep*, and I really wonder what happens if you > hit a referral point while traversing nested symlink, get pathname > resolution (already several levels into recursion) call ->follow_link(), > bounce down through nfs_do_refmount/nfs_follow_referral/try_location/ > vfs_kern_mount/nfs4_referral_get_sb/nfs_follow_remote_path into > vfs_path_lookup, which will cheerfully add a few more loops like that. > > Sure, the *total* nesting depth through symlinks is still limited by 8, but > that pile of stack frames is _MUCH_ fatter than what we normally have in > pathname resolution. You've suddenly added ~60 extra stack frames to the > worst-case stack footprint of the pathname resolution. Don't try that > on sparc64, boys and girls, it won't be happy with attempt to carve ~12Kb > extra out of its kernel stack... In fact, it's worse than just ~60 stack > frames - several will contain (on-stack) struct nameidata in them, which > very definitely will _not_ fit into the minimal stack frame. It's about > 160 bytes extra, for each of those (up to 7). Actually, just what will happen if you have a referral that would eventually resolve to a directory you have no permissions to access? AFAICS, you'll end up trying it on all alternates, since nfs_follow_referral() will cheerfully keep trying one variant after another, getting -EACCES from each. Worse, if there are nested referrals in it, you'll get all sequences of alternates tried before you give up. ..o*O(at least it's merely exponential; Ackermann would be even more fun) -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
