qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: qemu-devel@nongnu.org, Fan Ni <fan.ni@samsung.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	qemu-trivial@nongnu.org
Subject: Re: [PATCH 3/3] hw/mem/cxl_type3: Fix problem with g_steal_pointer()
Date: Tue, 5 Mar 2024 08:27:52 +0100	[thread overview]
Message-ID: <4f6e1748-a917-4b2b-847d-fbfe04a3e43e@redhat.com> (raw)
In-Reply-To: <20240304151037.00000f6c@Huawei.com>

On 04/03/2024 16.10, Jonathan Cameron wrote:
> On Mon,  4 Mar 2024 11:44:06 +0100
> Thomas Huth <thuth@redhat.com> wrote:
> 
>> When setting GLIB_VERSION_MAX_ALLOWED to GLIB_VERSION_2_58 or higher,
>> glib adds type safety checks to the g_steal_pointer() macro. This
>> triggers errors in the ct3_build_cdat_entries_for_mr() function which
>> uses the g_steal_pointer() for type-casting from one pointer type to
>> the other (which also looks quite weird since the local pointers have
>> all been declared with g_autofree though they are never freed here).
>> Fix it by using a proper typecast instead. For making this possible, we
>> have to remove the QEMU_PACKED attribute from some structs since GCC
>> otherwise complains that the source and destination pointer might
>> have different alignment restrictions. Removing the QEMU_PACKED should
>> be fine here since the structs are already naturally aligned. Anyway,
>> add some QEMU_BUILD_BUG_ON() statements to make sure that we've got
>> the right sizes (without padding in the structs).
> 
> I missed these as well when getting rid of the false handling
> of failure of g_new0 calls.
> 
> Another alternative would be to point to the head structures rather
> than the containing structure - would avoid need to cast.
> That might be neater?  Should I think also remove the alignment
> question?

I gave it a try, but it does not help against the alignment issue, I still get:

../../devel/qemu/hw/mem/cxl_type3.c: In function 
‘ct3_build_cdat_entries_for_mr’:
../../devel/qemu/hw/mem/cxl_type3.c:138:34: error: taking address of packed 
member of ‘struct CDATDsmas’ may result in an unaligned pointer value 
[-Werror=address-of-packed-member]
   138 |     cdat_table[CT3_CDAT_DSMAS] = &dsmas->header;
       |                                  ^~~~~~~~~~~~~~

 From my experience, it's better anyway to avoid __attribute__((packed)) on 
structures unless it is really really required. At least we should avoid it 
as good as possible as long as we still support running QEMU on Sparc hosts 
(that don't support misaligned memory accesses), since otherwise you can end 
up with non-working code there, see e.g.:

  https://www.mail-archive.com/qemu-devel@nongnu.org/msg439899.html

or:

  https://gitlab.com/qemu-project/qemu/-/commit/cb89b349074310ff9eb7ebe18a

Thus I'd rather prefer to keep this patch as it is right now.

  Thomas



  reply	other threads:[~2024-03-05  7:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-04 10:44 [PATCH 0/3] cxl: Fix issues with g_steal_pointer() Thomas Huth
2024-03-04 10:44 ` [PATCH 1/3] hw/cxl/cxl-cdat: Fix type of buf in ct3_load_cdat() Thomas Huth
2024-03-04 14:57   ` Jonathan Cameron via
2024-03-04 10:44 ` [PATCH 2/3] hw/pci-bridge/cxl_upstream: Fix problem with g_steal_pointer() Thomas Huth
2024-03-04 15:06   ` Jonathan Cameron via
2024-03-04 15:12     ` Jonathan Cameron via
2024-03-04 10:44 ` [PATCH 3/3] hw/mem/cxl_type3: " Thomas Huth
2024-03-04 15:10   ` Jonathan Cameron via
2024-03-05  7:27     ` Thomas Huth [this message]
2024-03-05 15:52       ` Jonathan Cameron via
2024-03-08  6:14 ` [PATCH 0/3] cxl: Fix issues " Michael Tokarev

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=4f6e1748-a917-4b2b-847d-fbfe04a3e43e@redhat.com \
    --to=thuth@redhat.com \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=fan.ni@samsung.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    /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).