| Message ID | 20201008092541.398079-1-aneesh.kumar@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | mm: Avoid using set_pte_at when updating a present pte | expand |
Ahh, and I should learn to read all my emails before replying to some of them.. On Thu, Oct 8, 2020 at 2:26 AM Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> wrote: > > This avoids the below warning > [..] > WARNING: CPU: 0 PID: 30613 at arch/powerpc/mm/pgtable.c:185 set_pte_at+0x2a8/0x3a0 arch/powerpc/mm/pgtable.c:185 .. and I assume this is what triggered the other patch too. Yes, with the ppc warning, we need to do _something_ about this, and at that point I think the "something" is to just avoid the pte wrpritect trick. Linus
diff --git a/mm/memory.c b/mm/memory.c index fcfc4ca36eba..bfe202ef6244 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -854,7 +854,7 @@ copy_present_page(struct mm_struct *dst_mm, struct mm_struct *src_mm, * source pte back to being writable. */ if (pte_write(pte)) - set_pte_at(src_mm, addr, src_pte, pte); + ptep_set_access_flags(vma, addr, src_pte, pte, 1); new_page = *prealloc; if (!new_page)
This avoids the below warning WARNING: CPU: 0 PID: 30613 at arch/powerpc/mm/pgtable.c:185 set_pte_at+0x2a8/0x3a0 arch/powerpc/mm/pgtable.c:185 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 30613 Comm: syz-executor.0 Not tainted 5.9.0-rc8-syzkaller-00156-gc85fb28b6f99 #0 Call Trace: [c0000000001cd1f0] panic+0x29c/0x75c kernel/panic.c:231 [c0000000001cce24] __warn+0x104/0x1b8 kernel/panic.c:600 [c000000000d829e4] report_bug+0x1d4/0x380 lib/bug.c:198 [c000000000036800] program_check_exception+0x4e0/0x750 arch/powerpc/kernel/traps.c:1508 [c0000000000098a8] program_check_common_virt+0x308/0x360 --- interrupt: 700 at set_pte_at+0x2a8/0x3a0 arch/powerpc/mm/pgtable.c:185 LR = set_pte_at+0x2a4/0x3a0 arch/powerpc/mm/pgtable.c:185 [c0000000005d2a7c] copy_present_page mm/memory.c:857 [inline] [c0000000005d2a7c] copy_present_pte mm/memory.c:899 [inline] [c0000000005d2a7c] copy_pte_range mm/memory.c:1014 [inline] [c0000000005d2a7c] copy_pmd_range mm/memory.c:1092 [inline] [c0000000005d2a7c] copy_pud_range mm/memory.c:1127 [inline] [c0000000005d2a7c] copy_p4d_range mm/memory.c:1150 [inline] [c0000000005d2a7c] copy_page_range+0x1f6c/0x2cc0 mm/memory.c:1212 [c0000000001c63cc] dup_mmap kernel/fork.c:592 [inline] [c0000000001c63cc] dup_mm+0x77c/0xab0 kernel/fork.c:1355 [c0000000001c8f70] copy_mm kernel/fork.c:1411 [inline] [c0000000001c8f70] copy_process+0x1f00/0x2740 kernel/fork.c:2070 [c0000000001c9b54] _do_fork+0xc4/0x10b0 kernel/fork.c:2429 [c0000000001caf54] __do_sys_clone3+0x1d4/0x2b0 kernel/fork.c:27 Architecture like ppc64 expects set_pte_at to be not used for updating a valid pte. This is further explained in commit 56eecdb912b5 ("mm: Use ptep/pmdp_set_numa() for updating _PAGE_NUMA bit") Cc: Peter Xu <peterx@redhat.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: John Hubbard <jhubbard@nvidia.com> Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jan Kara <jack@suse.cz> Cc: Michal Hocko <mhocko@suse.com> Cc: Kirill Shutemov <kirill@shutemov.name> Cc: Hugh Dickins <hughd@google.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> --- mm/memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)