linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@amd64.org>
To: Rik van Riel <riel@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	akpm@linux-foundation.org, sjhill@mips.com, ralf@linux-mips.org,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Rob Herring <rob.herring@calxeda.com>,
	Russell King <rmk+kernel@arm.linux.org.uk>,
	Nicolas Pitre <nico@linaro.org>
Subject: Re: bugs in page colouring code
Date: Thu, 14 Jun 2012 12:36:27 +0200	[thread overview]
Message-ID: <20120614103627.GA25940@aftab.osrc.amd.com> (raw)
In-Reply-To: <20120613152936.363396d5@cuia.bos.redhat.com>

On Wed, Jun 13, 2012 at 03:29:36PM -0400, Rik van Riel wrote:
> The page colouring code on x86-64, align_addr in sys_x86_64.c is
> slightly more amusing.

This was done with the reviewers' fun level in mind from the very start.

:-)

> For one, there are separate kernel boot arguments to control whether
> 32 and 64 bit processes need to have their addresses aligned for
> page colouring.
> 
> Do we really need that?

Yes.

Mind you, this is only enabled on AMD F15h - all other x86 simply can't
tweak it without code change.

> Would it be a problem if I discarded that code, in order to get to one
> common cache colouring implementation?

Sorry, but, we'd like to keep it in.

> Secondly, MAP_FIXED never checks for page colouring alignment. I
> assume the cache aliasing on AMD Bulldozer is merely a performance
> issue, and we can simply ignore page colouring for MAP_FIXED?

Right, AFAICR, MAP_FIXED is not generally used for shared libs (correct
me if I'm wrong here, my memory is very fuzzy about it) and since we see
the perf issue with shared libs, this was fine.

> That will be easy to get right in an architecture-independent
> implementation.
> 
> 
> A third issue is this:
> 
>         if (!(current->flags & PF_RANDOMIZE))
>                 return addr;
> 
> Do we really want to skip page colouring merely because the 
> application does not have PF_RANDOMIZE set?  What is this
> conditional supposed to do?

Linus said that without this we are probably breaking old userspace
which can't stomach ASLR so we had to respect such userspace which
clears that flag.

> When an app calls mmap with address 0, what breaks by giving it a
> properly page coloured address, instead of the first suitable address
> we find?

Look at dfb09f9b7ab03fd367740e541a5caf830ed56726.

We need bits slice [12:14] in the virtual address to be the same
across all processes mapping the same physical memory otherwise, the
cross-invalidations happen.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2012-06-14 10:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-13 19:29 bugs in page colouring code Rik van Riel
2012-06-14  8:42 ` Paul Mundt
2012-06-14 12:56   ` Rik van Riel
2012-06-14 10:36 ` Borislav Petkov [this message]
2012-06-14 12:57   ` Rik van Riel
2012-06-14 13:20     ` Borislav Petkov
2012-06-14 14:31       ` Ralf Baechle
2012-06-14 20:58     ` H. Peter Anvin
2012-06-14 21:03       ` Rik van Riel
2012-06-14 21:13         ` H. Peter Anvin
2012-06-14 21:20           ` Rik van Riel
2012-06-14 13:20 ` Russell King - ARM Linux
2012-06-14 14:27   ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120614103627.GA25940@aftab.osrc.amd.com \
    --to=bp@amd64.org \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nico@linaro.org \
    --cc=ralf@linux-mips.org \
    --cc=riel@redhat.com \
    --cc=rmk+kernel@arm.linux.org.uk \
    --cc=rob.herring@calxeda.com \
    --cc=sjhill@mips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).