All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathias Krause <minipli@googlemail.com>
To: Joe Perches <joe@perches.com>
Cc: Mason <slash.tmp@free.fr>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Mathias Krause <minipli@gmail.com>
Subject: Re: String literals in __init functions
Date: Thu, 26 Mar 2015 17:37:00 +0100	[thread overview]
Message-ID: <CA+rthh9Fb2q+O_wicc6eNcbo6SzwOVZed=tnThJLF-xuoQ-+Cw@mail.gmail.com> (raw)
In-Reply-To: <1427386390.15849.13.camel@perches.com>

On 26 March 2015 at 17:13, Joe Perches <joe@perches.com> wrote:
> On Thu, 2015-03-26 at 13:40 +0100, Mason wrote:
>> On 25/03/2015 19:01, Joe Perches wrote:
>> > On Wed, 2015-03-25 at 18:56 +0100, Mason wrote:
>> >
>> >> AFAIU, functions only used at system init are tagged __init to have
>> >> the linker store them in a separate .init.text section, so memory can
>> >> be reclaimed once initialization is complete. Is that correct?
>> >>
>> >> The corresponding tag for data is __initdata (section .init.data)
>> >>
>> >> I started wondering if the string literals used in an __init functions
>> >> were automatically marked __initdata.
>> >>
>> >> Looking at the objdump output, I see that the string literals are,
>> >> in fact, stored in the .rodata section. I suppose that .rodata is NOT
>> >> reclaimed after init?
>> >>
>> >> [...]
>> >>
>> >> Did I miss something in init.h?
>> >> Or should it be done like above to reclaim string literals?
>> >
>> > No, you didn't miss anything.
>> >
>> > One proposal:
>> >
>> > https://lkml.org/lkml/2014/8/21/255
>>
>> Thanks for the link!
>>
>> Here's the equivalent gmane link for my own reference:
>> http://thread.gmane.org/gmane.linux.kernel/1771969
>>
>> Basically, if I understand correctly, Ingo NAKed the patch, saying
>> this should be done automatically by the toolchain. That would make
>> for an interesting side-project...
>
> True.  It's probably not feasible though.
>
> Tracking string deduplication/reuse would be pretty difficult.

Yep, that's why I simply didn't attempt to write a "toolchain" to
automatically put strings into the appropriate section. String
annotation and deduplication is best done in the compiler. It already
does impressive tricks to limit the amount of actual strings ending up
in the binary. If one would try to write a compiler plugin to
automatically flag __init / __exit strings it would have to be an LTO
pass as only there one would have the complete view where the string
will end up. It's not as simple as blindly marking all strings used in
__init / __exit functions to end up in the corresponding .rodata
section because those strings may be passed to functions that want to
keep a pointer, e.g. as an object name. But not all functions do! So
only an LTO pass *may* see the whole usage of a possible __init /
__exit string. Therefore I'm still not convinced that solving the
problem in the toolchain is the right thing to do. It's *way* more
complicated and probably gets it wrong more often than not. Therefore
the straight simple approach of manually marking the strings is IMHO
the best solution. Unfortunately, not everyone shares this opinion :/

Mathias

WARNING: multiple messages have this Message-ID (diff)
From: minipli@googlemail.com (Mathias Krause)
To: linux-arm-kernel@lists.infradead.org
Subject: String literals in __init functions
Date: Thu, 26 Mar 2015 17:37:00 +0100	[thread overview]
Message-ID: <CA+rthh9Fb2q+O_wicc6eNcbo6SzwOVZed=tnThJLF-xuoQ-+Cw@mail.gmail.com> (raw)
In-Reply-To: <1427386390.15849.13.camel@perches.com>

