linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/3] Simplify set_huge_pte_at, pte_same for LPAE
Date: Tue, 3 Dec 2013 15:09:25 +0000	[thread overview]
Message-ID: <20131203150924.GE12370@arm.com> (raw)
In-Reply-To: <20131203134623.GA24994@linaro.org>

On Tue, Dec 03, 2013 at 01:46:24PM +0000, Steve Capper wrote:
> On Tue, Nov 19, 2013 at 05:35:26PM +0000, Steve Capper wrote:
> > The following patch series is my attempt at fixing a rather nasty bug
> > which became visible in 3.12-rc1 when running the libhugetlbfs test
> > suite. (This problem only just came to my attention yesterday).
> > 
> > For LPAE, set_huge_pte_at calls set_pte_at which then calls
> > set_pte_ext, which in turn is wired up to call cpu_v7_set_pte_ext,
> > which is defined in proc-v7-3level.S.
> > 
> > For huge pages, given newprot a pgprot_t value for a shared writable
> > VMA, and ptep a pointer to a pte belonging to this VMA; the following
> > behaviour is assumed by core code:
> >    hugetlb_change_protection(vma, address, end, newprot);
> >    ...
> > 
> >    huge_pte_write(huge_ptep_get(ptep)); /* should be true! */
> > 
> > Unfortunately, cpu_v7_set_pte_ext will change the bit layout of the
> > resultant pte, and will set the read only bit if the dirty bit is not
> > also enabled.
> 
> A question has been raised for the arm64 analogue of this series as to
> whether or not this is the best approach:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/215155.html
> 
> I am having a think about this, and will send out a V2 once my brain
> has caught up. :-)

I think we first need to check we don't actually do a CoW for any clean
anonymous small page just because pte_dirty and pte_write use the same
PTE_RDONLY bit (both arm+LPAE and arm64). Once that's fixed, I don't
think you need any hugetlb changes.

Basically we need to encode these states:

				PTE_DIRTY	PTE_RDONLY
!pte_dirty && !pte_write	0		1
!pte_dirty && pte_write		0		1
pte_dirty && !pte_write		1		1
pte_dirty && pte_write		1		0

So we can't distinguish between the first two with just two bits since
PTE_RDONLY is a hardware bit.

My proposal would be for PTE_WRITE bit with PTE_RDONLY only set in the
set_pte() function (if !pte_dirty || !pte_write).

-- 
Catalin

      reply	other threads:[~2013-12-03 15:09 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19 17:35 [PATCH 0/3] Simplify set_huge_pte_at, pte_same for LPAE Steve Capper
2013-11-19 17:35 ` [PATCH 1/3] ARM: mm: Rewire LPAE set_huge_pte_at Steve Capper
2013-11-19 17:35 ` [PATCH 2/3] ARM: mm: Make LPAE huge page ptes NG by default Steve Capper
2013-11-19 17:35 ` [PATCH 3/3] Revert "ARM: mm: correct pte_same behaviour for LPAE." Steve Capper
2013-11-19 18:02 ` [PATCH 0/3] Simplify set_huge_pte_at, pte_same for LPAE Christoffer Dall
2013-12-03 13:46 ` Steve Capper
2013-12-03 15:09   ` Catalin Marinas [this message]

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=20131203150924.GE12370@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).