linux-ext4 - Re: [PATCH 5 2/4] Return 32/64-bit dir name hash according to usage type

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 24 Apr 2012 16:28:20 -0500
From:	Andreas Dilger <adilger@...mcloud.com>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Bernd Schubert <bernd.schubert@...m.fraunhofer.de>,
	linux-ext4@...r.kernel.org, Fan Yong <yong.fan@...mcloud.com>,
	bfields@...hat.com
Subject: Re: [PATCH 5 2/4] Return 32/64-bit dir name hash according to usage type

On 2012-04-24, at 2:21 PM, Eric Sandeen wrote:
> I know I'm being a little pedantic w/ the late review here....
> 
> It seems like the only differences between ext4_dir_llseek and the old ext4_llseek are these:
> 
> 1) For SEEK_END, we now return -EINVAL for a positive offset (i.e. past EOF)
> 2) For SEEK_END, we seek to ext4_get_htree_eof() not to inode->i_size
> 3) For SEEK_SET, we impose different limits for max offset
>  - s_maxbytes / ext4_get_htree_eof for !dx/dx, vs. s_bitmap_maxbytes/s_maxbytes
> 
> Do any of these changes relate to the hash collision problem?  Are any of them uniquely required for ext4, enough to warrant cut & paste of the vfs llseek code (again?)
> 
> What I'm getting at is: what are the reasons that we cannot use generic_file_llseek_size(), maybe with a new argument to specify a non-standard location for SEEK_END.  Such a change would require a solid explanation, but it'd probably go in if it meant one less seek implementation to worry about.

So, when we were looking at this code, it makes sense that if dir seek is being done for telldir/seekdir that the parameters for ext4 are hash functions, so they should be compared against hash limits instead of the file size.

This probably makes sense for other filesystems that use hash cookies instead of byte offsets to have a similar dir seek implementation, but I thought there might be a controversy about this and I'm happy to get it into ext4 as a starting point.

Cheers, Andreas
--
Andreas Dilger                       Whamcloud, Inc.
Principal Lustre Engineer            http://www.whamcloud.com/




--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html