linux-kernel - RE: [PATCH 1/2] RFC: Prepare PAD for native and xen platform

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: <DE8DF0795D48FD4CA783C40EC82923350B9496@SHSMSX101.ccr.corp.intel.com>
Date:	Tue, 28 Feb 2012 16:24:09 +0000
From:	"Liu, Jinsong" <jinsong.liu@...el.com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	Jan Beulich <jbeulich@...e.com>,
	"keir.xen@...il.com" <keir.xen@...il.com>,
	"Brown, Len" <len.brown@...el.com>,
	"Li, Shaohua" <shaohua.li@...el.com>,
	"lenb@...nel.org" <lenb@...nel.org>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 1/2] RFC: Prepare PAD for native and xen platform

Konrad Rzeszutek Wilk wrote:
> On Sun, Feb 26, 2012 at 08:25:41AM +0000, Liu, Jinsong wrote:
>> Liu, Jinsong wrote:
>>> Jan Beulich wrote:
>>>>>>> "Liu, Jinsong" <jinsong.liu@...el.com> 02/23/12 2:29 PM >>>
>>>>> --- a/drivers/acpi/Kconfig
>>>>> +++ b/drivers/acpi/Kconfig
>>>>> @@ -213,10 +213,11 @@ config ACPI_HOTPLUG_CPU
>>>>>    default y
>>>>  >
>>>>> config ACPI_PROCESSOR_AGGREGATOR
>>>>> -    tristate "Processor Aggregator"
>>>>> +    bool "Processor Aggregator"
>>>> 
>>>> There must be ways to address whatever strange problem you see
>>>> without making this piece of code non-modular.
>>>> 
>>> 
>>> Yes, another approach is x86_init approach, defining acpi_pad_ops at
>>> x86_init.c and overwritten when xen_start_kernel. This patch is just
>>> a RFC patch, to evaluate which approch is more reasonable :-)
>>> 
>> 
>> Have a more think about it, x86_init approach still need to disable
>> acpi_pad module. 
>> Seems we have to set acpi_pad as bool, as long as it need to hook to
>> native acpi_pad fucs/variables. 
> 
> What about the other approach I suggested where there are some
> function overrides in osl.c? Something similar to
> https://lkml.org/lkml/2012/1/17/401, specifically
> https://lkml.org/lkml/2012/1/17/403 - that way you are not turning
> the modules into being built in, but intead have the function table
> already in the kernel (as some form of EXPORT_SYMBOL_GPL or a
> registration function). 
> 

Thanks for the example (it's good itself :-), but per my understanding they are different cases.

In the osl example case, tboot_late_init call acpi_os_set_prepare_sleep to register func, so it works no matter tboot.c built as y/n/m (through currently it's bool).

However, in our case, we just cannot do so. We need
1. predefine a hook to native acpi pad funcs, take effect when static compile stage;
2. when xen init, redirect the hook to xen acpi pad funcs, take effect at running time;
(The point is, we cannot do init twice for native and xen acpi pad, so we have to statically predefine a hook to native acpi_pad)

For the reason above, I think we have to remove acpi_pad module, as long as we need to hook to native acpi_pad funcs. Thoughts?

Regards,
Jinsong
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/