kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Thomas Huth <thuth@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>,
	kvm@vger.kernel.org, Andrew Jones <drjones@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>
Cc: linux-s390@vger.kernel.org, borntraeger@de.ibm.com,
	frankja@linux.ibm.com
Subject: Re: strict aliasing in kvm-unit-tests (was: Re: [kvm-unit-tests PATCH v8 6/6] s390x: SCLP unit test)
Date: Wed, 22 Jan 2020 15:42:38 +0100	[thread overview]
Message-ID: <aa3c6235-7a9e-d7c5-bd9d-974f2b947992@redhat.com> (raw)
In-Reply-To: <ddf083a3-7d29-ca78-0fd9-e7e3c38e0f04@redhat.com>

On 22/01/20 15:15, Thomas Huth wrote:
> On 22/01/2020 13.16, Thomas Huth wrote:
>> On 22/01/2020 11.40, David Hildenbrand wrote:
>>> On 22.01.20 11:39, Thomas Huth wrote:
>>>> On 22/01/2020 11.32, David Hildenbrand wrote:
>>>>> On 22.01.20 11:31, Thomas Huth wrote:
>>>>>> On 22/01/2020 11.22, David Hildenbrand wrote:
>>>>>>> On 22.01.20 11:10, David Hildenbrand wrote:
>> [...]
>>>>>>>> Doing a fresh ./configure + make on RHEL7 gives me
>>>>>>>>
>>>>>>>> [linux1@rhkvm01 kvm-unit-tests]$ make
>>>>>>>> gcc  -std=gnu99 -ffreestanding -I /home/linux1/git/kvm-unit-tests/lib -I /home/linux1/git/kvm-unit-tests/lib/s390x -I lib -O2 -march=zEC12 -fno-delete-null-pointer-checks -g -MMD -MF s390x/.sclp.d -Wall -Wwrite-strings -Wempty-body -Wuninitialized -Wignored-qualifiers -Werror  -fomit-frame-pointer    -Wno-frame-address   -fno-pic    -Wclobbered  -Wunused-but-set-parameter  -Wmissing-parameter-type  -Wold-style-declaration -Woverride-init -Wmissing-prototypes -Wstrict-prototypes   -c -o s390x/sclp.o s390x/sclp.c
>>>>>>>> s390x/sclp.c: In function 'test_one_simple':
>>>>>>>> s390x/sclp.c:121:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
>>>>>>>>   ((SCCBHeader *)sccb_template)->length = sccb_len;
>>>>>>>>   ^
>>>>>>>> s390x/sclp.c: At top level:
>>>>>>>> cc1: error: unrecognized command line option "-Wno-frame-address" [-Werror]
>>>>>>>> cc1: all warnings being treated as errors
>>>>>>>> make: *** [s390x/sclp.o] Error 1
>>>>>>>
>>>>>>> The following makes it work:
>>>>>>>
>>>>>>>
>>>>>>> diff --git a/s390x/sclp.c b/s390x/sclp.c
>>>>>>> index c13fa60..0b8117a 100644
>>>>>>> --- a/s390x/sclp.c
>>>>>>> +++ b/s390x/sclp.c
>>>>>>> @@ -117,8 +117,10 @@ static bool test_one_ro(uint32_t cmd, uint8_t *addr, uint64_t exp_pgm, uint16_t
>>>>>>>  static bool test_one_simple(uint32_t cmd, uint8_t *addr, uint16_t sccb_len,
>>>>>>>                         uint16_t buf_len, uint64_t exp_pgm, uint16_t exp_rc)
>>>>>>>  {
>>>>>>> +       SCCBHeader *header = (void *)sccb_template;
>>>>>>> +
>>>>>>>         memset(sccb_template, 0, sizeof(sccb_template));
>>>>>>> -       ((SCCBHeader *)sccb_template)->length = sccb_len;
>>>>>>> +       header->length = sccb_len;
>>>>>>
>>>>>> While that might silence the compiler warning, we still might get
>>>>>> aliasing problems here, I think.
>>>>>> The right way to solve this problem is to turn sccb_template into a
>>>>>> union of the various structs/arrays that you want to use and then access
>>>>>> the fields through the union instead ("type-punning through union").
>>>>>
>>>>> We do have the exact same thing in lib/s390x/sclp.c already, no?
>>>>
>>>> Maybe we should carefully check that code, too...
>>>>
>>>>> Especially, new compilers don't seem to care?
>>>>
>>>> I've seen horrible bugs due to these aliasing problems in the past -
>>>> without compiler warnings showing up! Certain versions of GCC assume
>>>> that they can re-order code with pointers that point to types of
>>>> different sizes, i.e. in the above example, I think they could assume
>>>> that they could re-order the memset() and the header->length = ... line.
>>>> I'd feel better if we play safe and use a union here.
>>>
>>> Should we simply allow type-punning?
>>
>> Maybe yes. The kernel also compiles with "-fno-strict-aliasing", and
>> since kvm-unit-tests is mainly a "playground" for people who do kernel
>> development, too, we should maybe also compile the unit tests with
>> "-fno-strict-aliasing".
>>
>> Paolo, Andrew, Laurent, what do you think?

I think enabling -fno-strict-aliasing is a good idea.

Paolo


  reply	other threads:[~2020-01-22 14:42 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-20 18:42 [kvm-unit-tests PATCH v8 0/6] s390x: SCLP Unit test Claudio Imbrenda
2020-01-20 18:42 ` [kvm-unit-tests PATCH v8 1/6] s390x: export sclp_setup_int Claudio Imbrenda
2020-01-20 18:42 ` [kvm-unit-tests PATCH v8 2/6] s390x: sclp: add service call instruction wrapper Claudio Imbrenda
2020-01-20 18:42 ` [kvm-unit-tests PATCH v8 3/6] s390x: lib: fix stfl wrapper asm Claudio Imbrenda
2020-01-21  6:15   ` Thomas Huth
2020-01-21  9:17   ` David Hildenbrand
2020-01-21 12:42   ` Janosch Frank
2020-01-20 18:42 ` [kvm-unit-tests PATCH v8 4/6] s390x: lib: add SPX and STPX instruction wrapper Claudio Imbrenda
2020-01-20 18:42 ` [kvm-unit-tests PATCH v8 5/6] s390x: lib: fix program interrupt handler if sclp_busy was set Claudio Imbrenda
2020-01-21  6:19   ` Thomas Huth
2020-01-21  9:18   ` David Hildenbrand
2020-01-20 18:42 ` [kvm-unit-tests PATCH v8 6/6] s390x: SCLP unit test Claudio Imbrenda
2020-01-22  9:55   ` David Hildenbrand
2020-01-22 10:10   ` David Hildenbrand
2020-01-22 10:22     ` David Hildenbrand
2020-01-22 10:31       ` Thomas Huth
2020-01-22 10:32         ` David Hildenbrand
2020-01-22 10:39           ` Thomas Huth
2020-01-22 10:40             ` David Hildenbrand
2020-01-22 11:20               ` David Hildenbrand
2020-01-22 12:13                 ` Thomas Huth
2020-01-22 12:16               ` Thomas Huth
2020-01-22 14:15                 ` strict aliasing in kvm-unit-tests (was: Re: [kvm-unit-tests PATCH v8 6/6] s390x: SCLP unit test) Thomas Huth
2020-01-22 14:42                   ` Paolo Bonzini [this message]
2020-01-22 15:01                     ` Laurent Vivier
2020-01-22  9:55 ` [kvm-unit-tests PATCH v8 0/6] s390x: SCLP Unit test David Hildenbrand
2020-01-22 10:02   ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aa3c6235-7a9e-d7c5-bd9d-974f2b947992@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=drjones@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=lvivier@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).