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=-5.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 28B73C433E0 for ; Mon, 21 Dec 2020 22:32:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EF184225AA for ; Mon, 21 Dec 2020 22:32:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726140AbgLUWcO (ORCPT ); Mon, 21 Dec 2020 17:32:14 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:49243 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726146AbgLUWcN (ORCPT ); Mon, 21 Dec 2020 17:32:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608589846; 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: in-reply-to:in-reply-to:references:references; bh=/0nOtRjyRXqUdfVgnLEJZJLZpSyfauPx9TpoxNOMLQc=; b=BcN7z3wbg0KXkZy++I+KLqknDQm3BxmfKknuq2jou0uD5WxuUGN9BmhnV+hiyxwqyGFQFm ++oFzoJEukxIyoMw9Y0o/DlJIwF+ugPg8K3UXnTnyKEO6ZvM2mNtX2IIKF8TUY3OVcyNRI LYyUnUqedIWKlARbBCWKQdghitunS+c= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-536-pR_nSEOzPQGy3KoZmj99Og-1; Mon, 21 Dec 2020 17:30:44 -0500 X-MC-Unique: pR_nSEOzPQGy3KoZmj99Og-1 Received: by mail-qt1-f199.google.com with SMTP id i1so8914778qtw.4 for ; Mon, 21 Dec 2020 14:30:44 -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:in-reply-to; bh=/0nOtRjyRXqUdfVgnLEJZJLZpSyfauPx9TpoxNOMLQc=; b=lHhnhu8s60+Qv78JZC/nYfJUZf/m5q6reetQBff5aHi+Ud4vux212opXUOfF+ZiUzw Pg3Y5wvQoZRXwlJN2GRIRSOW1uDok7QUEai45rzEWtb6YZjqM6I44duZtbIQI9TRD7wZ zyG3zAyUj4CCovQfVa7fDURretp9gFr7sWKd+5Wr6a3ICW8AtWXwQbWuGLkjRUL6yFBO fm/O8XCdvKmcWUiFcSbk6m0JtxLS9NXiIQ/ZT6itCQQEryCY68ZXq6WPIY5XmunKix6+ d7ht3KvogUQwQW3UZLZQ4EzzRvsPP4rpeLoSmjFXUnE9f1tU1H9HfCudMwmh8vcRT7tA vSxg== X-Gm-Message-State: AOAM533VH93IZpH+oOmAdOutYxlj9QXIQtoHj4E1qzkCmBpEUWON976z KEEluR2S1jLaB8wJu2Z2UXbsTwxwJsAmUJmF7AD8Yf71+tJqR8UtiZdk9erRoKOhHmOk+Z/sQUK +DWi/U298Qe4fEmsC X-Received: by 2002:a0c:f850:: with SMTP id g16mr19255293qvo.14.1608589844018; Mon, 21 Dec 2020 14:30:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJwsyvGQ+Zlz+F4Ln7DFyojEIAwfAH7eIeF2+0g/BLBE8jYg9DoCNA01RbxX54HEjqCZPSWhnQ== X-Received: by 2002:a0c:f850:: with SMTP id g16mr19255269qvo.14.1608589843776; Mon, 21 Dec 2020 14:30:43 -0800 (PST) Received: from xz-x1 ([142.126.83.202]) by smtp.gmail.com with ESMTPSA id a35sm12063468qtk.82.2020.12.21.14.30.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Dec 2020 14:30:42 -0800 (PST) Date: Mon, 21 Dec 2020 17:30:41 -0500 From: Peter Xu To: Nadav Amit Cc: Yu Zhao , Linus Torvalds , Andrea Arcangeli , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable , Minchan Kim , Andy Lutomirski , Will Deacon , Peter Zijlstra Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect Message-ID: <20201221223041.GL6640@xz-x1> References: <20201221172711.GE6640@xz-x1> <76B4F49B-ED61-47EA-9BE4-7F17A26B610D@gmail.com> <9E301C7C-882A-4E0F-8D6D-1170E792065A@gmail.com> <1FCC8F93-FF29-44D3-A73A-DF943D056680@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1FCC8F93-FF29-44D3-A73A-DF943D056680@gmail.com> Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Mon, Dec 21, 2020 at 01:49:55PM -0800, Nadav Amit wrote: > BTW: In general, I think that you are right, and that changing of PTEs > should not require taking mmap_lock for write. However, I am not sure > cow_user_page() is not the only one that poses a problem and whether a more > systematic solution is needed. If cow_user_pages() is the only problem, do > you think it is possible to do the copying while holding the PTL? It works > for normal-pages, but I am not sure whether special-pages pose special > problems. > > Anyhow, this is an enhancement that we can try later. AFAIU mprotect() is the only one who modifies the pte using the mmap write lock. NUMA balancing is also using read mmap lock when changing pte protections, while my understanding is mprotect() used write lock only because it manipulates the address space itself (aka. vma layout) rather than modifying the ptes, so it needs to. At the pte level, it seems always to be the pgtable lock that serializes things. So it's perfectly legal to me for e.g. a driver to modify ptes with the read lock of mmap_sem, unless I'm severely mistaken.. as long as the pgtable lock is taken when doing so. If there's a driver that manipulated the ptes, changed the content of the page, recover the ptes to origin, and all these happen right after wp_page_copy() unlocked the pgtable lock but before wp_page_copy() retakes the same lock again, we may face the same issue finding that the page got copied contains corrupted data at last. While I don't know what to blame on the driver either because it seems to be exactly following the rules. I believe changing into write lock would solve the race here because tlb flushing would be guaranteed along the way, but I'm just a bit worried it's not the best way to go.. Thanks, -- Peter Xu