On Mon, Jul 9, 2018 at 7:49 AM Greg KH <greg@xxxxxxxxx> wrote:
> On Mon, Jul 09, 2018 at 07:44:44AM +0300, Alexey Brodkin wrote:
> > Depending on ABI "long long" type of a particular 32-bit CPU
> > might be aligned by either word (32-bits) or double word (64-bits).
Or even 16-bit (on e.g. m68k).
> > --- a/drivers/base/devres.c
> > +++ b/drivers/base/devres.c
> > @@ -24,8 +24,12 @@ struct devres_node {
> >
> > struct devres {
> > struct devres_node node;
> > - /* -- 3 pointers */
> > - unsigned long long data[]; /* guarantee ull alignment */
> > + /*
> > + * Depending on ABI "long long" type of a particular 32-bit CPU
> > + * might be aligned by either word (32-bits) or double word (64-bits).
or even 16-bit (on e.g. m68k).
> > + * Make sure "data" is really 64-bit aligned for any 32-bit CPU.
> > + */
> > + unsigned long long data[] __aligned(sizeof(unsigned long long));
> > };
>
> Does this change the padding today for any other arches? If so, does
> the increased memory usage cause any noticable issues?
Yes it does. struct devres_node contains an odd number of pointers, so
there will be a hole between node and data on all 32-bit architectures.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