On 26 March 2015 at 17:13, Joe Perches <joe@perches.com> wrote:
> On Thu, 2015-03-26 at 13:40 +0100, Mason wrote:
>> On 25/03/2015 19:01, Joe Perches wrote:
>> > On Wed, 2015-03-25 at 18:56 +0100, Mason wrote:
>> >
>> >> AFAIU, functions only used at system init are tagged __init to have
>> >> the linker store them in a separate .init.text section, so memory can
>> >> be reclaimed once initialization is complete. Is that correct?
>> >>
>> >> The corresponding tag for data is __initdata (section .init.data)
>> >>
>> >> I started wondering if the string literals used in an __init functions
>> >> were automatically marked __initdata.
>> >>
>> >> Looking at the objdump output, I see that the string literals are,
>> >> in fact, stored in the .rodata section. I suppose that .rodata is NOT
>> >> reclaimed after init?
>> >>
>> >> [...]
>> >>
>> >> Did I miss something in init.h?
>> >> Or should it be done like above to reclaim string literals?
>> >
>> > No, you didn't miss anything.
>> >
>> > One proposal:
>> >
>> > https://lkml.org/lkml/2014/8/21/255
>>
>> Thanks for the link!
>>
>> Here's the equivalent gmane link for my own reference:
>> http://thread.gmane.org/gmane.linux.kernel/1771969
>>
>> Basically, if I understand correctly, Ingo NAKed the patch, saying
>> this should be done automatically by the toolchain. That would make
>> for an interesting side-project...
>
> True.  It's probably not feasible though.
>
> Tracking string deduplication/reuse would be pretty difficult.

Yep, that's why I simply didn't attempt to write a "toolchain" to
automatically put strings into the appropriate section. String
annotation and deduplication is best done in the compiler. It already
does impressive tricks to limit the amount of actual strings ending up
in the binary. If one would try to write a compiler plugin to
automatically flag __init / __exit strings it would have to be an LTO
pass as only there one would have the complete view where the string
will end up. It's not as simple as blindly marking all strings used in
__init / __exit functions to end up in the corresponding .rodata
section because those strings may be passed to functions that want to
keep a pointer, e.g. as an object name. But not all functions do! So
only an LTO pass *may* see the whole usage of a possible __init /
__exit string. Therefore I'm still not convinced that solving the
problem in the toolchain is the right thing to do. It's *way* more
complicated and probably gets it wrong more often than not. Therefore
the straight simple approach of manually marking the strings is IMHO
the best solution. Unfortunately, not everyone shares this opinion :/

Mathias

  reply	other threads:[~2015-03-26 16:37 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-25 17:56 String literals in __init functions Mason
2015-03-25 17:56 ` Mason
2015-03-25 18:01 ` Joe Perches
2015-03-25 18:01   ` Joe Perches
2015-03-26 12:40   ` Mason
2015-03-26 12:40     ` Mason
2015-03-26 16:13     ` Joe Perches
2015-03-26 16:13       ` Joe Perches
2015-03-26 16:37       ` Mathias Krause [this message]
2015-03-26 16:37         ` Mathias Krause
2015-03-26 17:53         ` Joe Perches
2015-03-26 17:53           ` Joe Perches
2015-03-26 20:49           ` Mathias Krause
2015-03-26 20:49             ` Mathias Krause
2015-03-26 21:40             ` Andrew Morton
2015-03-26 21:40               ` Andrew Morton
2015-03-26 21:58               ` Joe Perches
2015-03-26 21:58                 ` Joe Perches
2015-03-26 22:15                 ` Andrew Morton
2015-03-26 22:15                   ` Andrew Morton
2015-03-27  7:16                   ` Mathias Krause
2015-03-27  7:16                     ` Mathias Krause
2015-04-02 16:00                 ` Joseph Myers
2015-04-02 16:00                   ` Joseph Myers
2015-04-02 16:23                   ` Joe Perches
2015-04-02 16:23                     ` Joe Perches
2015-03-27  7:05               ` Mathias Krause
2015-03-27  7:05                 ` Mathias Krause
2015-03-27  7:32                 ` Joe Perches
2015-03-27  7:32                   ` Joe Perches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+rthh9Fb2q+O_wicc6eNcbo6SzwOVZed=tnThJLF-xuoQ-+Cw@mail.gmail.com' \
    --to=minipli@googlemail.com \
    --cc=joe@perches.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=minipli@gmail.com \
    --cc=slash.tmp@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.