From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1DBD3C38A2D for ; Thu, 27 Oct 2022 01:48:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7EE928E0002; Wed, 26 Oct 2022 21:48:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 79F1E8E0001; Wed, 26 Oct 2022 21:48:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 666678E0002; Wed, 26 Oct 2022 21:48:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 57CC98E0001 for ; Wed, 26 Oct 2022 21:48:42 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1EA1AC0592 for ; Thu, 27 Oct 2022 01:48:42 +0000 (UTC) X-FDA: 80065045284.16.70C2E68 Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) by imf29.hostedemail.com (Postfix) with ESMTP id C04A7120040 for ; Thu, 27 Oct 2022 01:48:41 +0000 (UTC) Received: by mail-qv1-f49.google.com with SMTP id c8so11606qvn.10 for ; Wed, 26 Oct 2022 18:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=LjF5WJ/5nIJrcaTZzzLDZvM3WvamyAQiIifVrONITDo=; b=cH6Eb4I0yW3Gc/F4bwQrIPB5+QCmkFlNfzebKe7e/DqPSu6m2LCghXWsFVMIh54PJd QnlxoaeEQj78BiwCsPZ5snf9vLD/mfi+d7OJJCRE16zWQ/VJ7LkYz8wB7+ijOklFm9mk jy9FIzWXdZbtBOvu3xLtHQooXARYtoJdosi0q3KrDUVKgFZzcMypg7Oi595h4kb1zboK s49nb+J60kgdgfi+mh7+cEf0PfzGyHx7OOCpA9+I6MBaArkBiVkC2LAqgEM8BKZJPNfs 5e+6xEEQuBUPYbsflG52682zaqgIyzlEtW/OdPOQzgPlDxHvo6FElt8EIJZzlf+ffeRd WtGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LjF5WJ/5nIJrcaTZzzLDZvM3WvamyAQiIifVrONITDo=; b=NqKn+UA2Fx1tmKE+G3e/PJ88ZqmFELPWUNH3W4RssRGNCykNLe1MR87mSPQQTR6C0a mPLPo7CC1dj+9/ZBtOfOaz3yQpz+6cL6K8TRXnFPt0HSXVrcCyb+Y28Yir5XczIjeEvG FGtMoewSdqf2Yg2ItVTxTqb8UkgkxwyjoWHPUtIiOBCX1JsuK9eUnagmOaF7GmDbAyVh rN/miAkWYOuT2b56dfy9S34zMtbvIcp3XBzn5Beu3jpgMh0a5K5mOVx9/gNjM+0+T3gf grfmGkDsiTp+0ld3djkp4BbpTqTRrPFdtd/3dpTtKAp+FgwuXoHph67k1VIDrL2lGc2Z 70iQ== X-Gm-Message-State: ACrzQf0h6egpO6yZ6Zft9kKKA5nvgjJXHX0pGV/ARsef33YaQLy9M/zK uKW2Q7R0rS2cgVDMQ2jJFDMO3A== X-Google-Smtp-Source: AMsMyM63cNcG81thh/X0xFu3/9/+XsQCc882T+opMeVuLK+zUp02aEARqHGYACht81XLZQbT41q66Q== X-Received: by 2002:ad4:5fc5:0:b0:4bb:6360:e80 with SMTP id jq5-20020ad45fc5000000b004bb63600e80mr19480596qvb.63.1666835320786; Wed, 26 Oct 2022 18:48:40 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id fy21-20020a05622a5a1500b0039c72bb51f3sm105211qtb.86.2022.10.26.18.48.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Oct 2022 18:48:39 -0700 (PDT) Date: Wed, 26 Oct 2022 18:48:29 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Peter Xu cc: Hugh Dickins , Yuanzheng Song , akpm@linux-foundation.org, gregkh@linuxfoundation.org, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH STABLE 5.10] mm/memory: add non-anonymous page check in the copy_present_page() In-Reply-To: Message-ID: References: <20221024094911.3054769-1-songyuanzheng@huawei.com> <3823471f-6dda-256e-e082-718879c05449@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666835321; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LjF5WJ/5nIJrcaTZzzLDZvM3WvamyAQiIifVrONITDo=; b=R4EFddjVfKv+X/GmrfulLj/J4pqBTIMTK6CrB+N3x2x2ZtYM98LXrH2a11u5ynVuWPSN2k +am+w38/7xqNKo524KvLG3xuCvT5iWuz+A85+5OwXeAqpm8ohJgjL0tNThQHh8bwtbecnT Sym2teqcAb3aU1PPHUrpoMad7/Iz2Ag= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=cH6Eb4I0; spf=pass (imf29.hostedemail.com: domain of hughd@google.com designates 209.85.219.49 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666835321; a=rsa-sha256; cv=none; b=vrjFmafeiwJVXCzb4wtDrdq4CcX2T+kYl5+S0iZSiz8SG1H+Utc1NNiACT4zwskpSAAxhP Xz9JOOEAw/GOpRNJD2A+ufSfmULWgIQpXIVw94vRM0ar3sf4qEwab+0H09daDqlC8QoXT4 LZFwwA5t9BNw2tSzBMEaPEUH64QNdy0= X-Rspamd-Queue-Id: C04A7120040 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=cH6Eb4I0; spf=pass (imf29.hostedemail.com: domain of hughd@google.com designates 209.85.219.49 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Stat-Signature: m1ktch4uzax4qsjobe3hbwkwjk9gmzom X-HE-Tag: 1666835321-302989 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, 26 Oct 2022, Peter Xu wrote: > Hi, Yuanzheng, > > On Wed, Oct 26, 2022 at 02:51:16PM -0700, Hugh Dickins wrote: > > On Mon, 24 Oct 2022, Yuanzheng Song wrote: > > > > > The vma->anon_vma of the child process may be NULL because > > > the entire vma does not contain anonymous pages. In this > > > case, a BUG will occur when the copy_present_page() passes > > > a copy of a non-anonymous page of that vma to the > > > page_add_new_anon_rmap() to set up new anonymous rmap. > > > > > > ------------[ cut here ]------------ > > > kernel BUG at mm/rmap.c:1044! > > > Internal error: Oops - BUG: 0 [#1] SMP > > > Modules linked in: > > > CPU: 2 PID: 3617 Comm: test Not tainted 5.10.149 #1 > > > Hardware name: linux,dummy-virt (DT) > > > pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) > > > pc : __page_set_anon_rmap+0xbc/0xf8 > > > lr : __page_set_anon_rmap+0xbc/0xf8 > > > sp : ffff800014c1b870 > > > x29: ffff800014c1b870 x28: 0000000000000001 > > > x27: 0000000010100073 x26: ffff1d65c517baa8 > > > x25: ffff1d65cab0f000 x24: ffff1d65c416d800 > > > x23: ffff1d65cab5f248 x22: 0000000020000000 > > > x21: 0000000000000001 x20: 0000000000000000 > > > x19: fffffe75970023c0 x18: 0000000000000000 > > > x17: 0000000000000000 x16: 0000000000000000 > > > x15: 0000000000000000 x14: 0000000000000000 > > > x13: 0000000000000000 x12: 0000000000000000 > > > x11: 0000000000000000 x10: 0000000000000000 > > > x9 : ffffc3096d5fb858 x8 : 0000000000000000 > > > x7 : 0000000000000011 x6 : ffff5a5c9089c000 > > > x5 : 0000000000020000 x4 : ffff5a5c9089c000 > > > x3 : ffffc3096d200000 x2 : ffffc3096e8d0000 > > > x1 : ffff1d65ca3da740 x0 : 0000000000000000 > > > Call trace: > > > __page_set_anon_rmap+0xbc/0xf8 > > > page_add_new_anon_rmap+0x1e0/0x390 > > > copy_pte_range+0xd00/0x1248 > > > copy_page_range+0x39c/0x620 > > > dup_mmap+0x2e0/0x5a8 > > > dup_mm+0x78/0x140 > > > copy_process+0x918/0x1a20 > > > kernel_clone+0xac/0x638 > > > __do_sys_clone+0x78/0xb0 > > > __arm64_sys_clone+0x30/0x40 > > > el0_svc_common.constprop.0+0xb0/0x308 > > > do_el0_svc+0x48/0xb8 > > > el0_svc+0x24/0x38 > > > el0_sync_handler+0x160/0x168 > > > el0_sync+0x180/0x1c0 > > > Code: 97f8ff85 f9400294 17ffffeb 97f8ff82 (d4210000) > > > ---[ end trace a972347688dc9bd4 ]--- > > > Kernel panic - not syncing: Oops - BUG: Fatal exception > > > SMP: stopping secondary CPUs > > > Kernel Offset: 0x43095d200000 from 0xffff800010000000 > > > PHYS_OFFSET: 0xffffe29a80000000 > > > CPU features: 0x08200022,61806082 > > > Memory Limit: none > > > ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- > > > > > > This problem has been fixed by the fb3d824d1a46 > > > ("mm/rmap: split page_dup_rmap() into page_dup_file_rmap() and page_try_dup_anon_rmap()"), > > > but still exists in the linux-5.10.y branch. > > > > > > This patch is not applicable to this version because > > > of the large version differences. Therefore, fix it by > > > adding non-anonymous page check in the copy_present_page(). > > > > > > Fixes: 70e806e4e645 ("mm: Do early cow for pinned pages during fork() for ptes") > > > Signed-off-by: Yuanzheng Song > > > > It's a good point, but this patch should not go into any stable release > > without an explicit Ack from either Peter Xu or David Hildenbrand. > > > > To my eye, it's simply avoiding the issue, rather than fixing > > it properly; and even if the issue is so rare, and fixing properly > > too difficult or inefficent (a cached anon_vma?), that a workaround > > is good enough, it still looks like the wrong workaround (checking > > dst_vma->anon_vma instead of PageAnon seems more to the point, and > > less lenient). > > Sorry to have missed this patch. I agree with Hugh that this patch may not > really fix the issue. > > IIUC it's the case where the vma is privately mapping a file. Some shared > pages got pinned, and here we're trying to trigger the CoW assuming it's > anonymous page but it's not. > > The pin should be RO - if it was a write pin, CoW should have happened on > the page cache and there should be an anonymous page, and anon_vma should > be there, no issue should happen. Only if with RO pin, we won't trigger > CoW, we won't have any anonymous page, we won't have anon_vma, hence the > panic. > > The thing is if the page is RO pinned, skip copying it (as what was done in > this patch) is not correct either, because e.g. a follow up write after > fork() from the parent will trigger CoW and the dma RO page that was pinned > will be inconsistent to the page in pgtable anymore, I think. > > IIUC the correct fix is what David worked on with unshare - when RO pin the > page cache we should have triggered CoR already before fork(). But as you > mentioned, that's too much change for stable. > > So besides this workaround which seems feasible to at least not panic the > system (Hugh: I can't quickly tell what'll be the difference here to check > dst anon_vma or PageAnon, they all seem to work? I could have missed Thanks for all the helpful elucidation above. My thought here, in favour of checking dst anon_vma rather than PageAnon, was that a common case would be that the private file vma does already have an anon_vma attached (from earlier CoW on some other page), and in that case there is no justification for taking this short cut to avoid the BUG in __page_set_anon_rmap() on every !PageAnon in the vma. And I imagined that the correct fix (short of going forward with David's full changes) would be to back out to a context where one could add an anon_vma_prepare(), then retry after that - involves dropping pt lock, maybe gets nasty (tedious, anyway). > something for sure..), the other workaround is teach the user app to switch > to use RW pin for any DMA pages even if RO, so that it'll always guarantee > page coherence even with the old kernel, and afaict that's what RDMA relied > on for years. I don't know an easy way to make old kernel work with RO pin > solidly if without the unsharing logic. > > Thanks, > > -- > Peter Xu