Re: [PATCH 01/15] mm: poison struct page for ptlock

From: Andrew Morton
Date: Tue Nov 15 2005 - 13:49:18 EST


Andrew Morton <akpm@xxxxxxxx> wrote:
>
> Hugh Dickins <hugh@xxxxxxxxxxx> wrote:
> >
> > The split ptlock patch enlarged the default SMP PREEMPT struct page from
> > 32 to 36 bytes on most 32-bit platforms, from 32 to 44 bytes on PA-RISC
> > 7xxx (without PREEMPT). That was not my intention, and I don't believe
> > that split ptlock deserves any such slice of the user's memory.
> >
> > Could we please try this patch, or something like it? Again to overlay
> > the spinlock_t from &page->private onwards, with corrected BUILD_BUG_ON
> > that we don't go too far; with poisoning of the fields overlaid, and
> > unsplit SMP config verifying that the split config is safe to use them.
> >
> > The previous attempt at this patch broke ppc64, which uses slab for its
> > page tables - and slab saves vital info in page->lru: but no config of
> > spinlock_t needs to overwrite lru on 64-bit anyway; and the only 32-bit
> > user of slab for page tables is arm26, which is never SMP i.e. all the
> > problems came from the "safety" checks, not from what's actually needed.
> > So previous checks refined with #ifdefs, and a BUG_ON(PageSlab) added.
> >
> > This overlaying is unlikely to be portable forever: but the added checks
> > should warn developers when it's going to break, long before any users.
>
> argh.
>
> Really, I'd prefer to abandon gcc-2.95.x rather than this. Look:
>
> struct a
> {
> union {
> struct {
> int b;
> int c;
> };
> int d;
> };
> } z;
>
> main()
> {
> z.b = 1;
> z.d = 1;
> }
>
> It does everything we want.

It occurs to me that we can do the above if (__GNUC__ > 2), or whatever.

That way, the only people who have a 4-byte-larger pageframe are those who
use CONFIG_PREEMPT, NR_CPUS>=4 and gcc-2.x.y. An acceptably small
community, I suspect.


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