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 645FDC433E0 for ; Mon, 21 Dec 2020 17:27:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DEC0F22B45 for ; Mon, 21 Dec 2020 17:27:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DEC0F22B45 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 2FA4D6B0036; Mon, 21 Dec 2020 12:27:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AA4F6B005D; Mon, 21 Dec 2020 12:27:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1992C6B0068; Mon, 21 Dec 2020 12:27:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id 0367B6B0036 for ; Mon, 21 Dec 2020 12:27:17 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B8A8A181AEF21 for ; Mon, 21 Dec 2020 17:27:17 +0000 (UTC) X-FDA: 77617970514.26.mass03_100c6f727459 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 81409180498A2 for ; Mon, 21 Dec 2020 17:27:17 +0000 (UTC) X-HE-Tag: mass03_100c6f727459 X-Filterd-Recvd-Size: 6067 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Dec 2020 17:27:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608571636; 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=/3qhlYqC6VGQL9wnW9i+UqvdaTUht8Sy4ZaQE3Fzns4=; b=JfZRYxG2mZSrK0ZtCzxgjwdTGC2raZ0U1RvNPC+qeyz2uCaoIGpENkupOb1WpmbBqoWH24 GI/WT99KD9lvf2apDfXcMCJT3zhtptfabXQa+p4fDrT3X4A0htp64GZ/tvDawMQx65hOb/ 2JSDXc6jz/52KnujvkOSgJHo3aBTGTI= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-387-o5U9Uh2ENpyykMw39fID3Q-1; Mon, 21 Dec 2020 12:27:14 -0500 X-MC-Unique: o5U9Uh2ENpyykMw39fID3Q-1 Received: by mail-qt1-f200.google.com with SMTP id o12so8234695qtw.14 for ; Mon, 21 Dec 2020 09:27:14 -0800 (PST) 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=/3qhlYqC6VGQL9wnW9i+UqvdaTUht8Sy4ZaQE3Fzns4=; b=JxFLyJ6AjFO6NpUXc+rzPEHGsgmqcmt9gEh7ShMojlc8bZpsnZMAqkKSXcjtssTIlD 2E/AOwUODrr+geDQm6Jro8OWZDsrt/DBSuI593xzAbzIsvY4tSk6wyE5h/XmxYHn90pH j+zl9n2YnygQIDzze4iyje8Pj4JTssRLWn+cg3CBz6qDXiPHF4B7ZhPSJI7eXp83j/fL Ce4gu3jytMooNSyOiQzDDe1/H+EzC9+bNq11B3oSXYJthldG+7XDclKrPBYAGZn6sjwV nBQtrDxoBiPZ360bv+85kGtQxq7IhNgmKMzSnxNRlCga1qoJlkanACGHL3/EA7as8BMo ZM2w== X-Gm-Message-State: AOAM533tykE+5ZxZYoWD8Xgu0YknPUjNX/UXNVA9snfGEGAq7ZuR5K1Y RWGJ5PMcrz1MjOuOEIOeRHpoEDK3w7hBPUvMu5FVJoUYboDjTfF67/QVo053axTiWYc2J0JQRVy nNGpOdRE6md0= X-Received: by 2002:a37:5d07:: with SMTP id r7mr17796060qkb.49.1608571633934; Mon, 21 Dec 2020 09:27:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJxRezkkdZJQqhTaV/VXrXr9yGTbdPr9iCSWsPfRzg1xntyEjAwIP+7+QmyC+aeWppFhXqNnDA== X-Received: by 2002:a37:5d07:: with SMTP id r7mr17796036qkb.49.1608571633671; Mon, 21 Dec 2020 09:27:13 -0800 (PST) Received: from xz-x1 ([142.126.83.202]) by smtp.gmail.com with ESMTPSA id c20sm10922199qtj.29.2020.12.21.09.27.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Dec 2020 09:27:12 -0800 (PST) Date: Mon, 21 Dec 2020 12:27:11 -0500 From: Peter Xu To: Nadav Amit Cc: Yu Zhao , Andrea Arcangeli , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable@vger.kernel.org, minchan@kernel.org, Andy Lutomirski , Will Deacon , Peter Zijlstra Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect Message-ID: <20201221172711.GE6640@xz-x1> References: <20201219043006.2206347-1-namit@vmware.com> MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=peterx@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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: Hi, Nadav, On Sun, Dec 20, 2020 at 12:06:38AM -0800, Nadav Amit wrote: [...] > So to correct myself, I think that what I really encountered was actual= ly > during MM_CP_UFFD_WP_RESOLVE (i.e., when the protection is removed). Th= e > problem was that in this case the =E2=80=9Cwrite=E2=80=9D-bit was remov= ed during unprotect. > Sorry for the strange formatting to fit within 80 columns: I assume I can ignore the race mentioned in the commit message but only r= efer to this one below. However I'm still confused. Please see below. >=20 >=20 > [ Start: PTE is writable ] >=20 > cpu0 cpu1 cpu2 > ---- ---- ---- > [ Writable PTE=20 > cached in TLB ] Here cpu2 got writable pte in tlb. But why? If below is an unprotect, it means it must have been protected once by userfaultfd, right? If so, the previous change_protection_range() which = did the wr-protect should have done a tlb flush already before it returns (si= nce pages>0 - we protected one pte at least). Then I can't see why cpu2 tlb = has stall data. If I assume cpu2 doesn't have that cached tlb, then "write to old page" w= on't happen either, because cpu1/cpu2 will all go through the cow path and pgt= able lock should serialize them. > userfaultfd_writeprotect() =09 > [ write-*unprotect* ] > mwriteprotect_range() > mmap_read_lock() > change_protection() >=20 > change_protection_range() > ... > change_pte_range() > [ *clear* =E2=80=9Cwrite=E2=80=9D-bit ] > [ defer TLB flushes] > [ page-fault ] > =E2=80=A6 > wp_page_copy() > cow_user_page() > [ copy page ] > [ write to old > page ] > =E2=80=A6 > set_pte_at_notify() >=20 > [ End: cpu2 write not copied form old to new page. ] Could you share how to reproduce the problem? I would be glad to give it= a shot as well. > [1] https://lore.kernel.org/patchwork/patch/1346386 PS: Sorry to not have read the other series of yours. It seems to need s= ome chunk of time so I postponed it a bit due to other things; but I'll read = at least the fixes very soon. Thanks, --=20 Peter Xu