aboutsummaryrefslogtreecommitdiffstats
path: root/COPYING
diff options
context:
space:
mode:
authorJeff Layton <jlayton@poochiereds.net>2014-05-02 13:50:02 -0400
committerSteve French <smfrench@gmail.com>2014-05-21 10:18:04 -0700
commit02323db17e3a73dd335690b7b1a2392912b05513 (patch)
tree24a6b832587ad960bd0da9af7a3f22e7826135e9 /COPYING
parentLinux 3.15-rc6 (diff)
downloadlinux-dev-02323db17e3a73dd335690b7b1a2392912b05513.tar.xz
linux-dev-02323db17e3a73dd335690b7b1a2392912b05513.zip
cifs: fix cifs_uniqueid_to_ino_t not to ever return 0
Currently, when the top and bottom 32-bit words are equivalent and the host is a 32-bit arch, cifs_uniqueid_to_ino_t returns 0 as the ino_t value. All we're doing to hash the value down to 32 bits is xor'ing the top and bottom 32-bit words and that obviously results in 0 if they are equivalent. The kernel doesn't really care if it returns this value, but some userland apps (like "ls") will ignore dirents that have a zero d_ino value. Change this function to use hash_64 to convert this value to a 31 bit value and then add 1 to ensure that it doesn't ever return 0. Also, there's no need to check the sizeof(ino_t) at runtime so create two different cifs_uniqueid_to_ino_t functions based on whether BITS_PER_LONG is 64 for not. This should fix: https://bugzilla.kernel.org/show_bug.cgi?id=19282 Reported-by: Eric <copet_eric@emc.com> Reported-by: <per-ola@sadata.se> Signed-off-by: Jeff Layton <jlayton@poochiereds.net> Signed-off-by: Steve French <smfrench@gmail.com>
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions