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

[Rusty Russell]

Frantisek Hrbata  writes:
> On Tue, Sep 10, 2013 at 03:05:57PM +0930, Rusty Russell wrote:
>> Frantisek Hrbata  writes:
>> > On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
>> >> Kyle McMartin  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 
>> >> >> > 
>> >> >> > 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Frantisek Hrbata]

On Tue, Sep 10, 2013 at 03:05:57PM +0930, Rusty Russell wrote:
> Frantisek Hrbata  writes:
> > On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
> >> Kyle McMartin  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 
> >> >> > 
> >> >> > 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?

> 
> From: Frantisek Hrbata 
> Subject: kernel: add support for init_array constructors
> 
> This adds the .init_array section as yet another section with constructors. 
> This
> is needed because gcc could add __gcov_init calls to .init_array or .ctors
> section, depending on gcc (and binutils) version .
> 
> v2: - reuse mod->ctors for .init_array section for modules, because gcc uses
>   .ctors or .init_array, but not both at the same time
> v3: - fail to load if that does happen somehow.
> 
> Signed-off-by: Frantisek Hrbata 
> Signed-off-by: Rusty Russell 
> 
> diff --git a/include/asm-generic/vmlinux.lds.h 
> b/include/asm-generic/vmlinux.lds.h
> index 83e2c31..bc2121f 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -473,6 +473,7 @@
>  #define KERNEL_CTORS()   . = ALIGN(8);  \
>   VMLINUX_SYMBOL(__ctors_start) = .; \
>   *(.ctors)  \
> + *(.init_array) \
>   VMLINUX_SYMBOL(__ctors_end) = .;
>  #else
>  #define KERNEL_CTORS()
> diff --git a/kernel/module.c b/kernel/module.c
> index dc58274..d3f5a58 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2738,7 +2738,7 @@ static int check_modinfo(struct module *mod, struct 
> load_info *info, int flags)
>   return 0;
>  }
>  
> -static void find_module_sections(struct module *mod, struct load_info *info)
> +static int find_module_sections(struct module *mod, struct load_info *info)
>  {
>   mod->kp = section_objs(info, "__param",
>  sizeof(*mod->kp), >num_kp);
> @@ -2768,6 +2768,18 @@ static void find_module_sections(struct module *mod, 
> struct load_info *info)
>  #ifdef CONFIG_CONSTRUCTORS
>   mod->ctors = section_objs(info, ".ctors",
> sizeof(*mod->ctors), >num_ctors);
> + if (!mod->ctors)
> + mod->ctors = section_objs(info, ".init_array",
> + sizeof(*mod->ctors), >num_ctors);
> + else if (find_sec(info, ".init_array")) {
> + /*
> +  * This shouldn't happen with same compiler and binutils
> +  * building all parts of the module.
> +  */
> + printk(KERN_WARNING "%s: has both .ctors and .init_array.\n",
> +mod->name);
> + return -EINVAL;
> + }
>  #endif
>  
>  #ifdef CONFIG_TRACEPOINTS
> @@ -2806,6 +2818,8 @@ static void find_module_sections(struct module *mod, 
> struct load_info *info)
>  
>   info->debug = section_objs(info, "__verbose",
>  sizeof(*info->debug), >num_debug);
> +
> + return 0;
>  }
>  
>  static int move_module(struct module *mod, struct 

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

[Rusty Russell]

Frantisek Hrbata  writes:
> On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
>> Kyle McMartin  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 
>> >> > 
>> >> > 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.

From: Frantisek Hrbata 
Subject: kernel: add support for init_array constructors

This adds the .init_array section as yet another section with constructors. This
is needed because gcc could add __gcov_init calls to .init_array or .ctors
section, depending on gcc (and binutils) version .

v2: - reuse mod->ctors for .init_array section for modules, because gcc uses
  .ctors or .init_array, but not both at the same time
v3: - fail to load if that does happen somehow.

Signed-off-by: Frantisek Hrbata 
Signed-off-by: Rusty Russell 

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 83e2c31..bc2121f 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -473,6 +473,7 @@
 #define KERNEL_CTORS() . = ALIGN(8);  \
VMLINUX_SYMBOL(__ctors_start) = .; \
*(.ctors)  \
+   *(.init_array) \
VMLINUX_SYMBOL(__ctors_end) = .;
 #else
 #define KERNEL_CTORS()
diff --git a/kernel/module.c b/kernel/module.c
index dc58274..d3f5a58 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2738,7 +2738,7 @@ static int check_modinfo(struct module *mod, struct 
load_info *info, int flags)
return 0;
 }
 
-static void find_module_sections(struct module *mod, struct load_info *info)
+static int find_module_sections(struct module *mod, struct load_info *info)
 {
mod->kp = section_objs(info, "__param",
   sizeof(*mod->kp), >num_kp);
@@ -2768,6 +2768,18 @@ static void find_module_sections(struct module *mod, 
struct load_info *info)
 #ifdef CONFIG_CONSTRUCTORS
mod->ctors = section_objs(info, ".ctors",
  sizeof(*mod->ctors), >num_ctors);
+   if (!mod->ctors)
+   mod->ctors = section_objs(info, ".init_array",
+   sizeof(*mod->ctors), >num_ctors);
+   else if (find_sec(info, ".init_array")) {
+   /*
+* This shouldn't happen with same compiler and binutils
+* building all parts of the module.
+*/
+   printk(KERN_WARNING "%s: has both .ctors and .init_array.\n",
+  mod->name);
+   return -EINVAL;
+   }
 #endif
 
 #ifdef CONFIG_TRACEPOINTS
@@ -2806,6 +2818,8 @@ static void find_module_sections(struct module *mod, 
struct load_info *info)
 
info->debug = section_objs(info, "__verbose",
   sizeof(*info->debug), >num_debug);
+
+   return 0;
 }
 
 static int move_module(struct module *mod, struct load_info *info)
@@ -3263,7 +3277,9 @@ static int load_module(struct load_info *info, const char 
__user *uargs,
 
/* Now we've got everything in the final locations, we can
 * find optional sections. */
-   find_module_sections(mod, info);
+   err = find_module_sections(mod, info);
+   if (err)
+   goto free_unload;
 
err = check_module_license_and_versions(mod);
if (err)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More 

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

[Rusty Russell]

Frantisek Hrbata fhrb...@redhat.com writes:
 On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
 Kyle McMartin k...@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 fhrb...@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.

From: Frantisek Hrbata fhrb...@redhat.com
Subject: kernel: add support for init_array constructors

This adds the .init_array section as yet another section with constructors. This
is needed because gcc could add __gcov_init calls to .init_array or .ctors
section, depending on gcc (and binutils) version .

v2: - reuse mod-ctors for .init_array section for modules, because gcc uses
  .ctors or .init_array, but not both at the same time
v3: - fail to load if that does happen somehow.

Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
Signed-off-by: Rusty Russell ru...@rustcorp.com.au

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 83e2c31..bc2121f 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -473,6 +473,7 @@
 #define KERNEL_CTORS() . = ALIGN(8);  \
VMLINUX_SYMBOL(__ctors_start) = .; \
*(.ctors)  \
+   *(.init_array) \
VMLINUX_SYMBOL(__ctors_end) = .;
 #else
 #define KERNEL_CTORS()
diff --git a/kernel/module.c b/kernel/module.c
index dc58274..d3f5a58 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2738,7 +2738,7 @@ static int check_modinfo(struct module *mod, struct 
load_info *info, int flags)
return 0;
 }
 
