[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1337012674.8512.589.camel@edumazet-glaptop>
Date: Mon, 14 May 2012 18:24:34 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Hans Schillstrom <hans.schillstrom@...csson.com>
Cc: Jan Engelhardt <jengelh@...i.de>,
Pablo Neira Ayuso <pablo@...filter.org>,
"kaber@...sh.net" <kaber@...sh.net>,
"jengelh@...ozas.de" <jengelh@...ozas.de>,
"netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"dan.carpenter@...cle.com" <dan.carpenter@...cle.com>,
"hans@...illstrom.com" <hans@...illstrom.com>
Subject: Re: [PATCH] netfilter: xt_HMARK: endian bugs
On Mon, 2012-05-14 at 18:09 +0200, Hans Schillstrom wrote:
> This context can contain both le & be machines,
> so at least in hmark it make sense
Before jhash() and its shuffle ? What do you mean ?
Please respin your patch using (__force u16/u32) instead of
useless/expensive ntohs() / ntohl() (in _this_ context of hashing)
If you compare two 32bits values, of course they must have same
ordering, but seeding jhash() is another matter.
(Granted all calls use the same ordering of course)
sparse is great tool, but if you add useless ntohl() calls to make
sparse silent, then its probably better to not use sparse.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists