summaryrefslogtreecommitdiffstats
path: root/arch
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2014-09-15 10:51:07 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2014-09-15 10:51:07 -0700
commitd6bb3e9075bbcf758d6084bb581f797bb6ea24c6 (patch)
tree74f479798ffd366067f249b3f8bcfe876e3affdb /arch
parent3630056d961593bdf41aaf268c7620d36e635119 (diff)
downloadlinux-d6bb3e9075bbcf758d6084bb581f797bb6ea24c6.tar.bz2
vfs: simplify and shrink stack frame of link_path_walk()
Commit 9226b5b440f2 ("vfs: avoid non-forwarding large load after small store in path lookup") made link_path_walk() always access the "hash_len" field as a single 64-bit entity, in order to avoid mixed size accesses to the members. However, what I didn't notice was that that effectively means that the whole "struct qstr this" is now basically redundant. We already explicitly track the "const char *name", and if we just use "u64 hash_len" instead of "long len", there is nothing else left of the "struct qstr". We do end up wanting the "struct qstr" if we have a filesystem with a "d_hash()" function, but that's a rare case, and we might as well then just squirrell away the name and hash_len at that point. End result: fewer live variables in the loop, a smaller stack frame, and better code generation. And we don't need to pass in pointers variables to helper functions any more, because the return value contains all the relevant information. So this removes more lines than it adds, and the source code is clearer too. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions