netdev - Re: Endianness problem with u32 classifier hash masks

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: <20071105135246.GB1933@ff.dom.local>
Date:	Mon, 5 Nov 2007 14:52:46 +0100
From:	Jarek Poplawski <jarkao2@...pl>
To:	Radu Rendec <radu.rendec@...s.ro>
Cc:	jamal <hadi@...erus.ca>, netdev@...r.kernel.org
Subject: Re: Endianness problem with u32 classifier hash masks

On Mon, Nov 05, 2007 at 02:59:21PM +0200, Radu Rendec wrote:
...
> Jamal, I am aware that any computation on the fast path involves some
> performance loss. However, I don't see any speed gain with your patch,
> because you just moved the ntohl() call inside u32_hash_fold(). Since
> u32_hash_fold() is called unconditionally and the only call is that one
> in u32_classify(), htohl() will be called exactly the same number of
> times.

It seems this performance loss shouldn't be so big because ntohl()
is probably quite well optimized in assembler. But, as I've written,
since there is max. 1 byte meaningful to us there is some additional
possibility to get it other way, but I doubt it's worth to bother,
and this can be done with some later patch, after all.

> 
> After almost a week of dealing with this, I still don't think it can be
> solved without byte re-ordering. If you guys think my patch is good, I
> would be more than glad to send it properly (change the comments as
> Jarek suggested and use git). Since I'm quite a newbie with git and
> haven't worked with kernel maintainers before, please be patient if it's
> not perfect at the first attempt :) What tree/branch should I make the
> patch against?

If we manage to convince Jamal, IMHO a patch to something current like
2.6.24-rc1-git14 (or maybe -rc2 soon), should suffice (plus some
options to diff to get function names etc. eg.: diff -Nurp). Try with
Documentation/SubmittingPatches. Git isn't necessary at all. And don't
forget about a changelog.

Regards,
Jarek P.
-
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