-static void find_module_sections(struct module *mod, struct load_info *info)
+static int find_module_sections(struct module *mod, struct load_info *info)
 {
mod-kp = section_objs(info, __param,
   sizeof(*mod-kp), mod-num_kp);
@@ -2768,6 +2768,18 @@ static void find_module_sections(struct module *mod, 
struct load_info *info)
 #ifdef CONFIG_CONSTRUCTORS
mod-ctors = section_objs(info, .ctors,
  sizeof(*mod-ctors), mod-num_ctors);
+   if (!mod-ctors)
+   mod-ctors = section_objs(info, .init_array,
+   sizeof(*mod-ctors), mod-num_ctors);
+   else if (find_sec(info, .init_array)) {
+   /*
+* This shouldn't happen with same compiler and binutils
+* building all parts of the module.
+*/
+   printk(KERN_WARNING %s: has both .ctors and .init_array.\n,
+  mod-name);
+   return -EINVAL;
+   }
 #endif
 
 #ifdef CONFIG_TRACEPOINTS
@@ -2806,6 +2818,8 @@ static void find_module_sections(struct module *mod, 
struct load_info *info)
 
info-debug = section_objs(info, __verbose,
   sizeof(*info-debug), info-num_debug);
+
+   return 0;
 }
 
 static int move_module(struct module *mod, struct load_info *info)
