On Wed, Apr 01, 2009 at 07:28:14AM +1100, Greg Banks wrote:
> Improve the hash function to handle clients which increment the XID
> in the unexpected byte order, by folding down the top bits of the XID.
I'm confused; maybe my arithemtic's wrong, but:
>
> Signed-off-by: Greg Banks <gnb@xxxxxxx>
> ---
>
> fs/nfsd/nfscache.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> Index: bfields/fs/nfsd/nfscache.c
> ===================================================================
> --- bfields.orig/fs/nfsd/nfscache.c
> +++ bfields/fs/nfsd/nfscache.c
> @@ -35,12 +35,15 @@ static struct list_head lru_head;
> static int cache_disabled = 1;
>
> /*
> - * Calculate the hash index from an XID.
> + * Calculate the hash index from an XID. Note, some clients increment
> + * their XIDs in host order, which can result in all the variation being
> + * in the top bits we see here. So we fold those bits down.
> */
> static inline u32 request_hash(u32 xid)
> {
> u32 h = xid;
> h ^= (xid >> 24);
This xor's the highest 8 bits into the lowest 8 bits; so the
higest-order bits are already being "folded down".
> + h ^= ((xid & 0xff0000) >> 8);
This just folds those same bits down into the order 16-23 bits. Does
that help?
> return h & (HASHSIZE-1);
Especially when we're only taking the bottom few (6, currently) bits
anyway?
--b.
> }
>
>
> --
> Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
