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

[Andrew Morton <akpm@osdl.org>]

Andrew Morton <akpm@osdl.org> wrote:
>
> Hugh Dickins <hugh@veritas.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/