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 D7704C433DB for ; Wed, 23 Dec 2020 15:52:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5334522210 for ; Wed, 23 Dec 2020 15:52:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5334522210 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 684038D0030; Wed, 23 Dec 2020 10:52:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6339B8D0026; Wed, 23 Dec 2020 10:52:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 522218D0030; Wed, 23 Dec 2020 10:52:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) by kanga.kvack.org (Postfix) with ESMTP id 393708D0026 for ; Wed, 23 Dec 2020 10:52:42 -0500 (EST) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id ED3B6181AEF30 for ; Wed, 23 Dec 2020 15:52:41 +0000 (UTC) X-FDA: 77624989722.02.slave89_4c002fc27469 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin02.hostedemail.com (Postfix) with ESMTP id D178B10097AA7 for ; Wed, 23 Dec 2020 15:52:41 +0000 (UTC) X-HE-Tag: slave89_4c002fc27469 X-Filterd-Recvd-Size: 5430 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Dec 2020 15:52:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608738760; 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=CctFZb6bundK1QcZGvHF97KgBugzbNEBYOfUqLkXE1s=; b=guqhXXpHiaqvVxI9qKUGKWGjALkSt+NVJfwBh91yOxZXS8r/3zai3kFgYX8DhX/yACQG1W 0pRL4AWttA4rk8kTSiqbzoDlgRz4j2mLj9ChfNdiz8vW5O79ysyY7vEZ3PNcuBc86VbE/i cKI8d+p2RcR4jPrp4dnxBq96MOvDYQc= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-574-ZhgR2hrrMFG5nRsmR28y6A-1; Wed, 23 Dec 2020 10:52:38 -0500 X-MC-Unique: ZhgR2hrrMFG5nRsmR28y6A-1 Received: by mail-qv1-f71.google.com with SMTP id x19so12765981qvv.16 for ; Wed, 23 Dec 2020 07:52:38 -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=CctFZb6bundK1QcZGvHF97KgBugzbNEBYOfUqLkXE1s=; b=O4MJMO5BB6aJ5pDLmRn0PFTH1f/xyKjiCe3zDevXp8Q1GzOoD95wI4Cnnmb8Erkp/p +J0/qW6jWOz0h+sOYyOfw48rwbXRxYdc3NEm9S86QQKVwCL8Npa12aJHC96bVXEbt35u Inl1rWm947LA0E0wwyDnXetYGmLxzf4bWz+P7LBGkkYfPBGslSjyJACh9mp5unmminmd 6UJZuKOfxAvoZgdFfOMWa6mG+Z0DgCS/brPbkQqEyOWYQX+hWC714Hvud85M61tm9hP6 fUkqYQu4cdoey3fT2JSVfaWl7nOKkpwkMv3FXyWhcvqDexCLvX1/5b40QAUqIiVfDDdB 5N1g== X-Gm-Message-State: AOAM531IBoDFe3wh/YZumR9vlNiRV2cG2DzXWiBkE/tLhxQcoUwG+uaU 8TrTXPvLKmEJ7mumCMAIiugtkBxNwS5MVQD84yTEGCpul6geyHeW+ildBbtNSF6kK1S8gv0ucpL DOc2dZ+srq3o= X-Received: by 2002:ac8:46c8:: with SMTP id h8mr26253725qto.17.1608738758049; Wed, 23 Dec 2020 07:52:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJzJU7/Y9icFKNa6TDN6+mbeV2MBtZBm3V2OIaPguxARYP0RegIgd55bLE2LXRcKkm70WUUQEw== X-Received: by 2002:ac8:46c8:: with SMTP id h8mr26253703qto.17.1608738757806; Wed, 23 Dec 2020 07:52:37 -0800 (PST) Received: from xz-x1 ([142.126.83.202]) by smtp.gmail.com with ESMTPSA id c14sm14501321qtg.85.2020.12.23.07.52.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Dec 2020 07:52:36 -0800 (PST) Date: Wed, 23 Dec 2020 10:52:35 -0500 From: Peter Xu To: Yu Zhao Cc: Andrea Arcangeli , Andy Lutomirski , Linus Torvalds , Nadav Amit , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable , Minchan Kim , Will Deacon , Peter Zijlstra Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect Message-ID: <20201223155235.GC6404@xz-x1> References: <1FCC8F93-FF29-44D3-A73A-DF943D056680@gmail.com> <20201221223041.GL6640@xz-x1> 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 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 Tue, Dec 22, 2020 at 08:36:04PM -0700, Yu Zhao wrote: > In your patch, do we need to take wrprotect_rwsem in > handle_userfault() as well? Otherwise, it seems userspace would have > to synchronize between its wrprotect ioctl and fault handler? i.e., > the fault hander needs to be aware that the content of write- > protected pages can actually change before the iotcl returns. The handle_userfault() thread should be sleeping until another uffd_wp_resolve fixes the page fault for it. However when the uffd_wp_resolve ioctl comes, then rwsem (either the group rwsem lock as Andrea proposed, or the mmap_sem, or any new rwsem lock we'd like to introduce, maybe per-uffd rather than per-mm) should have guaranteed the previous wr-protect ioctls are finished and tlb must have been flushed until this thread continues. And I don't know why it matters even if the data changed - IMHO what uffd-wp wants to do is simply to make sure after wr-protect ioctl returns to userspace, no change on the page should ever happen anymore. So "whether data changed" seems matter more on the ioctl thread rather than the handle_userfault() thread. IOW, I think data changes before tlb flush but after pte wr-protect is always fine - but that's not fine anymore if the syscall returns. Thanks, -- Peter Xu