From: Michael Ellerman <patch-notifications@ellerman.id.au>
To: Michael Ellerman <mpe@ellerman.id.au>, linuxppc-dev@ozlabs.org
Cc: linux-mm@kvack.org, jack@suse.cz,
aneesh.kumar@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
erhard_f@mailbox.org
Subject: Re: powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present()
Date: Sun, 17 Feb 2019 19:21:37 +1100 (AEDT) [thread overview]
Message-ID: <442Khx2lFLz9sDX@ozlabs.org> (raw)
In-Reply-To: <20190214062339.7139-1-mpe@ellerman.id.au>
On Thu, 2019-02-14 at 06:23:39 UTC, Michael Ellerman wrote:
> In v4.20 we changed our pgd/pud_present() to check for _PAGE_PRESENT
> rather than just checking that the value is non-zero, e.g.:
>
> static inline int pgd_present(pgd_t pgd)
> {
> - return !pgd_none(pgd);
> + return (pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT));
> }
>
> Unfortunately this is broken on big endian, as the result of the
> bitwise && is truncated to int, which is always zero because
> _PAGE_PRESENT is 0x8000000000000000ul. This means pgd_present() and
> pud_present() are always false at compile time, and the compiler
> elides the subsequent code.
>
> Remarkably with that bug present we are still able to boot and run
> with few noticeable effects. However under some work loads we are able
> to trigger a warning in the ext4 code:
>
> WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927 .ext4_set_page_dirty+0x70/0xb0
> CPU: 11 PID: 29593 Comm: debugedit Not tainted 4.20.0-rc1 #1
> ...
> NIP .ext4_set_page_dirty+0x70/0xb0
> LR .set_page_dirty+0xa0/0x150
> Call Trace:
> .set_page_dirty+0xa0/0x150
> .unmap_page_range+0xbf0/0xe10
> .unmap_vmas+0x84/0x130
> .unmap_region+0xe8/0x190
> .__do_munmap+0x2f0/0x510
> .__vm_munmap+0x80/0x110
> .__se_sys_munmap+0x14/0x30
> system_call+0x5c/0x70
>
> The fix is simple, we need to convert the result of the bitwise && to
> an int before returning it.
>
> Thanks to Jan Kara and Aneesh for help with debugging.
>
> Fixes: da7ad366b497 ("powerpc/mm/book3s: Update pmd_present to look at _PAGE_PRESENT bit")
> Cc: stable@vger.kernel.org # v4.20+
> Reported-by: Erhard F. <erhard_f@mailbox.org>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/a58007621be33e9f7c7bed5d5ff8ecb9
cheers
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <patch-notifications@ellerman.id.au>
To: Michael Ellerman <mpe@ellerman.id.au>, linuxppc-dev@ozlabs.org
Cc: linux-mm@kvack.org, erhard_f@mailbox.org, jack@suse.cz,
aneesh.kumar@linux.vnet.ibm.com, linux-kernel@vger.kernel.org
Subject: Re: powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present()
Date: Sun, 17 Feb 2019 19:21:37 +1100 (AEDT) [thread overview]
Message-ID: <442Khx2lFLz9sDX@ozlabs.org> (raw)
In-Reply-To: <20190214062339.7139-1-mpe@ellerman.id.au>
On Thu, 2019-02-14 at 06:23:39 UTC, Michael Ellerman wrote:
> In v4.20 we changed our pgd/pud_present() to check for _PAGE_PRESENT
> rather than just checking that the value is non-zero, e.g.:
>
> static inline int pgd_present(pgd_t pgd)
> {
> - return !pgd_none(pgd);
> + return (pgd_raw(pgd) & cpu_to_be64(_PAGE_PRESENT));
> }
>
> Unfortunately this is broken on big endian, as the result of the
> bitwise && is truncated to int, which is always zero because
> _PAGE_PRESENT is 0x8000000000000000ul. This means pgd_present() and
> pud_present() are always false at compile time, and the compiler
> elides the subsequent code.
>
> Remarkably with that bug present we are still able to boot and run
> with few noticeable effects. However under some work loads we are able
> to trigger a warning in the ext4 code:
>
> WARNING: CPU: 11 PID: 29593 at fs/ext4/inode.c:3927 .ext4_set_page_dirty+0x70/0xb0
> CPU: 11 PID: 29593 Comm: debugedit Not tainted 4.20.0-rc1 #1
> ...
> NIP .ext4_set_page_dirty+0x70/0xb0
> LR .set_page_dirty+0xa0/0x150
> Call Trace:
> .set_page_dirty+0xa0/0x150
> .unmap_page_range+0xbf0/0xe10
> .unmap_vmas+0x84/0x130
> .unmap_region+0xe8/0x190
> .__do_munmap+0x2f0/0x510
> .__vm_munmap+0x80/0x110
> .__se_sys_munmap+0x14/0x30
> system_call+0x5c/0x70
>
> The fix is simple, we need to convert the result of the bitwise && to
> an int before returning it.
>
> Thanks to Jan Kara and Aneesh for help with debugging.
>
> Fixes: da7ad366b497 ("powerpc/mm/book3s: Update pmd_present to look at _PAGE_PRESENT bit")
> Cc: stable@vger.kernel.org # v4.20+
> Reported-by: Erhard F. <erhard_f@mailbox.org>
> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc fixes.
https://git.kernel.org/powerpc/c/a58007621be33e9f7c7bed5d5ff8ecb9
cheers
next prev parent reply other threads:[~2019-02-17 8:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 6:23 [PATCH] powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present() Michael Ellerman
2019-02-14 6:23 ` Michael Ellerman
2019-02-14 16:31 ` Jan Kara
2019-02-14 16:31 ` Jan Kara
2019-02-16 10:55 ` Balbir Singh
2019-02-16 10:55 ` Balbir Singh
2019-02-16 14:22 ` Segher Boessenkool
2019-02-16 14:22 ` Segher Boessenkool
2019-02-17 6:23 ` Balbir Singh
2019-02-17 6:23 ` Balbir Singh
2019-02-17 8:34 ` Michael Ellerman
2019-02-17 21:55 ` Balbir Singh
2019-02-17 21:55 ` Balbir Singh
2019-02-18 0:49 ` Michael Ellerman
2019-02-18 0:49 ` Michael Ellerman
2019-02-19 12:01 ` Balbir Singh
2019-02-19 12:01 ` Balbir Singh
2019-02-19 20:15 ` Segher Boessenkool
2019-02-19 20:15 ` Segher Boessenkool
2019-02-20 11:18 ` Michael Ellerman
2019-02-20 11:18 ` Michael Ellerman
2019-02-20 14:51 ` Segher Boessenkool
2019-02-20 14:51 ` Segher Boessenkool
2019-02-17 8:34 ` Michael Ellerman
2019-02-16 13:15 ` Andreas Schwab
2019-02-16 13:15 ` Andreas Schwab
2019-02-17 8:26 ` Michael Ellerman
2019-02-17 8:26 ` Michael Ellerman
2019-02-17 8:21 ` Michael Ellerman [this message]
2019-02-17 8:21 ` Michael Ellerman
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=442Khx2lFLz9sDX@ozlabs.org \
--to=patch-notifications@ellerman.id.au \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=erhard_f@mailbox.org \
--cc=jack@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mpe@ellerman.id.au \
/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.