linux-kernel - Re: [GIT PULL] ext4 bug fixes for 3.18

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141101133802.GA31245@thunk.org>
Date:	Sat, 1 Nov 2014 09:38:02 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [GIT PULL] ext4 bug fixes for 3.18

On Fri, Oct 31, 2014 at 04:26:16PM -0700, Linus Torvalds wrote:
> On Fri, Oct 31, 2014 at 2:49 PM, Theodore Ts'o <tytso@....edu> wrote:
> >
> > Theodore Ts'o (1):
> >       jbd2: use a better hash function for the revoke table
> 
> Does it really make sense to use hash_u64()? It can be quite expensive
> (mainly on 32-bit targets), and since the low bits are where all the
> information is anyway, I'd suggest using hash_32() here even if the
> block number in theory can have a few bits above the 32-bit mark.

Hmm... the problem is that since the block group size is normally
32768 blocks, and most metadata blocks (which is what needs to be
revoked) is located at the beginning of the block groups, if we drop
the high 32-bits, then there would be some hash aliasing going on.

What we could do is use hash_32() unless we have a file system large
enough that it matters, and then if we still wanted to avoid using
hash_u64(), we could do something like this:

	hash_32(__swab32(blk >> 32) | (blk & 0xFFFFFFFF))

That way we get the information from the block group number as well,
and in a way where it doesn't interfere with the information in the
low bits of the block number.

I didn't think hash_64 was *that* slow, so it's not clear the above
would be faster, though.  And if someone is using a > 16TB file system
on a 32-bit platform, I suspect they might be having other problems.  :-)

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/