public inbox for linux-cifs@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: linux-cifs@vger.kernel.org
Cc: Paulo Alcantara <palcantara@suse.de>,
	Aurelien Aptel <aaptel@suse.com>,
	Steve French <stfrench@microsoft.com>,
	linux-fsdevel@vger.kernel.org
Subject: broken hash use in fs/cifs/dfs_cache.c
Date: Mon, 22 Mar 2021 17:48:29 +0000	[thread overview]
Message-ID: <YFjYbftTAJdO+LNg@zeniv-ca.linux.org.uk> (raw)

	Found while trying to untangle some... unidiomatic string handling
in cifs:

static struct cache_entry *__lookup_cache_entry(const char *path)
{
        struct cache_entry *ce;
        unsigned int h;
        bool found = false;

        h = cache_entry_hash(path, strlen(path));

        hlist_for_each_entry(ce, &cache_htable[h], hlist) {
                if (!strcasecmp(path, ce->path)) {
                        found = true;
                        dump_ce(ce);
                        break;
                }
        }

        if (!found)
                ce = ERR_PTR(-ENOENT);
        return ce;
}

combined with

static inline unsigned int cache_entry_hash(const void *data, int size)
{
        unsigned int h;

        h = jhash(data, size, 0);
        return h & (CACHE_HTABLE_SIZE - 1);
}

That can't possibly work.  The fundamental requirement for hashes is that
lookups for all keys matching an entry *MUST* lead to searches in the same
hash chain.  Here the test is strcasecmp(), so "foo" and "Foo" are expected
to match the same entry.  But jhash() yields different values on those -
it's a general-purpose hash, and it doesn't give a damn about upper and
lower case letters.  Moreover, even though we look at the value modulo
32, I don't believe that it's going to be case-insensitive.

Either the key comparison or the hash function is wrong here.  *IF* something
external guarantees the full match, we don't need strcasecmp() - strcmp()
would work.  Otherwise, the hash function needs to be changed.

             reply	other threads:[~2021-03-22 17:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-22 17:48 Al Viro [this message]
2021-03-22 18:23 ` broken hash use in fs/cifs/dfs_cache.c Paulo Alcantara
2021-03-22 18:38 ` Aurélien Aptel
2021-03-22 20:23   ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YFjYbftTAJdO+LNg@zeniv-ca.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=aaptel@suse.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=palcantara@suse.de \
    --cc=stfrench@microsoft.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox