From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>,
"Stefano Stabellini" <sstabellini@kernel.org>,
Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 2/3] x86/ucode: Fix cache handling in microcode_update_helper()
Date: Mon, 18 Nov 2024 08:45:24 +0100 [thread overview]
Message-ID: <de8c88d4-5b79-41eb-955a-d015ef94aa15@suse.com> (raw)
In-Reply-To: <babfdcb5-c23f-4a18-b1bb-52026f9bf2f7@citrix.com>
On 15.11.2024 19:03, Andrew Cooper wrote:
> On 14/11/2024 11:26 am, Jan Beulich wrote:
>> On 12.11.2024 22:19, Andrew Cooper wrote:
>>> microcode_update_cache() now has a single caller, but inlining it shows how
>>> unnecessarily complicated the logic really is.
>>>
>>> Outside of error paths, there is always one microcode patch to free. Its
>>> either result of parse_blob(), or it's the old cached value.
>>>
>>> In order to fix this, have a local patch pointer (mostly to avoid the
>>> unnecessary verbosity of patch_with_flags.patch), and always free it at the
>>> end. The only error path needing care is the IS_ERR(patch) path, which is
>>> easy enough to handle.
>>>
>>> Also, widen the scope of result. We only need to call compare_patch() once,
>>> and the answer is still good later when updating the cache. In order to
>>> update the cache, simply SWAP() the patch and the cache pointers, allowing the
>>> singular xfree() at the end to cover both cases.
>>>
>>> This also removes all callers microcode_free_patch() which fixes the need to
>>> cast away const to allow it to compile.
>> I'm sure you're well aware that this in turn is just because of your opposition
>> to xfree() and alike taking const void *.
>
> My opposition, and the C standards committee, and MISRA to name but a few.
The C standard's committee - yes, if we mean to stick to free()'s properties
to the letter (I don't think they have any idea about unmap-like things). For
Misra though, would you mind educating me where they would have a concern?
Jan
next prev parent reply other threads:[~2024-11-18 7:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-12 21:19 [PATCH v2 0/3] x86/ucode: Simplify/fix loading paths further Andrew Cooper
2024-11-12 21:19 ` [PATCH v2 1/3] x86/ucode: Remove the collect_cpu_info() call from parse_blob() Andrew Cooper
2024-11-14 11:11 ` Jan Beulich
2024-11-14 15:59 ` Andrew Cooper
2024-11-14 16:15 ` Jan Beulich
2024-11-14 17:20 ` Andrew Cooper
2024-11-12 21:19 ` [PATCH v2 2/3] x86/ucode: Fix cache handling in microcode_update_helper() Andrew Cooper
2024-11-14 11:26 ` Jan Beulich
2024-11-15 18:03 ` Andrew Cooper
2024-11-18 7:45 ` Jan Beulich [this message]
2024-11-12 21:19 ` [PATCH v2 3/3] x86/ucode: Drop MIS_UCODE and microcode_match_result Andrew Cooper
2024-11-14 11:41 ` Jan Beulich
2024-11-14 17:18 ` Andrew Cooper
2024-11-15 8:02 ` Jan Beulich
2024-11-15 16:50 ` Andrew Cooper
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=de8c88d4-5b79-41eb-955a-d015ef94aa15@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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.