linux-kernel - Re: [PATCH 0/4] __cpuinitconst and _

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080111194428.GB29189@uranus.ravnborg.org>
Date:	Fri, 11 Jan 2008 20:44:28 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Jan Beulich <jbeulich@...ell.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] __cpuinitconst and __devinitconst

Hi Jan.

On Fri, Jan 11, 2008 at 08:55:29AM +0000, Jan Beulich wrote:
> Since __cpuinitdata/__devinitdata don't allow const to be specified with
> them (otherwise .init.data sections with and without the writeable attribute
> will be generated by the compiler), and since __devinitdata except for
> embedded systems evaluates to <empty> unconditionally and
> __cpuinitdata at least in most production kernel configurations also
> likely evaluates to <empty>, it seems appropriate to add an additional
> attribute allowing the respective objects to end up in .rodata rather than
> .data when not used at initialization time only.

How about a slightly diffrent approach...
Consider
__cpuinitconst => function is placed in section .init.const.text
__devinitconst => function is placed in section .init.const.text

Then we in the linker scrip can distingush between the two
and locate the sections as appropriate.

This will require some updates to modpost but are align with an
idea I have had for a while.
All of the following should have dedicated sections associated
unconditionally:

__init
__cpuinit
__meminit
__initdata
__cpuinitdata
__meminitdata

And then in the linker script we decide what to do with the section.
In the built-in case we put them in the "to-be-discarded" section.
In the module case we put them as today.

The primary tasks needed to accomplish this is:
1) Update all arch linker scripts (and some of them looks ugly)
2) Teach modpost about the new sections

If you following the suggestion above this is a simple step
in this direction which would be good.

Comments?

	Sam
--
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/