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 X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B029C07E95 for ; Tue, 20 Jul 2021 00:34:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D9B7261009 for ; Tue, 20 Jul 2021 00:34:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D9B7261009 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 7E8DD8D0005; Mon, 19 Jul 2021 20:34:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 771CE8D0001; Mon, 19 Jul 2021 20:34:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59D368D0005; Mon, 19 Jul 2021 20:34:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0150.hostedemail.com [216.40.44.150]) by kanga.kvack.org (Postfix) with ESMTP id 309B68D0001 for ; Mon, 19 Jul 2021 20:34:44 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BDDCA18495FE9 for ; Tue, 20 Jul 2021 00:34:42 +0000 (UTC) X-FDA: 78381095604.23.6FC9DEE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf02.hostedemail.com (Postfix) with ESMTP id 5C3777001A05 for ; Tue, 20 Jul 2021 00:34:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626741281; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3Vj4ZjBO1w2b+GiZ3IkY4u+4/TOlkA+2xSSKiXPHhM8=; b=ITIdmVMp+1mX5Yl/c8HhLorfhIeX1+dR1jHM+7oXN1RqL0SPG2NEugbybIdsGS/p45vf0c +97134EIpMpBT4Q+SJrrpbV/5bcdkXLIfVZxJNZhjdK4PCjAiSSb9r4dqkW1CUl4x30mZT xg2hQZdGZLPC6YYL3SoVJK1y6KC8BBY= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-64-c4KrYNmIPKi8MVlZUgEJlw-1; Mon, 19 Jul 2021 20:34:40 -0400 X-MC-Unique: c4KrYNmIPKi8MVlZUgEJlw-1 Received: by mail-qk1-f200.google.com with SMTP id y16-20020a05620a0e10b02903b8f9d28c19so11181333qkm.23 for ; Mon, 19 Jul 2021 17:34:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=3Vj4ZjBO1w2b+GiZ3IkY4u+4/TOlkA+2xSSKiXPHhM8=; b=mYnCzuEZG/BwJNMJVztHOlPKspw/CkgmONf6ltg0wBV5yMwg9E/d1TlJhIomgwvdSx vf6uGGppgTxgouj7t/g37TeRw4hrlEzXdbLUxVOvotoRz3XhCLGxwDFbjVfGsPpOl5OJ db8+EJLJH1zdsO0ujXLeNG5FxWjhybjTloBtFDw8ThlgLtOovTfzQ4SWD2NeFdTB8pPW hTexPKfjU0CPcwdWqMu951tMU7dCxL5ToEyJp0N2cp0GnTKdgqRdfmxO6iMEnpj0WY3C 7qNvSMHCbEt3AB/wtmgxi5KcroySNZ/8LX7gqOfDuxzY7kugZTES6Ob0ZmIQ596/FZ0V gwHQ== X-Gm-Message-State: AOAM5307cIi6uDxMzbkRxMvdFNQxcRqEzuJ8ZEhbcJA86F00VaxOBVVN X37uFcVwhsst0v0Ppzr8PFQHGhRsUq3vkR63XgCy/2Xc09X7+mRmVqm0y6Y1S/j6W3HtmWWqQ5D VJkoUfcZWVmQ= X-Received: by 2002:a05:620a:6cd:: with SMTP id 13mr26756557qky.346.1626741280037; Mon, 19 Jul 2021 17:34:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdmcXsrcx0Tqk05tPtTIeIyoc2bcimurslvdUWFxdlVM9Co3n2KBoz878jQPuSfxj0sChQ6A== X-Received: by 2002:a05:620a:6cd:: with SMTP id 13mr26756541qky.346.1626741279719; Mon, 19 Jul 2021 17:34:39 -0700 (PDT) Received: from t490s (bras-base-toroon474qw-grc-65-184-144-111-238.dsl.bell.ca. [184.144.111.238]) by smtp.gmail.com with ESMTPSA id q206sm8954835qka.19.2021.07.19.17.34.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Jul 2021 17:34:38 -0700 (PDT) Date: Mon, 19 Jul 2021 20:34:37 -0400 From: Peter Xu To: Hugh Dickins Cc: Igor Raits , Andrew Morton , Hillf Danton , Axel Rasmussen , linux-mm@kvack.org Subject: Re: kernel BUG at include/linux/swapops.h:204! Message-ID: References: <4c9e24db-29d5-5bbb-17ae-8dc32ceb66ed@google.com> <796cbb7-5a1c-1ba0-dde5-479aba8224f2@google.com> <757b684a-67b5-999b-7f2d-b55fb1c61fd8@google.com> MIME-Version: 1.0 In-Reply-To: <757b684a-67b5-999b-7f2d-b55fb1c61fd8@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ITIdmVMp; spf=none (imf02.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam05 X-Stat-Signature: jygj45w45xyswh9b16cjqz9kgfwaqr79 X-Rspamd-Queue-Id: 5C3777001A05 X-HE-Tag: 1626741282-548596 Content-Transfer-Encoding: quoted-printable 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 Mon, Jul 19, 2021 at 03:42:41PM -0700, Hugh Dickins wrote: > On Mon, 19 Jul 2021, Peter Xu wrote: > > On Mon, Jul 19, 2021 at 12:11:21PM -0700, Hugh Dickins wrote: > > >=20 > > > But I'm confident that 8f34f1eac382 will prove to be the fix, so Pe= ter > > > please prepare some backports of that for the various stable/longte= rm > > > kernels that need it - I've not looked into whether it applies clea= nly, > > > or depends on other commits too. You fixed several related but dif= ferent > > > things in that commit: but this one is the worst, because it can co= rrupt > > > even those who are not using UFFD_WP at all. > >=20 > > Looks right to me, b569a1760782 ("userfaultfd: wp: drop _PAGE_UFFD_WP= properly > > when fork", 2020-04-07) seems to be the culprit. I didn't notice the= side > > effect in the bug or in the fix, or it should have already land stabl= es. I am > > very sorry for such a preliminary bug that caused this fallout - I re= ally can't > > tell why I completely didn't look at is_swap_pte() that's so obvious = indeed. > >=20 > > I checked it up, 5.6.y doesn't have the issue commit yet as it's not = marked as > > "fixes". It started to show up in 5.7.y~5.13.y. 5.14-rc1 has 8f34f1ea= c382 which > > is the fix. So I think we need the fix or equivalent fix for 5.7.y~5= .13.y. > >=20 > > 5.12.y & 5.13.y can pick up the fix 8f34f1eac382 cleanly. For the ol= ders > > (5.7.y~5.11.y) they can't. I plan to revert b569a1760782 instead. > >=20 > ... > >=20 > > Please let me know if there's any comment on the backport plan above,= or I'll > > prepare the patches for all the branches before tomorrow. >=20 > Thanks for getting on to it so quickly, Peter. >=20 > The only non-EOL stable/longterm releases are then 5.13, 5.12 and 5.10. I see, thanks. I haven't explicitly backported patches to stable; it's a= good chance to learn about the bits, though. >=20 > I have no appreciation of the importance of UFFD_EVENT_FORK support > for uffd-wp. And no appreciation of the importance of the other bugs > you fixed in 8f34f1eac382, and other uffd-wp fixes you may have made > recently, some backported, some not. >=20 > But I think it is worth giving 5.10, the longterm, a little more > consideration: don't be driven by whether 8f34f1eac382 applies cleanly > (all 5.13 and 5.12 would require then is a mail to GregKH Cc stable > asking him to add that commit), but by how important the support is > to users of 5.10, and how far away from working safely it is - maybe > a 5.10-specific patch would be worthwhile, maybe not, I cannot judge. I am not aware of anyone who's using fork with uffd-wp. CRIU is the majo= r user per my knowledge that uses uffd fork, but still it shouldn't be using uff= d-wp. I know other users that use uffd-wp, but never with fork event. Per my understanding, if above is true then it's probably not a good cand= idate for such patches that fixing uffd-wp + fork to be backported to stable, a= s in stable tree rules there's one entry: - It must fix a real bug that bothers people (not a, =E2=80=9CThis coul= d be a problem=E2=80=A6=E2=80=9D type thing). https://www.kernel.org/doc/html/v5.13/process/stable-kernel-rules.html That's also one reason I didn't add Fixes for some patches because I am n= ot sure whether that'll help anyone, and the worst case is if someone hit so= me issue we can backport explicitly. There're a few other things that made me a bit worried before backporting= the full patch, even for 5.12/5.13, as there're requirements on the patch: - It cannot be bigger than 100 lines, with context. - It must fix only one thing. The full patch (after squashed) contains ~200 LOC with context, and it do= es fix a few more things... Do you know whether that would be a problem? I'm not sure how strict would stable branches be, but if that's one block= er then we'll only be able to either pick up the real fix for copy_pmd_range= () or just revert the issue commit which is just a few more lines; that should = also keep the tree cleaner. From that sense, maybe it's easier to just revert= for all the branches (5.10/5.12/5.13). Then if someone broke with uffd-wp+fo= rk, I can backport the full patch with better reasoning. Thoughts? Thanks, --=20 Peter Xu