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:   Thu, 5 Aug 2021 19:20:26 +0200
From:   Mete Polat <metepolat2000@...il.com>
To:     Davidlohr Bueso <dbueso@...e.de>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Michel Lespinasse <michel@...pinasse.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mete Polat <metepolat2000@...il.com>,
        Jesper Nilsson <jesper@....nu>,
        David Woodhouse <dwmw2@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        kernel-janitors@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH] rbtree: remove unneeded explicit alignment in struct
 rb_node

On Thu, Aug 05, 2021 at 08:02:28AM -0700, Davidlohr Bueso wrote:
> On 2021-08-05 07:02, Arnd Bergmann wrote:
> > The revert would appear to change the alignment to 16 bits instead
> > of 32 bits on m68k as well (not 8 bits as on cris), but I don't know if
> > that
> > can cause problems there.
> 
> Yeah I tried this a while back and it broke m68k, so it was a no go:
> 
> https://lore.kernel.org/lkml/CAMuHMdXeZvJ0X6Ah2CpLRoQJm+YhxAWBt-rUpxoyfOLTcHp+0g@mail.gmail.com/

The problem is that the field '__rb_parent_color' in struct rb_node is
storing the color AND the pointer to the parent node at the same time.
The color is stored in the least significant bit which is fine when
rb_node is at least 16-bit aligned. I guess, it does not work on m68k
because the makro

#define __rb_parent(pc)    ((struct rb_node *)(pc & ~3))

used to retrieve the parent pointer zeros the first two bits, not only
the first one.

Maybe the effiency to store this one color bit in another field was
required in the early days but I think moving the color to a seperate
field is really the better way to go. It also makes reasoning about the
algorithm easier.

I will create a patch.

Mete
> 
> Thanks, Davidlohr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