Core kernel expect swp_entry_t to be consisting of
only swap type and swap offset. We should not leak pte bits to
swp_entry_t. This breaks swapoff which use the swap type and offset
to build a swp_entry_t and later compare that to the swp_entry_t
obtained from linux page table pte. Leaking pte bits to swp_entry_t
breaks that comparison and results in us looping in try_to_unuse.
The stack trace can be anywhere below try_to_unuse() in mm/swapfile.c,
since swapoff is circling around and around that function, reading from
each used swap block into a page, then trying to find where that page
belongs, looking at every non-file pte of every mm that ever swapped.
Reported-by: Hugh Dickins <hughd@google.com>
Suggested-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Aneesh Kumar K.V <redacted>
---
Changes from V1:
* improve change log and code comment
arch/powerpc/include/asm/book3s/64/pgtable.h | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
Core kernel expect swp_entry_t to be consisting of
only swap type and swap offset. We should not leak pte bits to
swp_entry_t. This breaks swapoff which use the swap type and offset
to build a swp_entry_t and later compare that to the swp_entry_t
obtained from linux page table pte. Leaking pte bits to swp_entry_t
breaks that comparison and results in us looping in try_to_unuse.
The stack trace can be anywhere below try_to_unuse() in mm/swapfile.c,
since swapoff is circling around and around that function, reading from
each used swap block into a page, then trying to find where that page
belongs, looking at every non-file pte of every mm that ever swapped.
Reported-by: Hugh Dickins <hughd@google.com>
Suggested-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Aneesh Kumar K.V <redacted>
I think we've seen enough of my name above, but if it helps further
Acked-by: Hugh Dickins <hughd@google.com>
Though I don't find the code comment below on swp_entry_t enlightening -
your commit description above is much more helpful. If I were writing it,
I might say... hmm, it's too hard: given all the convolutions, I gave up.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2016-01-12 00:03:45
On Mon, 2016-01-11 at 21:19 +0530, Aneesh Kumar K.V wrote:
Core kernel expect swp_entry_t to be consisting of
only swap type and swap offset. We should not leak pte bits to
swp_entry_t. This breaks swapoff which use the swap type and offset
to build a swp_entry_t and later compare that to the swp_entry_t
obtained from linux page table pte. Leaking pte bits to swp_entry_t
breaks that comparison and results in us looping in try_to_unuse.
The stack trace can be anywhere below try_to_unuse() in mm/swapfile.c,
since swapoff is circling around and around that function, reading from
each used swap block into a page, then trying to find where that page
belongs, looking at every non-file pte of every mm that ever swapped.
Reported-by: Hugh Dickins <hughd@google.com>
Suggested-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Aneesh Kumar K.V <redacted>
Thanks. I slightly edited the wording in the change log and added:
Fixes: 6a119eae942c ("powerpc/mm: Add a _PAGE_PTE bit")
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2016-01-12 12:32:53
On Mon, 2016-11-01 at 15:49:34 UTC, "Aneesh Kumar K.V" wrote:
Core kernel expect swp_entry_t to be consisting of
only swap type and swap offset. We should not leak pte bits to
swp_entry_t. This breaks swapoff which use the swap type and offset
to build a swp_entry_t and later compare that to the swp_entry_t
obtained from linux page table pte. Leaking pte bits to swp_entry_t
breaks that comparison and results in us looping in try_to_unuse.
The stack trace can be anywhere below try_to_unuse() in mm/swapfile.c,
since swapoff is circling around and around that function, reading from
each used swap block into a page, then trying to find where that page
belongs, looking at every non-file pte of every mm that ever swapped.
Reported-by: Hugh Dickins <hughd@google.com>
Suggested-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Aneesh Kumar K.V <redacted>
Acked-by: Hugh Dickins <hughd@google.com>