From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Thomas Huth <thuth@redhat.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 15:52:18 +0000 [thread overview]
Message-ID: <20240305155218.00000c00@Huawei.com> (raw)
In-Reply-To: <4f6e1748-a917-4b2b-847d-fbfe04a3e43e@redhat.com>
On Tue, 5 Mar 2024 08:27:52 +0100
Thomas Huth <thuth@redhat.com> wrote:
> 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
Fair enough.
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
>
next prev parent reply other threads:[~2024-03-05 15:53 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
2024-03-05 15:52 ` Jonathan Cameron via [this message]
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=20240305155218.00000c00@Huawei.com \
--to=qemu-devel@nongnu.org \
--cc=Jonathan.Cameron@Huawei.com \
--cc=fan.ni@samsung.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=qemu-trivial@nongnu.org \
--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).