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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 98E1EC433E0 for ; Mon, 21 Dec 2020 18:22:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 409F6230FC for ; Mon, 21 Dec 2020 18:22:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 409F6230FC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8488F6B005C; Mon, 21 Dec 2020 13:22:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D1E76B005D; Mon, 21 Dec 2020 13:22:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6E8B86B0068; Mon, 21 Dec 2020 13:22:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5426B6B005C for ; Mon, 21 Dec 2020 13:22:53 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 16169181AF5C2 for ; Mon, 21 Dec 2020 18:22:53 +0000 (UTC) X-FDA: 77618110626.28.suit67_461100927459 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin28.hostedemail.com (Postfix) with ESMTP id E413E6C21 for ; Mon, 21 Dec 2020 18:22:52 +0000 (UTC) X-HE-Tag: suit67_461100927459 X-Filterd-Recvd-Size: 3307 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Dec 2020 18:22:52 +0000 (UTC) X-Gm-Message-State: AOAM530Xxfwni6i3YPhL1xQT7NXpWWXoBXzGOmuF2drFE3t+oUM0/2yn FljJqvEB9LUiFYz/utRDXPPU0HTz3kF54bfEQ1GUqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608574971; bh=09s/7/3Abqx6UuMNj0u19lQ8gCTkTlZe5NqmmaxK9+4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Bo2Fa9gWLOSAKLQOzb6Oj9YP9nN27xyxcbVrrkxKTgaUUis9adXsAlE2/PQ08Uour 5ZXP8SsubuI5xmfpmWXU21mr+asURMlTMcL11Tuiyw8dcRfdrofSVP77gCtiTk6SfP IPdvY2lQIoggfdku1N5Os27Lp/UWEHNZa6Jn72Iwo4rpHUAF3Vn2q6w6ubIbhZ+EwB +8Cc9hqwT2ogGzrD48wKxfs6128Ln/14xdpWV17jgR7fpdIzaU/2iDlSypRZqflsX/ 36Sp7GH5M9zSlW8VmJyOrL1xQO+qqc3WLwdmRlieo+GiTaaU/ogXQ9qHelRL4WEjrA DFuE9CfYmVvqg== X-Google-Smtp-Source: ABdhPJwjTRqYw8V9Gi4qEwVzEP3KAOAipT6YS4V/aZhUnVFW91AADzWb0GD1KyN5B6hdVMCwN/jvFo6XDpkmv5gcYbs= X-Received: by 2002:a1c:630b:: with SMTP id x11mr17742545wmb.138.1608574969815; Mon, 21 Dec 2020 10:22:49 -0800 (PST) MIME-Version: 1.0 References: <20201219043006.2206347-1-namit@vmware.com> In-Reply-To: From: Andy Lutomirski Date: Mon, 21 Dec 2020 10:22:38 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect To: Andrea Arcangeli Cc: Andy Lutomirski , Nadav Amit , Dave Hansen , linux-mm , Peter Xu , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable , Minchan Kim , Yu Zhao , Will Deacon , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" 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, Dec 21, 2020 at 10:04 AM Andrea Arcangeli wrote: > > Hello, > > On Sat, Dec 19, 2020 at 09:08:55PM -0800, Andy Lutomirski wrote: > > On Sat, Dec 19, 2020 at 6:49 PM Andrea Arcangeli wrote: > > > The ptes are changed always with the PT lock, in fact there's no > > > problem with the PTE updates. The only difference with mprotect > > > runtime is that the mmap_lock is taken for reading. And the effect > > > contested for this change doesn't affect the PTE, but supposedly the > > > tlb flushing deferral. > > > > Can you point me at where the lock ends up being taken in this path? > > pte_offset_map_lock in change_pte_range, as in mprotect, no difference. > > As I suspected on my follow up, the bug described wasn't there, but > I'll look at the new theory posted. Indeed.