linux-kernel - Re: [PATCH anybus v3 4/6] bus: support HMS Anybus-S bus

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:   Sat, 10 Nov 2018 11:55:42 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     thesven73@...il.com, svendev@...x.com,
        Rob Herring <robh+dt@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Lee Jones <lee.jones@...aro.org>,
        Mark Rutland <mark.rutland@....com>,
        Andreas Färber <afaerber@...e.de>,
        Thierry Reding <treding@...dia.com>,
        David Lechner <david@...hnology.com>,
        Noralf Trønnes <noralf@...nnes.org>,
        Johan Hovold <johan@...nel.org>,
        Michal Simek <monstr@...str.eu>, michal.vokac@...ft.com,
        Greg KH <gregkh@...uxfoundation.org>,
        John Garry <john.garry@...wei.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Robin Murphy <robin.murphy@....com>,
        Paul Gortmaker <paul.gortmaker@...driver.com>,
        sebastien.bourdelin@...oirfairelinux.com, icenowy@...c.io,
        stuyoder@...il.com, Maxime Ripard <maxime.ripard@...tlin.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH anybus v3 4/6] bus: support HMS Anybus-S bus

On Fri, Nov 9, 2018 at 10:03 PM Arnd Bergmann <arnd@...db.de> wrote:
> On Fri, Nov 9, 2018 at 5:25 PM Sven Van Asbroeck <thesven73@...il.com> wrote:
> > On Thu, Nov 8, 2018 at 9:07 AM Arnd Bergmann <arnd@...db.de> wrote:
> > > > +struct anybus_mbox_hdr {
> > > > +       u16 id;
> > > > +       u16 info;
> > > > +       u16 cmd_num;
> > > > +       u16 data_size;
> > > > +       u16 frame_count;
> > > > +       u16 frame_num;
> > > > +       u16 offset_high;
> > > > +       u16 offset_low;
> > > > +       u16 extended[8];
> > > > +} __packed;
> > >
> > > I don't think you want this to be __packed, it won't change the layout
> > > but instead force byte accesses on architectures that don't have
> > > fast unaligned load/store instructions.
> > >
> > > Instead of the __packed, it's almost always better to ensure that
> > > the structure itself is aligned to a 16-bit address.
> > >
> >
> > A general question about __packed.
> >
> > My current understanding is this:
> > (please tell me if it's incorrect or incomplete)
> >
> > + without __packed, the compiler is free to pad the struct in whatever
> > way it feels is best.
> > + with __packed, the fields have to be laid out EXACTLY as specified.
>
> It's not up to the compiler but the ELF ABI. The rules are largely consisten
> among the architectures we support, but there are a couple of notable
> exceptions:
>
> - ARM OABI requires 32-bit alignment for structures
> - x86-32 aligns 64-bit members to 32-bit rather than 64-bit
> - m68k has some oddities, I think they can pack certain
>   members (don't remember the details)

M68k aligns 16-bit and larger members to 16-bit.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

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