@@ -3263,7 +3277,9 @@ static int load_module(struct load_info *info, const char 
__user *uargs,
 
/* Now we've got everything in the final locations, we can
 * find optional sections. */
-   find_module_sections(mod, info);
+   err = find_module_sections(mod, info);
+   if (err)
+   goto free_unload;
 
err = check_module_license_and_versions(mod);
if (err)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

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

[Frantisek Hrbata]

On Tue, Sep 10, 2013 at 03:05:57PM +0930, Rusty Russell wrote:
 Frantisek Hrbata fhrb...@redhat.com writes:
  On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
  Kyle McMartin k...@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 fhrb...@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?

 
 From: Frantisek Hrbata fhrb...@redhat.com
 Subject: kernel: add support for init_array constructors
 
 This adds the .init_array section as yet another section with constructors. 
 This
 is needed because gcc could add __gcov_init calls to .init_array or .ctors
 section, depending on gcc (and binutils) version .
 
 v2: - reuse mod-ctors for .init_array section for modules, because gcc uses
   .ctors or .init_array, but not both at the same time
 v3: - fail to load if that does happen somehow.
 
 Signed-off-by: Frantisek Hrbata fhrb...@redhat.com
 Signed-off-by: Rusty Russell ru...@rustcorp.com.au
 
 diff --git a/include/asm-generic/vmlinux.lds.h 
 b/include/asm-generic/vmlinux.lds.h
 index 83e2c31..bc2121f 100644
 --- a/include/asm-generic/vmlinux.lds.h
 +++ b/include/asm-generic/vmlinux.lds.h
 @@ -473,6 +473,7 @@
  #define KERNEL_CTORS()   . = ALIGN(8);  \
   VMLINUX_SYMBOL(__ctors_start) = .; \
   *(.ctors)  \
 + *(.init_array) \
   VMLINUX_SYMBOL(__ctors_end) = .;
  #else
  #define KERNEL_CTORS()
 diff --git a/kernel/module.c b/kernel/module.c
 index dc58274..d3f5a58 100644
 --- a/kernel/module.c
 +++ b/kernel/module.c
 @@ -2738,7 +2738,7 @@ static int check_modinfo(struct module *mod, struct 
 load_info *info, int flags)
   return 0;
  }
  
 -static void find_module_sections(struct module *mod, struct load_info *info)
 +static int find_module_sections(struct module *mod, struct load_info *info)
  {
   mod-kp = section_objs(info, __param,
  sizeof(*mod-kp), mod-num_kp);
 @@ -2768,6 +2768,18 @@ static void find_module_sections(struct module *mod, 
 struct load_info *info)
  #ifdef CONFIG_CONSTRUCTORS
   mod-ctors = section_objs(info, .ctors,
 sizeof(*mod-ctors), mod-num_ctors);
 + if (!mod-ctors)
 + mod-ctors = section_objs(info, .init_array,
 + sizeof(*mod-ctors), mod-num_ctors);
 + else if (find_sec(info, .init_array)) {
 + /*
 +  * This shouldn't happen with same compiler and binutils
 +  * building all parts of the module.
 +  */
 + printk(KERN_WARNING %s: has both .ctors and .init_array.\n,
 +mod-name);
 + return -EINVAL;
 + }
  #endif
  
  #ifdef CONFIG_TRACEPOINTS
 @@ -2806,6 +2818,8 @@ static void find_module_sections(struct module *mod, 
 struct load_info *info)
  
   info-debug = section_objs(info, __verbose,
  sizeof(*info-debug), info-num_debug);
 +
 + return 0;
  }
  
  static int move_module(struct module *mod, struct load_info *info)
 @@ -3263,7 +3277,9 @@ static int load_module(struct load_info *info, const 
 char __user *uargs,
  
   /* Now we've got everything in 

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

[Rusty Russell]

Frantisek Hrbata fhrb...@redhat.com writes:
 On Tue, Sep 10, 2013 at 03:05:57PM +0930, Rusty Russell wrote:
 Frantisek Hrbata fhrb...@redhat.com writes:
  On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
  Kyle McMartin k...@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 fhrb...@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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Kyle McMartin]

On Mon, Sep 09, 2013 at 06:28:14PM +0200, Frantisek Hrbata wrote:
> 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"?
> 

They shouldn't exist unless placed there intentionally... I suspect a
call_if_changed Makefile target to regenerated a header would solve this
problem sufficiently for a given toolchain version.

A little exposition:
.init_array and .ctors are laid out on top of each other, with an
ordering that's a bit complicated... the sort of the ctor functions ends
up being .ctor.x upwards towards 65535, and .init_array.x downwards
from 65535 towards 0, with priority 65535-x, so that

.init_array.32768 would be called before .ctor.32768.

It's all a complete mess.

Perhaps if CONFIG_GCOV is on, we should enforce MODVERSIONS and make
sure the GCC version doesn't change for the running kernel?

Maybe it would be sufficient to just detect what the toolchain supports
and do that? I have a patch based on the configure.ac in gcc that
does something like that, which would be trivial to use to generate a
header based on gcc version.

> Anyway many thanks for taking time to look at this. Below is my attepmt to
> implement the check you proposed. 
> 
> untested/uncompiled

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

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

[Frantisek Hrbata]

On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
> Kyle McMartin  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 
> >> > 
> >> > 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"?

Anyway many thanks for taking time to look at this. Below is my attepmt to
implement the check you proposed. 

untested/uncompiled

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 83e2c31..bc2121f 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -473,6 +473,7 @@
 #define KERNEL_CTORS() . = ALIGN(8);  \
VMLINUX_SYMBOL(__ctors_start) = .; \
*(.ctors)  \
+   *(.init_array) \
VMLINUX_SYMBOL(__ctors_end) = .;
 #else
 #define KERNEL_CTORS()
diff --git a/include/linux/module.h b/include/linux/module.h
index 05f2447..e775b41 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -380,6 +380,8 @@ struct module
/* Constructor functions. */
ctor_fn_t *ctors;
unsigned int num_ctors;
+   ctor_fn_t *init_array;
+   unsigned int num_init_array;
 #endif
 };
 #ifndef MODULE_ARCH_INIT
diff --git a/kernel/module.c b/kernel/module.c
index dc58274..831b92d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2768,6 +2768,9 @@ static void find_module_sections(struct module *mod, 
struct load_info *info)
 #ifdef CONFIG_CONSTRUCTORS
mod->ctors = section_objs(info, ".ctors",
  sizeof(*mod->ctors), >num_ctors);
+   mod->init_array = section_objs(info, ".init_array",
+ sizeof(*mod->init_array),
+ >num_init_array);
 #endif
 
 #ifdef CONFIG_TRACEPOINTS
@@ -2808,6 +2811,18 @@ static void find_module_sections(struct module *mod, 
struct load_info *info)
   sizeof(*info->debug), >num_debug);
 }
 
