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] [thread-next>] [day] [month] [year] [list]
Message-ID: <6916864a-f2cc-f484-180f-a0edd2149fc5@huawei.com>
Date: Mon, 23 Dec 2024 17:44:44 +0800
From: Xiaofei Tan <tanxiaofei@...wei.com>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>, "Rafael J. Wysocki"
	<rafael@...nel.org>
CC: <rafael@...nel.org>, <lenb@...nel.org>, <linux-acpi@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <jonathan.cameron@...wei.com>,
	<M.Chehab@...wei.com>, <roberto.sassu@...wei.com>, <shiju.jose@...wei.com>,
	<prime.zeng@...ilicon.com>, <linuxarm@...wei.com>
Subject: Re: [PATCH] acpi: Fix hed module initialization order when it is
 built-in

Hi Mauro,

在 2024/12/12 0:22, Mauro Carvalho Chehab 写道:
> Em Fri, 15 Nov 2024 11:50:14 +0800
> Xiaofei Tan <tanxiaofei@...wei.com> escreveu:
>
> Please always copy my @kernel.org address for upstream work.

OK

>> When the module hed is built-in, the init order is determined by
>> Makefile order. That order violates expectations. Because the module
>> hed init is behind evged. RAS records can't be handled in the
>> special time window that evged has initialized while hed not.
>> If the number of such RAS records is more than the APEI HEST error
>> source number, the HEST resources could be occupied all, and then
>> could affect subsequent RAS error reporting.
> IMO, it is a lot better to use a late init call. Please see:
> 	include/linux/init.h
>
> This would be done by, for instance, using late_initcall().
>
> Now, what we have is:
>
> 	acpi-y                          += evged.o
> 	obj-$(CONFIG_ACPI_HED)          += hed.o
>
> Where ACPI_HED being a tri-state.
>
> It sounds to me, that even, with your patch, if you build
> HED as a module, you'll still have a problem.
Yes, and it is also  affected by loading sequence of HED and GHES. Anyway, the risk remains.
>
> Shouldn't be ACPI_HED be changed from tristate to bool?

agree,

@Rafael

Hi Rafael, Please help check if we can do this change, thanks.


>
> Regards,
> Mauro
>
>> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
>> Signed-off-by: Xiaofei Tan <tanxiaofei@...wei.com>
>> ---
>>   drivers/acpi/Makefile | 8 +++++++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
>> index 61ca4afe83dc..54f60b7922ad 100644
>> --- a/drivers/acpi/Makefile
>> +++ b/drivers/acpi/Makefile
>> @@ -15,6 +15,13 @@ endif
>>   
>>   obj-$(CONFIG_ACPI)		+= tables.o
>>   
>> +#
>> +# The hed.o needs to be in front of evged.o to avoid the problem that
>> +# RAS errors cannot be handled in the special time window of startup
>> +# phase that evged has initialized while hed not.
>> +#
>> +obj-$(CONFIG_ACPI_HED)		+= hed.o
>> +
>>   #
>>   # ACPI Core Subsystem (Interpreter)
>>   #
>> @@ -95,7 +102,6 @@ obj-$(CONFIG_ACPI_HOTPLUG_IOAPIC) += ioapic.o
>>   obj-$(CONFIG_ACPI_BATTERY)	+= battery.o
>>   obj-$(CONFIG_ACPI_SBS)		+= sbshc.o
>>   obj-$(CONFIG_ACPI_SBS)		+= sbs.o
>> -obj-$(CONFIG_ACPI_HED)		+= hed.o
>>   obj-$(CONFIG_ACPI_EC_DEBUGFS)	+= ec_sys.o
>>   obj-$(CONFIG_ACPI_BGRT)		+= bgrt.o
>>   obj-$(CONFIG_ACPI_CPPC_LIB)	+= cppc_acpi.o
> .

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