[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 02/12] x86/boot: eliminate module_map
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 7 Nov 2024 10:20:39 -0500
- Arc-authentication-results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@xxxxxxxxxxxxxxxxxxxx; dmarc=pass header.from=<dpsmith@xxxxxxxxxxxxxxxxxxxx>
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1730992842; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=e7pUCQEXiwbHmhXpKP5ghbovuABm4HGgLAe3v5b9E3g=; b=hXplxh2bF5WvY+jh5NzYxsfSMuop8DsCy+7yVxwI3VedsHOstmQC0RrAi3rYmxsHs9oARa8PvE5ivIY/tGM0vRVA5pKKS2zXyNL9FwfrKRsV3hCLoyl77rx63eP1HriMohEEF5dtaiW2UJGhNw2yqAhLVQnmWSR4L+7pspG109o=
- Arc-seal: i=1; a=rsa-sha256; t=1730992842; cv=none; d=zohomail.com; s=zohoarc; b=h52WZWOC9y9F//b25eN81aMqkH21pn4MDFZJA6xBrsr32GgGxAfciN/Rx8F9EBi/129EuGgavmOM834IvAiRUT4PZdzxHYFVWMnhgAJ64obXFduPU9uQlNLHL4iowPCKOsAObawmID+Ij0W2t2tnjQN4CRNMsNEQ/9NUpgI+T40=
- Cc: jason.andryuk@xxxxxxx, christopher.w.clark@xxxxxxxxx, stefano.stabellini@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Thu, 07 Nov 2024 15:20:56 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 11/7/24 10:15, Jan Beulich wrote:
On 07.11.2024 16:08, Daniel P. Smith wrote:
On 11/7/24 05:05, Jan Beulich wrote:
On 02.11.2024 18:25, Daniel P. Smith wrote:
--- a/xen/xsm/xsm_policy.c
+++ b/xen/xsm/xsm_policy.c
@@ -33,22 +33,18 @@
int __init xsm_multiboot_policy_init(
struct boot_info *bi, void **policy_buffer, size_t *policy_size)
{
- int i;
+ unsigned int i;
int rc = 0;
u32 *_policy_start;
unsigned long _policy_len;
- /*
- * Try all modules and see whichever could be the binary policy.
- * Adjust module_map for the module that is the binary policy.
- */
- for ( i = bi->nr_modules - 1; i >= 1; i-- )
+ /* Try all unknown modules and see whichever could be the binary policy. */
+ for_each_boot_module_by_type(i, bi, BOOTMOD_UNKNOWN)
{
- if ( !test_bit(i, bi->module_map) )
- continue;
+ struct boot_module *bm = &bi->mods[i];
... same here (and likely elsewhere in the series).
Nope, you can't const this one as that will cause this is at the tail
end of the loop to fail:
+ bm->type = BOOTMOD_XSM_POLICY;
Oh, I had managed to not spot that.
No worries. As I said, I have been trying to develop the habit to check
if write usage will be needed, const-ing and then finding myself often
greeted with gcc error about write to const. Wish gcc could warn about
pointers that have no writes in scope to help catch viable candidates.
v/r,
dps
|