+static void check_module_sections(struct module *mod)
+{
+#ifdef CONFIG_CONSTRUCTORS
+   if (mod->ctors && mod->init_array) {
+   pr_err("%s: .ctors and .init_array sections mishmash\n",
+   mod->name);
+   return -EINVAL;
+   }
+#endif
+   return 0;
+}
+
 static int move_module(struct module *mod, struct load_info *info)
 {
int i;
@@ -3032,6 +3047,9 @@ static void do_mod_ctors(struct module *mod)
 
for (i = 0; i < mod->num_ctors; i++)
mod->ctors[i]();
+
+   for (i = 0; i < mod->num_init_array; i++)
+   mod->init_array[i]();
 #endif
 }
 
@@ -3265,6 +3283,10 @@ static int load_module(struct load_info *info, const 
char __user *uargs,
 * find optional sections. */
find_module_sections(mod, info);
 
+   err = check_module_sections(mod);
+   if (err)
+   goto free_unload;
+
err = check_module_license_and_versions(mod);
if (err)
goto free_unload;
-- 
1.8.3.1

> 
> Cheers,
> Rusty.

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

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

[Frantisek Hrbata]

On Mon, Sep 09, 2013 at 10:44:03AM +0930, Rusty Russell wrote:
 Kyle McMartin k...@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 fhrb...@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?

Anyway many thanks for taking time to look at this. Below is my attepmt to
implement the check you proposed. 

untested/uncompiled

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 83e2c31..bc2121f 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -473,6 +473,7 @@
 #define KERNEL_CTORS() . = ALIGN(8);  \
VMLINUX_SYMBOL(__ctors_start) = .; \
*(.ctors)  \
+   *(.init_array) \
VMLINUX_SYMBOL(__ctors_end) = .;
 #else
 #define KERNEL_CTORS()
diff --git a/include/linux/module.h b/include/linux/module.h
index 05f2447..e775b41 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -380,6 +380,8 @@ struct module
/* Constructor functions. */
ctor_fn_t *ctors;
unsigned int num_ctors;
+   ctor_fn_t *init_array;
+   unsigned int num_init_array;
 #endif
 };
 #ifndef MODULE_ARCH_INIT
diff --git a/kernel/module.c b/kernel/module.c
index dc58274..831b92d 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2768,6 +2768,9 @@ static void find_module_sections(struct module *mod, 
struct load_info *info)
 #ifdef CONFIG_CONSTRUCTORS
mod-ctors = section_objs(info, .ctors,
  sizeof(*mod-ctors), mod-num_ctors);
+   mod-init_array = section_objs(info, .init_array,
+ sizeof(*mod-init_array),
+ mod-num_init_array);
 #endif
 
 #ifdef CONFIG_TRACEPOINTS
@@ -2808,6 +2811,18 @@ static void find_module_sections(struct module *mod, 
struct load_info *info)
   sizeof(*info-debug), info-num_debug);
 }
 
+static void check_module_sections(struct module *mod)
+{
+#ifdef CONFIG_CONSTRUCTORS
+   if (mod-ctors  mod-init_array) {
+   pr_err(%s: .ctors and .init_array sections mishmash\n,
+   mod-name);
+   return -EINVAL;
+   }
+#endif
+   return 0;
+}
+
 static int move_module(struct module *mod, struct load_info *info)
 {
int i;
@@ -3032,6 +3047,9 @@ static void do_mod_ctors(struct module *mod)
 
for (i = 0; i  mod-num_ctors; i++)
mod-ctors[i]();
+
+   for (i = 0; i  mod-num_init_array; i++)
+   mod-init_array[i]();
 #endif
 }
 
