Re: [rfc][patch] x86: avoid highmem cache attribute aliasing

From: Suresh Siddha
Date: Mon Aug 11 2008 - 15:09:26 EST


On Mon, Aug 11, 2008 at 10:10:19AM -0700, Ingo Molnar wrote:
>
> * Nick Piggin <npiggin@xxxxxxx> wrote:
>
> > Highmem code can leave ptes and tlb entries around for a given page
> > even after kunmap, and after it has been freed.
> >
> > From what I can gather, the PAT code may change the cache attributes
> > of arbitrary physical addresses (ie. including highmem pages), which
> > would result in aliases in the case that it operates on one of these
> > lazy tlb highmem pages.
> >
> > Flushing kmaps should solve the problem.
> >
> > I've also just added code for conditional flushing if we haven't got
> > any dangling highmem aliases -- this should help performance if we
> > change page attributes frequently or systems that aren't using much
> > highmem pages (eg. if < 4G RAM). Should be turned into 2 patches, but
> > just for RFC...
>
> hm, such aliasing might happen in theory - and i guess in practice too
> if the AGP driver allocates/deallocates aperture in short succession.
>
> Maybe this could corrupt the X framebuffer - or even generic kernel RAM.
> Mind resending the two split up patches? The fix we might want to take
> into v2.6.27, the speedup probably for v2.6.28.
>
> But maybe i'm missing something obvious that prevents such problems on
> 32-bit systems - Venki, Suresh, what do you think?

Andi pointed out in another thread that we don't use GFP_HIGHMEM in the
AGP drivers. And hence we haven't encountered an issue so far. But yes,
this is a good fix to close the hole.

thanks,
suresh
--
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/