From mboxrd@z Thu Jan 1 00:00:00 1970 From: joe@perches.com (Joe Perches) Date: Thu, 26 Mar 2015 10:53:13 -0700 Subject: String literals in __init functions In-Reply-To: References: <5512F6C6.1020304@free.fr> <1427306517.2717.0.camel@perches.com> <5513FE2F.3040306@free.fr> <1427386390.15849.13.camel@perches.com> Message-ID: <1427392393.15849.16.camel@perches.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, 2015-03-26 at 17:37 +0100, Mathias Krause wrote: > On 26 March 2015 at 17:13, Joe Perches 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 :/ At least a few do though. The first 4 patches still apply and are useful in my opinion. Maybe you could resend them as a new patch set and cc Andrew Morton. (cc'd here too) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752531AbbCZRxT (ORCPT ); Thu, 26 Mar 2015 13:53:19 -0400 Received: from smtprelay0215.hostedemail.com ([216.40.44.215]:58285 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752130AbbCZRxS (ORCPT ); Thu, 26 Mar 2015 13:53:18 -0400 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 50,0,0,,d41d8cd98f00b204,joe@perches.com,:::::::::::,RULES_HIT:41:355:379:541:599:800:960:967:973:988:989:1260:1263:1277:1311:1313:1314:1345:1359:1373:1437:1515:1516:1518:1534:1543:1593:1594:1605:1711:1730:1747:1777:1792:2194:2199:2393:2525:2553:2561:2564:2682:2685:2692:2693:2828:2859:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3315:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4470:5007:6119:6261:7903:8599:8792:9025:9040:9108:10004:10226:10400:10450:10455:10848:11232:11658:11914:12043:12257:12517:12519:12555:12663:12740:12926:13161:13229:13869:14096:14097:19904:19999:21080,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0 X-HE-Tag: bulb58_3976947d1d71c X-Filterd-Recvd-Size: 4156 Message-ID: <1427392393.15849.16.camel@perches.com> Subject: Re: String literals in __init functions From: Joe Perches To: Mathias Krause , Andrew Morton Cc: Mason , Linux ARM , LKML , Ingo Molnar Date: Thu, 26 Mar 2015 10:53:13 -0700 In-Reply-To: References: <5512F6C6.1020304@free.fr> <1427306517.2717.0.camel@perches.com> <5513FE2F.3040306@free.fr> <1427386390.15849.13.camel@perches.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.12.10-0ubuntu1~14.10.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2015-03-26 at 17:37 +0100, Mathias Krause wrote: > On 26 March 2015 at 17:13, Joe Perches 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 :/ At least a few do though. The first 4 patches still apply and are useful in my opinion. Maybe you could resend them as a new patch set and cc Andrew Morton. (cc'd here too)