Re: [PATCH v2 4/4] kernel: add support for init_array constructors

[Rusty Russell <rusty@rustcorp.com.au>]

Frantisek Hrbata <fhrbata@redhat.com> writes:
> On Tue, Sep 10, 2013 at 03:05:57PM +0930, Rusty Russell wrote:
>> Frantisek Hrbata <fhrbata@redhat.com> writes:
>> > On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
>> >> Kyle McMartin <kyle@infradead.org> writes:
>> >> > On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote:
>> >> >> > > v2: - reuse mod->ctors for .init_array section for modules, because gcc uses
>> >> >> > >       .ctors or .init_array, but not both at the same time
>> >> >> > >
>> >> >> > > Signed-off-by: Frantisek Hrbata <fhrbata@redhat.com>
>> >> >> > 
>> >> >> > Might be nice to document which gcc version changed this, so people can
>> >> >> > choose whether to cherry-pick this change?
>> >> >> 
>> >> >> Thank you for pointing this out. As per gcc git this was introduced by commit
>> >> >> ef1da80 and released in 4.7 version.
>> >> >> 
>> >> >> $ git describe --contains ef1da80
>> >> >> gcc-4_7_0-release~4358
>> >> >> 
>> >> >> Do you want me to post v3 with this info included in the descrition?
>> >> >> 
>> >> >
>> >> > It actually depends on the combination of binutils/ld and gcc you use, not
>> >> > simply which gcc version you use. :/
>> >> 
>> >> Indeed, and seems it was binutils 20110507 which actually handled it
>> >> properly.
>> >> 
>> >> AFAICT it's theoretically possible to have .ctors and .init_array in a
>> >> module.  Unlikely, but the patch should check for both and refuse to
>> >> load the module in that case.  Otherwise weird things would happen.
>> >
>> > I'm not sure if coexistence of .ctors and .init_array sections should result in
>> > denial of module, but I for sure know nothing about this :). Could you maybe
>> > privide one example of the "weird thing"?
>> 
>> Well, if we have both ctors and init_array, and we only call the ctors,
>> part of the module will be uninitialized.
>> 
>> I was thinking about something like the following (based on your
>> previous patch).
>> 
>> Thoughts?
>> Rusty.
>
> Thank you Rusty, from what I can say it looks ok to me. So I would go with this
> version. Is there anything that needs to be done to consider this as the
> correct version of the 4/4 patch? Meaning should we repost this as v3 or could
> your version of the patch be picked as you posted it?

Take that as posted.  I could push it through my tree, but I think
you'll want to keep them all together.

Cheers,
Rusty.