linux-kernel - Re: [Stratos-dev] [PATCH V3 1/3] gpio: Add virtio-gpio driver

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-next>] [day] [month] [year] [list]

Message-ID: <CAK8P3a2-bXfDcPymMct2aUXs2m+YgbKdmAatMMs9tnc+HjS_xQ@mail.gmail.com>
Date:   Fri, 11 Jun 2021 10:34:31 +0200
From:   Arnd Bergmann <arnd@...aro.org>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Stefan Hajnoczi <stefanha@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Viresh Kumar <vireshk@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        virtualization@...ts.linux-foundation.org,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Stratos Mailing List <stratos-dev@...lists.linaro.org>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        Jason Wang <jasowang@...hat.com>,
        "Stefano Garzarella --cc virtualization @ lists . linux-foundation . org" 
        <sgarzare@...hat.com>
Subject: Re: [Stratos-dev] [PATCH V3 1/3] gpio: Add virtio-gpio driver

On Fri, Jun 11, 2021 at 5:39 AM Viresh Kumar via Stratos-dev
<stratos-dev@...lists.linaro.org> wrote:
> On 10-06-21, 19:40, Jean-Philippe Brucker wrote:
> > On Thu, Jun 10, 2021 at 12:16:46PM +0000, Viresh Kumar via Stratos-dev wrote:

> > > +} __packed;
> >
> > No need for __packed, because the fields are naturally aligned (as
> > required by the virtio spec)
>
> Yeah, I know, but I tend to add that for structures which aren't very
> simple (like the request/response ones), just to avoid human errors
> and hours of debugging someone need to go through. __packed won't harm
> at least :)

Extraneous __packed annotations do cause real problems:

- On architectures without hardware unaligned accesses, the compiler is
  forced to emit byte load/store instructions, which is slower and breaks
  atomic updates to shared variables

- If a function takes a pointer of a packed struct member, and passes that
  pointer to a function that expects a regular aligned pointer, you
get undefined
  behavior. Newer compilers produce a warning if you do that (we currently
  shut up that warning because there are many false positives in the kernel),
  but you can also run into CPU exceptions or broken code even on CPUs
  that do support unaligned accesses when the variable ends up being
  actually unaligned (as you just told the compiler that it is allowed to do).

      Arnd