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  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, 6 Nov 2007 15:25:58 +0100
From:	Jarek Poplawski <jarkao2@...pl>
To:	jamal <hadi@...erus.ca>
Cc:	Radu Rendec <radu.rendec@...s.ro>, netdev@...r.kernel.org
Subject: Re: Endianness problem with u32 classifier hash masks

On Tue, Nov 06, 2007 at 08:34:31AM -0500, jamal wrote:
> On Tue, 2007-06-11 at 10:09 +0200, Radu Rendec wrote:
> 
> > Yup, you're right. Bitwise anding is the same regardless of the byte
> > ordering of the operands. As long as you don't have one operand in host
> > order and the other in net order, it's ok.
> 
> Ok
> 
> > However, Jarek's computations with his mask and your patch seemed
> > correct to me yesterday. And I think I know the answer: data must be
> > changed to host order _before_ shifting. I mean something like this:
> > 
> > static __inline__ unsigned u32_hash_fold(u32 key, struct tc_u32_sel
> > *sel, u8 fshift)
> > {
> >        unsigned h = ntohl(key & sel->hmask) >> fshift;
> >        return h;
> > }
> 
> Even better than what i suggested ;->

Yes, it saves one htonl() on the slow path!

> 
> > > > On paper i get the same result with the new or old scheme for the bucket selection.
> > > > As i stated on the patch - i never did test the theory.
> > 
> > Well, neither did I (about what I stated above). But still I think,
> > Jarek was right yesterday and I can't figure out how it worked for you
> > on paper. How about this new version?
> 
> Looks good - we can think of optimizing later.
> 
> > Well, I think it's pretty clear now: I'll try my version of Jamal's
> > patch :) 
> 
> Which derived from your original patch using little effort in comparison
> to yours. All the hardwork is yours.
> You did quiet an impressive debug work. Please give yourself a little
> pat on the back for me.

Wait a minute! Don't forget to take a picture or something!

> 
> > But not right now, because I also have to show up at work.
> 
> I empathize. 
> Please send two patches instead of one. One for this and the next for
> the ffs conversion (please run some simple tests in both cases).
> 
> Jarek,
> Heres a few more derivations of Canada for you:
> 
> Legend has it that Canada's name is derived from  
> "settlement" in Iroquoian (One the First Nations in present day Canada).
> I think it was pronounced "Kanata"
> An alternative legend says the early Spanish called it acánada  meaning
> "nothing here"
> 
> I tend to believe the Iroquoian version since to this day Canada
> continues to serve as a new settlement for many people. And the Spanish
> were totaly wrong - there is something here ;-> At least Tim Hortons
> coffee.

Nice stories! Thanks. Btw, with this Polish saying, the strangest thing
is US was always preferred as a settlment, after all.

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

Powered by blists - more mailing lists