Re: [PATCH v3] vmlinux.lds: account for destructor sections

[Dmitry Vyukov]

On Fri, Jul 1, 2016 at 4:58 PM, Andrey Ryabinin <ryabinin.a.a@xxxxxxxxx> wrote:
> 2016-06-29 20:28 GMT+03:00 Dmitry Vyukov <dvyukov@xxxxxxxxxx>:
>> On Fri, Jun 24, 2016 at 6:57 PM, Andrey Ryabinin <ryabinin.a.a@xxxxxxxxx> wrote:
>>> 2016-06-24 18:39 GMT+03:00 Dmitry Vyukov <dvyukov@xxxxxxxxxx>:
>>>> If CONFIG_KASAN is enabled and gcc is configured with
>>>> --disable-initfini-array and/or gold linker is used,
>>>> gcc emits .ctors/.dtors and .text.startup/.text.exit
>>>> sections instead of .init_array/.fini_array.
>>>> .dtors section is not explicitly accounted in the linker
>>>> script and messes vvar/percpu layout. Want:
>>>>
>>>> ffffffff822bfd80 D _edata
>>>> ffffffff822c0000 D __vvar_beginning_hack
>>>> ffffffff822c0000 A __vvar_page
>>>> ffffffff822c0080 0000000000000098 D vsyscall_gtod_data
>>>> ffffffff822c1000 A __init_begin
>>>> ffffffff822c1000 D init_per_cpu__irq_stack_union
>>>> ffffffff822c1000 A __per_cpu_load
>>>> ffffffff822d3000 D init_per_cpu__gdt_page
>>>>
>>>> Got:
>>>>
>>>> ffffffff8279a600 D _edata
>>>> ffffffff8279b000 A __vvar_page
>>>> ffffffff8279c000 A __init_begin
>>>> ffffffff8279c000 D init_per_cpu__irq_stack_union
>>>> ffffffff8279c000 A __per_cpu_load
>>>> ffffffff8279e000 D __vvar_beginning_hack
>>>> ffffffff8279e080 0000000000000098 D vsyscall_gtod_data
>>>> ffffffff827ae000 D init_per_cpu__gdt_page
>>>>
>>>> This happens because __vvar_page and .vvar get different
>>>> addresses in arch/x86/kernel/vmlinux.lds.S:
>>>>
>>>>         . = ALIGN(PAGE_SIZE);
>>>>         __vvar_page = .;
>>>>
>>>>         .vvar : AT(ADDR(.vvar) - LOAD_OFFSET) {
>>>>                 /* work around gold bug 13023 */
>>>>                 __vvar_beginning_hack = .;
>>>>
>>>> Discard .dtors/.fini_array/.text.exit, since we don't call dtors.
>>>> Merge .text.startup into init text.
>>>>
>>>> Signed-off-by: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
>>>
>>> Reviewed-by: Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
>>
>>
>> Who can take it to some tree?
>
> akpm tends to be the maintainer of last resort.
> But you probably need to resend the patch, because LKML was not in CC list.
> Also, please add stable tag: Cc: <stable@xxxxxxxxxxxxxxx> # v4.0+

Remailed. Thanks.