From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@au1.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>,
Anton Blanchard <anton@au1.ibm.com>,
Hugh Dickins <hughd@google.com>,
linuxppc-dev@lists.ozlabs.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: 3.10-rc ppc64 corrupts usermem when swapping
Date: Sun, 02 Jun 2013 12:52:56 +0530 [thread overview]
Message-ID: <8738t1c6y7.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <1370038982.3928.147.camel@pasglop>
Benjamin Herrenschmidt <benh@au1.ibm.com> writes:
> On Fri, 2013-05-31 at 14:45 +0530, Aneesh Kumar K.V wrote:
>
>> > The patch you are running on is what I'll send to Linus for 3.10 (+/-
>> > cosmetics). Aneesh second patch is a much larger rework which will be
>> > needed for THP but that will wait for 3.11. I'm happy for you to test it
>> > but I first want to make sure it's solid with the 3.10 fix :-)
>
> BTW. One concern I still have is that Hugh identified the bad commit
> to be:
>
> 7e74c3921ad9610c0b49f28b8fc69f7480505841
> "powerpc: Fix hpte_decode to use the correct decoding for page sizes".
>
> However, you introduce the return on HPTE not found earlier, in
>
> b1022fbd293564de91596b8775340cf41ad5214c
> "powerpc: Decode the pte-lp-encoding bits correctly."
>
> So while I'm still happy with the current band-aid for 3.10 and am
> about to send it to Linus, the above *does* seem to indicate that
> there is also something wrong with the "Fix hpte_decode..." commit,
> which might not actually get the page size right...
>
> Can you investigate ?
7e74c3921ad9610c0b49f28b8fc69f7480505841
"powerpc: Fix hpte_decode to use the correct decoding for page sizes"
changes should only impact hpte_decode. We don't change the details
of hpte_actual_psize at all in this patch. That means we should see a
difference only with kexec right ?.
Hugh,
Will you be able to double check whether
7e74c3921ad9610c0b49f28b8fc69f7480505841 is the bad commit. The one
before that is what we changed in the patch that fixed your problem.
-aneesh
next prev parent reply other threads:[~2013-06-02 7:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-30 5:47 3.10-rc ppc64 corrupts usermem when swapping Hugh Dickins
2013-05-30 7:00 ` Benjamin Herrenschmidt
2013-05-30 8:27 ` Aneesh Kumar K.V
2013-05-30 8:33 ` Benjamin Herrenschmidt
2013-05-30 13:48 ` Hugh Dickins
2013-05-31 5:05 ` Hugh Dickins
2013-05-31 5:31 ` Benjamin Herrenschmidt
2013-05-31 14:45 ` Hugh Dickins
[not found] ` <87ppw7mrx7.fsf@linux.vnet.ibm.com>
2013-05-31 22:23 ` Benjamin Herrenschmidt
2013-06-02 7:22 ` Aneesh Kumar K.V [this message]
2013-06-02 18:19 ` Hugh Dickins
2013-05-30 16:10 ` Aneesh Kumar K.V
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=8738t1c6y7.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=anton@au1.ibm.com \
--cc=benh@au1.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=hughd@google.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.