linux-kernel - Re: [RFC] Sectionized printk data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20080209235433.GS4352@ghostprotocols.net>
Date:	Sat, 9 Feb 2008 21:54:33 -0200
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Jan Engelhardt <jengelh@...putergmbh.de>
Cc:	Sam Ravnborg <sam@...nborg.org>,
	Johannes Weiner <hannes@...urebad.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Sectionized printk data

Em Sat, Feb 09, 2008 at 11:08:45PM +0100, Jan Engelhardt escreveu:
> 
> On Feb 4 2008 19:07, Sam Ravnborg wrote:
> >> The attached patch allows something along the lines:
> >> 
> >> int __init some_function(void)
> >> {
> >>         [...]
> >>         pr_init(KERN_WARNING "failure %s in %s\n", ...);
> >>         [...]
> >> }
> >> 
> >> Another idea I had was to make printk a macro that figures out the
> >> section of the surrounding function and then moves the data
> >> automatically when it is a literal, but I couldn't find mechanisms that
> >> allow this.  Anyone of you got an idea?
> >> 
> >> What do you think in general?
> >
> >What is the rationale behind this?
> 
> To drop strings that are only shown once anyway, such as:
> 
> static int __init ebtables_init(void)
> {
>         int ret;
> 
>         mutex_lock(&ebt_mutex);
>         list_add(&ebt_standard_target.list, &ebt_targets);
>         mutex_unlock(&ebt_mutex);
>         if ((ret = nf_register_sockopt(&ebt_sockopts)) < 0)
>                 return ret;
> 
> ->      printk(KERN_INFO "Ebtables v2.0 registered\n");
>         return 0;
> }
> 
> >If you say "saving memory" then please let us know with specific examples
> >in what area these savings will really pay off.

A long time ago I played with this, using a sparse based tool that was
inserted as the compiler and modified the code before passing to gcc,
i.e. a pre-pre-processor:

http://www.kernel.org/pub/linux/kernel/people/acme/sparse/initstr.c

I couldn't find in the archives, but IIRC some extra pages were freed
after boot, i.e. strings moved from .data to .init.data.

With a tool like this the advantage is that no source code has to be
changed, strings in __init functions are automagically moved to
.init.data, the disadvantage is that not all strings can be moved to
.init.data as there were (are?) subsystems that keep pointers to the
string passed and another tool would be involved in the build process.

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