@@ -3265,6 +3283,10 @@ static int load_module(struct load_info *info, const 
char __user *uargs,
 * find optional sections. */
find_module_sections(mod, info);
 
+   err = check_module_sections(mod);
+   if (err)
+   goto free_unload;
+
err = check_module_license_and_versions(mod);
if (err)
goto free_unload;
-- 
1.8.3.1

 
 Cheers,
 Rusty.

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

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

[Kyle McMartin]

On Mon, Sep 09, 2013 at 06:28:14PM +0200, Frantisek Hrbata wrote:
 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?
 

They shouldn't exist unless placed there intentionally... I suspect a
call_if_changed Makefile target to regenerated a header would solve this
problem sufficiently for a given toolchain version.

A little exposition:
.init_array and .ctors are laid out on top of each other, with an
ordering that's a bit complicated... the sort of the ctor functions ends
up being .ctor.x upwards towards 65535, and .init_array.x downwards
from 65535 towards 0, with priority 65535-x, so that

.init_array.32768 would be called before .ctor.32768.

It's all a complete mess.

Perhaps if CONFIG_GCOV is on, we should enforce MODVERSIONS and make
sure the GCC version doesn't change for the running kernel?

Maybe it would be sufficient to just detect what the toolchain supports
and do that? I have a patch based on the configure.ac in gcc that
does something like that, which would be trivial to use to generate a
header based on gcc version.

 Anyway many thanks for taking time to look at this. Below is my attepmt to
 implement the check you proposed. 
 
 untested/uncompiled

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

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

[Rusty Russell]

Kyle McMartin  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 
>> > 
>> > 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.

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

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

[Rusty Russell]

Kyle McMartin k...@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 fhrb...@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.

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

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

[Kyle McMartin]

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 
> > 
> > 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. :/

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

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

[Frantisek Hrbata]

On Fri, Sep 06, 2013 at 11:43:08AM +0930, Rusty Russell wrote:
> Frantisek Hrbata  writes:
> > This adds the .init_array section as yet another section with constructors. 
> > This
> > is needed because gcc could add __gcov_init calls to .init_array or .ctors
> > section, depending on gcc version.
> >
> > 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 
> 
> 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?

> 
> Acked-by: Rusty Russell 

Many thanks

> 
> > ---
> >  include/asm-generic/vmlinux.lds.h | 1 +
> >  kernel/module.c   | 3 +++
> >  2 files changed, 4 insertions(+)
> >
> > diff --git a/include/asm-generic/vmlinux.lds.h 
> > b/include/asm-generic/vmlinux.lds.h
> > index 69732d2..c55d8d9 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -468,6 +468,7 @@
> >  #define KERNEL_CTORS() . = ALIGN(8);  \
> > VMLINUX_SYMBOL(__ctors_start) = .; \
> > *(.ctors)  \
> > +   *(.init_array) \
> > VMLINUX_SYMBOL(__ctors_end) = .;
> >  #else
> >  #define KERNEL_CTORS()
> > diff --git a/kernel/module.c b/kernel/module.c
> > index 2069158..bbbd953 100644
> > --- a/kernel/module.c
> > +++ b/kernel/module.c
> > @@ -2760,6 +2760,9 @@ static void find_module_sections(struct module *mod, 
> > struct load_info *info)
> >  #ifdef CONFIG_CONSTRUCTORS
> > mod->ctors = section_objs(info, ".ctors",
> >   sizeof(*mod->ctors), >num_ctors);
> > +   if (!mod->ctors)
> > +   mod->ctors = section_objs(info, ".init_array",
> > +   sizeof(*mod->ctors), >num_ctors);
> >  #endif
> >  
> >  #ifdef CONFIG_TRACEPOINTS
> > -- 
> > 1.8.3.1

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

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

[Frantisek Hrbata]

On Fri, Sep 06, 2013 at 11:43:08AM +0930, Rusty Russell wrote:
 Frantisek Hrbata fhrb...@redhat.com writes:
  This adds the .init_array section as yet another section with constructors. 
  This
  is needed because gcc could add __gcov_init calls to .init_array or .ctors
  section, depending on gcc version.
 
  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 fhrb...@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?

 
 Acked-by: Rusty Russell ru...@rustcorp.com.au

Many thanks

 
  ---
   include/asm-generic/vmlinux.lds.h | 1 +
   kernel/module.c   | 3 +++
   2 files changed, 4 insertions(+)
 
  diff --git a/include/asm-generic/vmlinux.lds.h 
  b/include/asm-generic/vmlinux.lds.h
  index 69732d2..c55d8d9 100644
  --- a/include/asm-generic/vmlinux.lds.h
  +++ b/include/asm-generic/vmlinux.lds.h
  @@ -468,6 +468,7 @@
   #define KERNEL_CTORS() . = ALIGN(8);  \
  VMLINUX_SYMBOL(__ctors_start) = .; \
  *(.ctors)  \
  +   *(.init_array) \
  VMLINUX_SYMBOL(__ctors_end) = .;
   #else
   #define KERNEL_CTORS()
  diff --git a/kernel/module.c b/kernel/module.c
  index 2069158..bbbd953 100644
  --- a/kernel/module.c
  +++ b/kernel/module.c
  @@ -2760,6 +2760,9 @@ static void find_module_sections(struct module *mod, 
  struct load_info *info)
   #ifdef CONFIG_CONSTRUCTORS
  mod-ctors = section_objs(info, .ctors,
sizeof(*mod-ctors), mod-num_ctors);
  +   if (!mod-ctors)
  +   mod-ctors = section_objs(info, .init_array,
  +   sizeof(*mod-ctors), mod-num_ctors);
   #endif
   
   #ifdef CONFIG_TRACEPOINTS
  -- 
  1.8.3.1

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

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

[Kyle McMartin]

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 fhrb...@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. :/

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

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

[Rusty Russell]

Frantisek Hrbata  writes:
> This adds the .init_array section as yet another section with constructors. 
> This
> is needed because gcc could add __gcov_init calls to .init_array or .ctors
> section, depending on gcc version.
>
> 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 

Might be nice to document which gcc version changed this, so people can
choose whether to cherry-pick this change?

Acked-by: Rusty Russell 

> ---
>  include/asm-generic/vmlinux.lds.h | 1 +
>  kernel/module.c   | 3 +++
>  2 files changed, 4 insertions(+)
>
> diff --git a/include/asm-generic/vmlinux.lds.h 
> b/include/asm-generic/vmlinux.lds.h
> index 69732d2..c55d8d9 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -468,6 +468,7 @@
>  #define KERNEL_CTORS()   . = ALIGN(8);  \
>   VMLINUX_SYMBOL(__ctors_start) = .; \
>   *(.ctors)  \
> + *(.init_array) \
>   VMLINUX_SYMBOL(__ctors_end) = .;
>  #else
>  #define KERNEL_CTORS()
> diff --git a/kernel/module.c b/kernel/module.c
> index 2069158..bbbd953 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -2760,6 +2760,9 @@ static void find_module_sections(struct module *mod, 
> struct load_info *info)
>  #ifdef CONFIG_CONSTRUCTORS
>   mod->ctors = section_objs(info, ".ctors",
> sizeof(*mod->ctors), >num_ctors);
> + if (!mod->ctors)
> + mod->ctors = section_objs(info, ".init_array",
> + sizeof(*mod->ctors), >num_ctors);
>  #endif
>  
>  #ifdef CONFIG_TRACEPOINTS
> -- 
> 1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Rusty Russell]

