lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 7 Jun 2024 10:10:17 +0100
From: Robin Murphy <robin.murphy@....com>
To: Amit Singh Tomar <amitsinght@...vell.com>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>
Cc: linux-kernel@...r.kernel.org, Marc Zyngier <maz@...nel.org>,
 Thomas Gleixner <tglx@...utronix.de>, Mark Rutland <mark.rutland@....com>,
 "Rafael J. Wysocki" <rafael@...nel.org>,
 linux-arm-kernel@...ts.infradead.org, linux-acpi@...r.kernel.org,
 acpica-devel@...ts.linux.dev
Subject: Re: [PATCH v6 1/1] irqchip/gic-v3: Enable non-coherent
 redistributors/ITSes ACPI probing

On 2024-06-07 8:53 am, Amit Singh Tomar wrote:
>> On Fri, Jun 07, 2024 at 12:21:54AM +0530, Amit Singh Tomar wrote:
>>
>> [...]
>>
>>>> diff --git a/drivers/acpi/processor_core.c 
>>>> b/drivers/acpi/processor_core.c
>>>> index b203cfe28550..915713c0e9b7 100644
>>>> --- a/drivers/acpi/processor_core.c
>>>> +++ b/drivers/acpi/processor_core.c
>>>> @@ -215,6 +215,21 @@ phys_cpuid_t __init acpi_map_madt_entry(u32 
>>>> acpi_id)
>>>>        return rv;
>>>>    }
>>>> +int __init acpi_get_madt_revision(void)
>>>
>>> Wondering, if we can have a generic function (acpi_get_tbl_revision) to
>>> obtain the revision number for any ACPI table, not just specific to 
>>> MADT?
>>
>> We could - I don't think there would be users other than code in this
>> patch though so I thought it would not be necessary.
>>
> 
> Right, it might not be essential now but I see that MPAM will be another 
> user of it once the MPAM patches are out.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/tree/drivers/acpi/arm64/mpam.c?h=mpam/snapshot/v6.7-rc2#n299

Not really; there's already plenty of ACPI code which checks the 
revision of a table *while* also parsing other information from it, and 
that MPAM code is doing the same. Using a standalone function to look up 
the table, check one thing and throw it away, and then immediately have 
to look it up again to do the rest would be needlessly overcomplicated.

The thing in the GIC case is that doing this semi-redundant lookup to 
re-retrieve the top-level MADT header while we're already deep into 
parsing its subtables is still the least-worst option, because the 
alternative would be invasively churning the whole common MADT 
abstraction to pass that information all the way down just for this one 
slightly niche thing.

Thanks,
Robin.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