diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2014-09-15 10:51:07 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2014-09-15 10:51:07 -0700 |
commit | d6bb3e9075bbcf758d6084bb581f797bb6ea24c6 (patch) | |
tree | 74f479798ffd366067f249b3f8bcfe876e3affdb /arch | |
parent | 3630056d961593bdf41aaf268c7620d36e635119 (diff) | |
download | linux-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