Frantisek Hrbata fhrb...@redhat.com writes:
 This adds the .init_array section as yet another section with constructors. 
 This
 is needed because gcc could add __gcov_init calls to .init_array or .ctors
 section, depending on gcc version.

 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 fhrb...@redhat.com

Might be nice to document which gcc version changed this, so people can
choose whether to cherry-pick this change?

Acked-by: Rusty Russell ru...@rustcorp.com.au

 ---
  include/asm-generic/vmlinux.lds.h | 1 +
  kernel/module.c   | 3 +++
  2 files changed, 4 insertions(+)

 diff --git a/include/asm-generic/vmlinux.lds.h 
 b/include/asm-generic/vmlinux.lds.h
 index 69732d2..c55d8d9 100644
 --- a/include/asm-generic/vmlinux.lds.h
 +++ b/include/asm-generic/vmlinux.lds.h
 @@ -468,6 +468,7 @@
  #define KERNEL_CTORS()   . = ALIGN(8);  \
   VMLINUX_SYMBOL(__ctors_start) = .; \
   *(.ctors)  \
 + *(.init_array) \
   VMLINUX_SYMBOL(__ctors_end) = .;
  #else
  #define KERNEL_CTORS()
 diff --git a/kernel/module.c b/kernel/module.c
 index 2069158..bbbd953 100644
 --- a/kernel/module.c
 +++ b/kernel/module.c
 @@ -2760,6 +2760,9 @@ static void find_module_sections(struct module *mod, 
 struct load_info *info)
  #ifdef CONFIG_CONSTRUCTORS
   mod-ctors = section_objs(info, .ctors,
 sizeof(*mod-ctors), mod-num_ctors);
 + if (!mod-ctors)
 + mod-ctors = section_objs(info, .init_array,
 + sizeof(*mod-ctors), mod-num_ctors);
  #endif
  
  #ifdef CONFIG_TRACEPOINTS
 -- 
 1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Frantisek Hrbata]

