Re: [PATCH] mm: poison struct page for ptlock

[Hugh Dickins]

On Fri, 4 Nov 2005, Andrew Morton wrote:
> Hugh Dickins <hugh@xxxxxxxxxxx> wrote:
> 
> > While leaving most of the page_private() mods in place for the moment,
> > 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 beyond ->lru; with poisoning of the fields overlaid,
> > and unsplit config verifying that the split config is safe to use them.
> 
> Does your family know you do this sort of thing?

They are beginning to suspect it, so I've made sure they're still asleep.

> What happened to my suggestion that we use anonymous structs here, and
> abandon gcc-2.9x?

Much as I'd hate split ptlock to enlarge struct page, I'd hate it to be
the last straw that forced you off gcc-2.9x: it does not deserve that.

But also, I just misunderstood you until now: I'd been stupidly thinking
you meant an anonymous union in place of your current u there; whereas
you meant extending the union to cover mapping, index, lru.   Hmm.

Well, if you're actively seeking a excuse to abandon gcc-2.9x?  But
although you're its best-known advocate, I think you're not alone.
Shall we wait for a more pressing reason?

> > -#define page_private(page)		((page)->u.private)
> > -#define set_page_private(page, v)	((page)->u.private = (v))
> > +#define page_private(page)		((page)->private)
> > +#define set_page_private(page, v)	((page)->private = (v))
> 
> Need to rename ->private to ->_private here, otherwise people will start
> using page->private again.

I'm happy for people to use page->private again.  I thought we
ought to try out this minimal patch first, for reassurance that the
arches are not using those fields of a pagetable struct page; but that
once it's had some exposure, we'd revert the page_private mods elsewhere.
There's no point to that wrapper with the union gone, is there?

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