[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/public: fix flexible array definitions


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Juergen Gross <jgross@xxxxxxxx>
  • Date: Thu, 30 Nov 2023 10:21:44 +0100
  • Authentication-results: smtp-out2.suse.de; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=suse.com (policy=quarantine); spf=fail (smtp-out2.suse.de: domain of jgross@xxxxxxxx does not designate 2a07:de40:b281:104:10:150:64:97 as permitted sender) smtp.mailfrom=jgross@xxxxxxxx
  • Autocrypt: addr=jgross@xxxxxxxx; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNH0p1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmNvbT7CwHkEEwECACMFAlOMcK8CGwMH CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCw3p3WKL8TL8eZB/9G0juS/kDY9LhEXseh mE9U+iA1VsLhgDqVbsOtZ/S14LRFHczNd/Lqkn7souCSoyWsBs3/wO+OjPvxf7m+Ef+sMtr0 G5lCWEWa9wa0IXx5HRPW/ScL+e4AVUbL7rurYMfwCzco+7TfjhMEOkC+va5gzi1KrErgNRHH kg3PhlnRY0Udyqx++UYkAsN4TQuEhNN32MvN0Np3WlBJOgKcuXpIElmMM5f1BBzJSKBkW0Jc Wy3h2Wy912vHKpPV/Xv7ZwVJ27v7KcuZcErtptDevAljxJtE7aJG6WiBzm+v9EswyWxwMCIO RoVBYuiocc51872tRGywc03xaQydB+9R7BHPzsBNBFOMcBYBCADLMfoA44MwGOB9YT1V4KCy vAfd7E0BTfaAurbG+Olacciz3yd09QOmejFZC6AnoykydyvTFLAWYcSCdISMr88COmmCbJzn sHAogjexXiif6ANUUlHpjxlHCCcELmZUzomNDnEOTxZFeWMTFF9Rf2k2F0Tl4E5kmsNGgtSa aMO0rNZoOEiD/7UfPP3dfh8JCQ1VtUUsQtT1sxos8Eb/HmriJhnaTZ7Hp3jtgTVkV0ybpgFg w6WMaRkrBh17mV0z2ajjmabB7SJxcouSkR0hcpNl4oM74d2/VqoW4BxxxOD1FcNCObCELfIS auZx+XT6s+CE7Qi/c44ibBMR7hyjdzWbABEBAAHCwF8EGAECAAkFAlOMcBYCGwwACgkQsN6d 1ii/Ey9D+Af/WFr3q+bg/8v5tCknCtn92d5lyYTBNt7xgWzDZX8G6/pngzKyWfedArllp0Pn fgIXtMNV+3t8Li1Tg843EXkP7+2+CQ98MB8XvvPLYAfW8nNDV85TyVgWlldNcgdv7nn1Sq8g HwB2BHdIAkYce3hEoDQXt/mKlgEGsLpzJcnLKimtPXQQy9TxUaLBe9PInPd+Ohix0XOlY+Uk QFEx50Ki3rSDl2Zt2tnkNYKUCvTJq7jvOlaPd6d/W0tZqpyy7KVay+K4aMobDsodB3dvEAs6 ScCnh03dDAFgIq5nsB11j3KPKdVoPlfucX2c7kGNH+LUMbzqV6beIENfNexkOfxHfw==
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Thu, 30 Nov 2023 09:21:48 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 30.11.23 09:24, Jan Beulich wrote:
On 29.11.2023 12:58, Juergen Gross wrote:
On 09.08.23 11:42, Juergen Gross wrote:
On 26.07.23 07:52, Jan Beulich wrote:
On 25.07.2023 18:59, Andrew Cooper wrote:
On 25/07/2023 5:16 pm, Jan Beulich wrote:
On 25.07.2023 15:55, Juergen Gross wrote:
Flexible arrays in public headers can be problematic with some
compilers.

Replace them with arr[XEN_FLEX_ARRAY_DIM] in order to avoid compilation
errors.

This includes arrays defined as "arr[1]", as seen with a recent Linux
kernel [1].

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=217693

Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
I think we need to be careful here: What if someone somewhere applies
sizeof() to any of the types you alter?

Then the code was most likely wrong already.

That's possible to judge only when seeing the code in question.

   The resulting value would
change with the changes you propose, which we cannot allow to happen
in a stable interface. Therefore imo it can only be an opt-in feature
to have these arrays no longer be one-element ones.

I don't consider this an issue.

If people take an update to the headers and their code stops compiling,
then of course they fix the compilation issue.  That's normal.

The code may continue to compile fine, and even appear to work initially.

It's unreasonable to take opt-in features to a set of headers intended
to be vendored in the first place, to work around a corner case that's
likely buggy already.

The original intention clearly was to allow use of these headers as is.
Anyway, I've voiced my view, yet if there are enough people agreeing
with you, then so be it.

Any further thoughts?

I have checked the code in the Linux kernel meanwhile. There should be no
fallout resulting from this change, but I think there are some user mode
backends outside of qemu which are probably using affected structs.

I've received another mail regarding the report [1] above. I think we should
_really_ come to a conclusion.

I'm still in favor of applying my suggested patch.

I think the change would be fine to make when adjusted to be conditional
upon (suitably bumped) __XEN_LATEST_INTERFACE_VERSION__.

Okay, fine with me.

Yet while looking at the patch and the headers again, it also looks as if
there might be another small issue: ring.h uses XEN_FLEX_ARRAY_DIM without
itself including xen.h. That's probably okay considering that all headers
including ring.h also include grant_table.h (which in turn includes xen.h),
but this dependency may still want making explicit.

Yes, I'll add that.

Finally - is the change actually going to help everywhere (not just in
Linux)? It effectively depends on people enabling C99 mode. Older gcc for
example didn't even define __STDC_VERSION__ when -std wasn't used. Linux
doesn't permit use of such old gcc versions anymore, but recall we're
aiming to be C89 compatible. Therefore I think that in addition we'd need
a way for consumers of the headers to indicate that the C99 form of
XEN_FLEX_ARRAY_DIM can be used even when __STDC_VERSION__ isn't defined.
(This may as well simply be done by allowing people to pre-define
XEN_FLEX_ARRAY_DIM before including any Xen headers.)

Will the problem even occur with such an old gcc? I don't think so, as only
rather recent compilers showed the "array out of bounds" failure. Otherwise
we would have heard complaints much earlier.

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.