This adds the .init_array section as yet another section with constructors. This
is needed because gcc could add __gcov_init calls to .init_array or .ctors
section, depending on gcc version.

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 
---
 include/asm-generic/vmlinux.lds.h | 1 +
 kernel/module.c   | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 69732d2..c55d8d9 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -468,6 +468,7 @@
 #define KERNEL_CTORS() . = ALIGN(8);  \
VMLINUX_SYMBOL(__ctors_start) = .; \
*(.ctors)  \
+   *(.init_array) \
VMLINUX_SYMBOL(__ctors_end) = .;
 #else
 #define KERNEL_CTORS()
diff --git a/kernel/module.c b/kernel/module.c
index 2069158..bbbd953 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2760,6 +2760,9 @@ static void find_module_sections(struct module *mod, 
struct load_info *info)
 #ifdef CONFIG_CONSTRUCTORS
mod->ctors = section_objs(info, ".ctors",
  sizeof(*mod->ctors), >num_ctors);
+   if (!mod->ctors)
+   mod->ctors = section_objs(info, ".init_array",
+   sizeof(*mod->ctors), >num_ctors);
 #endif
 
 #ifdef CONFIG_TRACEPOINTS
-- 
1.8.3.1

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

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

[Frantisek Hrbata]

This adds the .init_array section as yet another section with constructors. This
is needed because gcc could add __gcov_init calls to .init_array or .ctors
section, depending on gcc version.

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 fhrb...@redhat.com
---
 include/asm-generic/vmlinux.lds.h | 1 +
 kernel/module.c   | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 69732d2..c55d8d9 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -468,6 +468,7 @@
 #define KERNEL_CTORS() . = ALIGN(8);  \
VMLINUX_SYMBOL(__ctors_start) = .; \
*(.ctors)  \
+   *(.init_array) \
VMLINUX_SYMBOL(__ctors_end) = .;
 #else
 #define KERNEL_CTORS()
diff --git a/kernel/module.c b/kernel/module.c
index 2069158..bbbd953 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2760,6 +2760,9 @@ static void find_module_sections(struct module *mod, 
struct load_info *info)
 #ifdef CONFIG_CONSTRUCTORS
mod-ctors = section_objs(info, .ctors,
  sizeof(*mod-ctors), mod-num_ctors);
+   if (!mod-ctors)
+   mod-ctors = section_objs(info, .init_array,
+   sizeof(*mod-ctors), mod-num_ctors);
 #endif
 
 #ifdef CONFIG_TRACEPOINTS
-- 
1.8.3.1

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