From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Gregory Price <gregory.price@memverge.com>
Cc: <qemu-devel@nongnu.org>, Michael Tsirkin <mst@redhat.com>,
Ben Widawsky <bwidawsk@kernel.org>, <linux-cxl@vger.kernel.org>,
Huai-Cheng Kuo <hchkuo@avery-design.com.tw>,
Chris Browy <cbrowy@avery-design.com>, <linuxarm@huawei.com>,
<ira.weiny@intel.com>
Subject: Re: [PATCH v7 4/5] hw/mem/cxl-type3: Add CXL CDAT Data Object Exchange
Date: Thu, 13 Oct 2022 11:40:58 +0100 [thread overview]
Message-ID: <20221013114058.00003c8d@huawei.com> (raw)
In-Reply-To: <Y0bk8g2zn2tpUS3a@memverge.com>
On Wed, 12 Oct 2022 12:01:54 -0400
Gregory Price <gregory.price@memverge.com> wrote:
> This code contains heap corruption on free, and I think should be
> refactored to pre-allocate all the entries we're interested in putting
> into the table.
Good point on the heap corruption.. (oops. Particularly as I raised
that I didn't like the complexity of your free in your previous version
and still failed to notice the current code was wrong...)
> This would flatten the code and simplify the error
> handling steps.
I'm not so keen on this. Error handling is pretty trivial because of
the autofree magic. It will get a tiny bit harder once we have
two calls to the factored out function, but not too bad - we just
need to free the handed off pointers in reverse from wherever we
got to before the error.
>
> Also, should we consider making a union with all the possible entries to
> make entry allocation easier? It may eat a few extra bytes of memory,
> but it would simplify the allocation/cleanup code here further.
An interesting point, though gets trickier once we have variable numbers
of elements. I'm not sure it's worth the effort to save a few lines
of code.
>
> Given that every allocation has to be checked, i'm also not convinced
> the use of g_autofree is worth the potential footguns associated with
> it.
After rolling a version with some of your suggested changes incorporated
the autofree logic is all nice and localized so I think it's well worth
having. Only slightly messy bit is we end up with 4 separate pointers
for the bandwidth and latency elements.
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Gregory Price <gregory.price@memverge.com>
Cc: <qemu-devel@nongnu.org>, Michael Tsirkin <mst@redhat.com>,
Ben Widawsky <bwidawsk@kernel.org>, <linux-cxl@vger.kernel.org>,
Huai-Cheng Kuo <hchkuo@avery-design.com.tw>,
Chris Browy <cbrowy@avery-design.com>, <linuxarm@huawei.com>,
<ira.weiny@intel.com>
Subject: Re: [PATCH v7 4/5] hw/mem/cxl-type3: Add CXL CDAT Data Object Exchange
Date: Thu, 13 Oct 2022 11:40:58 +0100 [thread overview]
Message-ID: <20221013114058.00003c8d@huawei.com> (raw)
In-Reply-To: <Y0bk8g2zn2tpUS3a@memverge.com>
On Wed, 12 Oct 2022 12:01:54 -0400
Gregory Price <gregory.price@memverge.com> wrote:
> This code contains heap corruption on free, and I think should be
> refactored to pre-allocate all the entries we're interested in putting
> into the table.
Good point on the heap corruption.. (oops. Particularly as I raised
that I didn't like the complexity of your free in your previous version
and still failed to notice the current code was wrong...)
> This would flatten the code and simplify the error
> handling steps.
I'm not so keen on this. Error handling is pretty trivial because of
the autofree magic. It will get a tiny bit harder once we have
two calls to the factored out function, but not too bad - we just
need to free the handed off pointers in reverse from wherever we
got to before the error.
>
> Also, should we consider making a union with all the possible entries to
> make entry allocation easier? It may eat a few extra bytes of memory,
> but it would simplify the allocation/cleanup code here further.
An interesting point, though gets trickier once we have variable numbers
of elements. I'm not sure it's worth the effort to save a few lines
of code.
>
> Given that every allocation has to be checked, i'm also not convinced
> the use of g_autofree is worth the potential footguns associated with
> it.
After rolling a version with some of your suggested changes incorporated
the autofree logic is all nice and localized so I think it's well worth
having. Only slightly messy bit is we end up with 4 separate pointers
for the bandwidth and latency elements.
next prev parent reply other threads:[~2022-10-13 10:41 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-07 15:21 [PATCH v7 0/5] QEMU PCIe DOE for PCIe 4.0/5.0 and CXL 2.0 Jonathan Cameron
2022-10-07 15:21 ` Jonathan Cameron via
2022-10-07 15:21 ` [PATCH v7 1/5] hw/pci: PCIe Data Object Exchange emulation Jonathan Cameron
2022-10-07 15:21 ` Jonathan Cameron via
2022-10-07 15:21 ` [PATCH v7 2/5] hw/mem/cxl-type3: Add MSIX support Jonathan Cameron
2022-10-07 15:21 ` Jonathan Cameron via
2022-10-07 15:21 ` [PATCH v7 3/5] hw/cxl/cdat: CXL CDAT Data Object Exchange implementation Jonathan Cameron
2022-10-07 15:21 ` Jonathan Cameron via
2022-10-13 11:04 ` Jonathan Cameron
2022-10-13 11:04 ` Jonathan Cameron via
2022-10-07 15:21 ` [PATCH v7 4/5] hw/mem/cxl-type3: Add CXL CDAT Data Object Exchange Jonathan Cameron
2022-10-07 15:21 ` Jonathan Cameron via
2022-10-12 16:01 ` Gregory Price
2022-10-13 10:40 ` Jonathan Cameron [this message]
2022-10-13 10:40 ` Jonathan Cameron via
2022-10-13 10:56 ` Jonathan Cameron
2022-10-13 10:56 ` Jonathan Cameron via
2022-10-12 18:21 ` Gregory Price
2022-10-12 18:21 ` [PATCH 1/5] hw/mem/cxl_type3: fix checkpatch errors Gregory Price
2022-10-12 18:21 ` [PATCH 2/5] hw/mem/cxl_type3: Pull validation checks ahead of functional code Gregory Price
2022-10-13 9:07 ` Jonathan Cameron
2022-10-13 9:07 ` Jonathan Cameron via
2022-10-13 10:42 ` Jonathan Cameron
2022-10-13 10:42 ` Jonathan Cameron via
2022-10-12 18:21 ` [PATCH 3/5] hw/mem/cxl_type3: CDAT pre-allocate and check resources prior to work Gregory Price
2022-10-13 10:44 ` Jonathan Cameron
2022-10-13 10:44 ` Jonathan Cameron via
2022-10-12 18:21 ` [PATCH 4/5] hw/mem/cxl_type3: Change the CDAT allocation/free strategy Gregory Price
2022-10-13 10:45 ` Jonathan Cameron
2022-10-13 10:45 ` Jonathan Cameron via
2022-10-12 18:21 ` [PATCH 5/5] hw/mem/cxl_type3: Refactor CDAT sub-table entry initialization into a function Gregory Price
2022-10-13 10:47 ` Jonathan Cameron
2022-10-13 10:47 ` Jonathan Cameron via
2022-10-13 19:40 ` Gregory Price
2022-10-14 15:29 ` Jonathan Cameron
2022-10-14 15:29 ` Jonathan Cameron via
2022-10-13 8:57 ` [PATCH v7 4/5] hw/mem/cxl-type3: Add CXL CDAT Data Object Exchange Jonathan Cameron
2022-10-13 8:57 ` Jonathan Cameron via
2022-10-13 11:36 ` Gregory Price
2022-10-13 11:53 ` Jonathan Cameron
2022-10-13 11:53 ` Jonathan Cameron via
2022-10-13 12:35 ` Gregory Price
2022-10-13 14:40 ` Jonathan Cameron
2022-10-13 14:40 ` Jonathan Cameron via
2022-10-07 15:21 ` [PATCH v7 5/5] hw/pci-bridge/cxl-upstream: Add a CDAT table access DOE Jonathan Cameron
2022-10-07 15:21 ` Jonathan Cameron via
2022-10-10 10:30 ` [PATCH v7 0/5] QEMU PCIe DOE for PCIe 4.0/5.0 and CXL 2.0 Jonathan Cameron
2022-10-10 10:30 ` Jonathan Cameron via
2022-10-11 9:45 ` Huai-Cheng
2022-10-11 21:19 ` [PATCH 0/5] Multi-Region and Volatile Memory support for CXL Type-3 Devices Gregory Price
2022-10-11 21:19 ` [PATCH 1/5] hw/cxl: set cxl-type3 device type to PCI_CLASS_MEMORY_CXL Gregory Price
2022-10-11 21:19 ` [PATCH 2/5] hw/cxl: Add CXL_CAPACITY_MULTIPLIER definition Gregory Price
2022-10-11 21:19 ` [PATCH 3/5] hw/mem/cxl_type: Generalize CDATDsmas initialization for Memory Regions Gregory Price
2022-10-12 14:10 ` Jonathan Cameron
2022-10-12 14:10 ` Jonathan Cameron via
2022-10-11 21:19 ` [PATCH 4/5] hw/cxl: Multi-Region CXL Type-3 Devices (Volatile and Persistent) Gregory Price
2022-10-11 21:19 ` [PATCH 5/5] cxl: update tests and documentation for new cxl properties Gregory Price
2022-10-11 22:20 ` [PATCH 0/5] Multi-Region and Volatile Memory support for CXL Type-3 Devices Michael S. Tsirkin
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=20221013114058.00003c8d@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=bwidawsk@kernel.org \
--cc=cbrowy@avery-design.com \
--cc=gregory.price@memverge.com \
--cc=hchkuo@avery-design.com.tw \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mst@redhat.com \
--cc=qemu-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.