From: Jesper Nilsson <email@example.com>
To: Arnd Bergmann <firstname.lastname@example.org>
Cc: Lukas Bulwahn <email@example.com>,
Michel Lespinasse <firstname.lastname@example.org>,
Davidlohr Bueso <email@example.com>,
Andrew Morton <firstname.lastname@example.org>,
Mete Polat <email@example.com>,
Jesper Nilsson <firstname.lastname@example.org>,
David Woodhouse <email@example.com>,
Ingo Molnar <firstname.lastname@example.org>,
Peter Zijlstra <email@example.com>,
Randy Dunlap <firstname.lastname@example.org>,
Linux Kernel Mailing List <email@example.com>,
Geert Uytterhoeven <firstname.lastname@example.org>
Subject: Re: [PATCH] rbtree: remove unneeded explicit alignment in struct rb_node
Date: Wed, 11 Aug 2021 00:46:11 +0200 [thread overview]
Message-ID: <YRMBs0FhqFZPDuNP@jni.nu> (raw)
On Thu, Aug 05, 2021 at 04:02:22PM +0200, Arnd Bergmann wrote:
> On Thu, Aug 5, 2021 at 3:32 PM Lukas Bulwahn <email@example.com> wrote:
> > Commit e977145aeaad ("[RBTREE] Add explicit alignment to sizeof(long) for
> > struct rb_node.") adds an explicit alignment to the struct rb_node due to
> > some speciality of the CRIS architecture.
> > The support for the CRIS architecture was removed with commit c690eddc2f3b
> > ("CRIS: Drop support for the CRIS port")
> > So, remove this now unneeded explicit alignment in struct rb_node as well.
> > This basically reverts commit e977145aeaad ("[RBTREE] Add explicit
> > alignment to sizeof(long) for struct rb_node.").
> > Reported-by: Randy Dunlap <firstname.lastname@example.org>
> > Reported-by: Mete Polat <email@example.com>
> > Signed-off-by: Lukas Bulwahn <firstname.lastname@example.org>
> > ---
> > applies cleanly on next-20210804, but only x86 compile-checked.
> > Michel, Davidlohr, Jesper, David, please ack.
> > Mete, you might want to re-run your RBT test suite for this change.
> > Andrew, once acked, please pick this minor cleanup into your tree.
> Do you know why it needed the extra alignment on cris at the time?
The problem for CRIS was that the architecture always had packed
structs (there was no way to avoid it in GCC) and CRIS could all data
on any byte boundary.
That was ok for normal pointers in structs, all pointers would be allocated
inside the same page and it didn't matter that they were aligned on odd byte
addresses for the CPU (except for being a little slower)
However, when the lowest bits were used as flags, that would clash on CRIS since
all bits were valid and possible address bits, so any sub-struct in a struct might be
aligned on an odd address, and using the pointer to the sub-struct would inadvertently
set the flag bits.
That's why just adding a forced alignment on the sub-struct fixed the problem,
since the compiler would respect such alignments, and thus leave the lower bits
free for trickery.
> 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.
/^JN - Jesper Nilsson
Jesper Nilsson -- jesper_at_jni.nu
prev parent reply other threads:[~2021-08-10 23:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-05 13:32 [PATCH] rbtree: remove unneeded explicit alignment in struct rb_node Lukas Bulwahn
2021-08-05 14:02 ` Arnd Bergmann
2021-08-05 14:14 ` Lukas Bulwahn
2021-08-05 15:02 ` Davidlohr Bueso
2021-08-05 15:10 ` Peter Zijlstra
2021-08-05 17:20 ` Mete Polat
2021-08-06 8:52 ` Michel Lespinasse
2021-08-06 11:57 ` Peter Zijlstra
2021-08-10 22:46 ` Jesper Nilsson [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).