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]
Date:	Tue, 02 Nov 2010 05:46:15 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Dave Chinner <david@...morbit.com>
Cc:	viro@...IV.linux.org.uk, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: Re: [PATCH 3/3] fs: rcu protect inode hash lookups

Le mardi 02 novembre 2010 à 11:01 +1100, Dave Chinner a écrit :

> So, to go to per-chain locks as per the proposed bit-lock-on-the-
> low-bit-of-the-head-pointer infrastructure, we'll have to cross that
> with the hlist_null code that plays low-bit pointer games for
> detecting the end of the chain.
> 

So what, just use another bit for the lock, this still let 30 bit for
the nulls value (62 bits on 64bit arches). Anyway, the bit lock is
rejected by RT guys, so why do you still care ?


> The chain is determined by hashing the inode number. Perhaps a
> simple enough test is to hash the last inode number on a cache miss
> and if that doesn't match the hash of the lookup key we redo the
> search. That seems to me like it will avoid needing to play games
> with termination markers - does that sound reasonable?
> 

Sure, if only the inode number is the key, it can be fetched in atomic
way so it should be good, even without taking a stable reference on last
item. It could be a problem if i_ino becomes a larger field...

Note : you'll have to remember the last item i_ino in a variable, not to
refetch it from a 'last item' pointer (this last item could also change
its chain...)

For TCP, hash key is a complex hash function of many fields needing to
take a reference before computing it, this was not an option.



--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