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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <478B2C6F.76E4.0078.0@novell.com>
Date:	Mon, 14 Jan 2008 08:33:35 +0000
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Sam Ravnborg" <sam@...nborg.org>
Cc:	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] __cpuinitconst and __devinitconst

>>> Sam Ravnborg <sam@...nborg.org> 13.01.08 22:42 >>>
>> And I found another small buglet too. I hope to post a complete
>> solution later today.
>
>The modpost bits turned out to take longer than expected so 
>they are not done yet. The problem was the modpost structure
>were not prepared for adding such additional chacks.
>So I reworked those bits and the patch has been sent out for review.
>
>What follows here is the changes for init.h + all linker scripts
>to show the idea.
>
>Next step is to beat modpost in shape and to post this on linux-arch.
>
>Note - in -mm there are changes to init.h so the logic
>to decide type of __meminit notation is much simpler.

Yes, I certainly like this concept. What I would have wanted in that patch,
though, is that the read-only data would right away be included in
RODATA() rather than being put in DATA_DATA. Also, to shorten the
names a little, how about .{cpu,mem,dev}init.rodata?

The one thing that I'm not sure is really consistent yet wrt. the
constification is that now you need to write e.g.

static const char __cpuinitcdata example[];

and (accidentally) omitting the 'const' (as it's really an apparently
redundant thing now) as in

static char __cpuinitcdata example[];

will cause section type conflicts (at the compiler or linker level). I
therefore think that the 'const' should really be part of the
__{cpu,mem,dev}cdata definitions (requiring the attribute to be
placed properly, namely placement at the end of a declaration as
is possible with __{cpu,mem,dev}initdata is then not an option here).

Jan

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