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,URIBL_BLOCKED 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 3A7D2C433DB for ; Mon, 21 Dec 2020 19:28:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C08B022B4B for ; Mon, 21 Dec 2020 19:28:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C08B022B4B 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 363AC6B0068; Mon, 21 Dec 2020 14:28:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 313B56B006C; Mon, 21 Dec 2020 14:28:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22A236B006E; Mon, 21 Dec 2020 14:28:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0139.hostedemail.com [216.40.44.139]) by kanga.kvack.org (Postfix) with ESMTP id 0B7116B0068 for ; Mon, 21 Dec 2020 14:28:52 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id D0BED8249980 for ; Mon, 21 Dec 2020 19:28:51 +0000 (UTC) X-FDA: 77618276862.22.bun06_14092c327459 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id AD90618038E73 for ; Mon, 21 Dec 2020 19:28:51 +0000 (UTC) X-HE-Tag: bun06_14092c327459 X-Filterd-Recvd-Size: 5935 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Dec 2020 19:28:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608578930; 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=DqGCALe//LHb1AnlutRHnAB2IrphEkKHBcp1ImnyyF4=; b=RZhTfhttZXpdwaNsdA9atkAMCjhU5SzuLPmldB6xB1BmeljtQa2xoEYsFHU1pU4wRA9DHn 0mY4mosMvQ581SJTzPmigVJIpdlAEdDrXxlnOhlNTjnxAaxFxe+0adxHskwiFFfGKpbwsZ LP6d5UizlT//pRD5atllMYKbCQdhsSc= 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-73-GU9YdJumN3ys9ohbdpZjrQ-1; Mon, 21 Dec 2020 14:28:48 -0500 X-MC-Unique: GU9YdJumN3ys9ohbdpZjrQ-1 Received: by mail-qk1-f200.google.com with SMTP id n190so9485438qkf.18 for ; Mon, 21 Dec 2020 11:28:48 -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=DqGCALe//LHb1AnlutRHnAB2IrphEkKHBcp1ImnyyF4=; b=h7uoiOMPbmC4qTKA4bngHd0jyO+vpnJfmUOXYKhLCcJNLuHjR0VgAw3JnZWIcej5XZ MQ7PVo7+7oMCC2BpeSZJxx4i6NyGDzix+ZB1zQy03lAR2aDXXamiEV8ccUWDcgl4q3Cg ezQN5E1WV0VNCyQbt67g25x1/2bjMS6jDSqXb1eEf6gs1/2jBkDgKMzjoJpoqph5118+ 09c93d/yeTgjAtDK8JZGXaZk9z2SnjU/5da09XUkTkFHDGgVa3Z37YD8rvpa+mgW4H1v nV/GnhM+ey1sIBp9vl8QRxrxP4Oy94g0JAhUUblI8GcIpdh3T6LN2x5LPnHmphk1Qo6b urDQ== X-Gm-Message-State: AOAM532FPOse9atBUp5fElpDuh0MB6JI/EXvYYvImgtURCg4MTmDuzRR 3sUyc7huWDclVYW+gPQWuG0NGZFUuCThT2OSksyorWMBq7J3hZDYYsFfd6gKwgJYkKRb3Ii6vSA GAzzoA8TbY9c= X-Received: by 2002:aed:29c2:: with SMTP id o60mr17763190qtd.253.1608578928365; Mon, 21 Dec 2020 11:28:48 -0800 (PST) X-Google-Smtp-Source: ABdhPJwsn1SLArBtFHb9e3jSB2ALMQZgUo1VQqvjtU1VmAZ7dXXrd9aB6Q7I+oD5sckuDOibu7ebRw== X-Received: by 2002:aed:29c2:: with SMTP id o60mr17763169qtd.253.1608578928083; Mon, 21 Dec 2020 11:28:48 -0800 (PST) Received: from xz-x1 ([142.126.83.202]) by smtp.gmail.com with ESMTPSA id e38sm4967128qtb.30.2020.12.21.11.28.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Dec 2020 11:28:47 -0800 (PST) Date: Mon, 21 Dec 2020 14:28:46 -0500 From: Peter Xu To: Nadav Amit Cc: linux-fsdevel@vger.kernel.org, Nadav Amit , Jens Axboe , Andrea Arcangeli , Alexander Viro , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH 03/13] selftests/vm/userfaultfd: wake after copy failure Message-ID: <20201221192846.GH6640@xz-x1> References: <20201129004548.1619714-1-namit@vmware.com> <20201129004548.1619714-4-namit@vmware.com> MIME-Version: 1.0 In-Reply-To: <20201129004548.1619714-4-namit@vmware.com> 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 Sat, Nov 28, 2020 at 04:45:38PM -0800, Nadav Amit wrote: > From: Nadav Amit > > When userfaultfd copy-ioctl fails since the PTE already exists, an > -EEXIST error is returned and the faulting thread is not woken. The > current userfaultfd test does not wake the faulting thread in such case. > The assumption is presumably that another thread set the PTE through > copy/wp ioctl and would wake the faulting thread or that alternatively > the fault handler would realize there is no need to "must_wait" and > continue. This is not necessarily true. > > There is an assumption that the "must_wait" tests in handle_userfault() > are sufficient to provide definitive answer whether the offending PTE is > populated or not. However, userfaultfd_must_wait() test is lockless. > Consequently, concurrent calls to ptep_modify_prot_start(), for > instance, can clear the PTE and can cause userfaultfd_must_wait() > to wrongly assume it is not populated and a wait is needed. Yes userfaultfd_must_wait() is lockless, however my understanding is that we'll enqueue before reading the page table, which seems to me that we'll always get notified even the race happens. Should apply to either UFFDIO_WRITEPROTECT or UFFDIO_COPY, iiuc, as long as we follow the order of (1) modify pgtable (2) wake sleeping threads. Then it also means that when must_wait() returned true, it should always get waked up when fault resolved. Taking UFFDIO_COPY as example, even if UFFDIO_COPY happen right before must_wait() calls: worker thread uffd thread ------------- ----------- handle_userfault spin_lock(fault_pending_wqh) enqueue() set_current_state(INTERRUPTIBLE) spin_unlock(fault_pending_wqh) must_wait() lockless walk page table UFFDIO_COPY fill in the hole wake up threads (this will wake up worker thread too?) schedule() (which may return immediately?) While here fault_pending_wqh is lock protected. I just feel like there's some other reason to cause the thread to stall. Or did I miss something? Thanks, -- Peter Xu