linux-kernel - Re: [bp:tip-x86-alternatives 1/1] error[E0588]: packed type cannot transitively contain a `#[repr(align)]` type

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]

Message-ID: <CANiq72mZ3d-W53o4iFryouRKkHkdyR=_qBWkMGm1aNd8Y9ZSnQ@mail.gmail.com>
Date:   Sat, 7 Jan 2023 00:26:38 +0100
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Alexander Altman <alexanderaltman@...com>
Cc:     Borislav Petkov <bp@...en8.de>, kernel test robot <lkp@...el.com>,
        llvm@...ts.linux.dev, oe-kbuild-all@...ts.linux.dev,
        rust-for-linux@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [bp:tip-x86-alternatives 1/1] error[E0588]: packed type cannot
 transitively contain a `#[repr(align)]` type

On Tue, Dec 27, 2022 at 9:31 PM Alexander Altman <alexanderaltman@...com> wrote:
>
> One way to resolve this temporarily would be to add the following line above
> the offending struct:
> /// <div rustbindgen hide></div>
> This will cause bindgen to ignore the struct entirely and not translate it.  If it’s
> actually needed for Rust code, now or later, then we can’t do that and need
> to actually replace it with something translatable, or else leave it hidden and
> manually create its translation on the Rust side.  For the latter, just using a
> u32 for the entire bitfield-containing union would be sufficient.

Thanks a lot Alexander for taking a look!

This is https://github.com/rust-lang/rust-bindgen/issues/2179.

What we do for constructs that `bindgen` cannot map is to add the
appropriate parameter/line in `rust/bindgen_parameters`. We hit a
similar case for `x86_msi_data` that you can see in that file. So
please feel free to add it there.

If we end up needing to access it from the Rust side, another
alternative is to write a C function that performs the required
operation on it that then the Rust side calls.

Cheers,
Miguel