Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2504523pxu; Sat, 28 Nov 2020 16:53:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJwi6rYDezPZtjf7TvOIluZG1E/o3N9DQKzGcbf4nJ6DV4XIrYDVCHJkh/ZFwJcttK/ruTd+ X-Received: by 2002:aa7:c74e:: with SMTP id c14mr14969727eds.202.1606611200568; Sat, 28 Nov 2020 16:53:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606611200; cv=none; d=google.com; s=arc-20160816; b=hUjWQ8rCTA/uUHlWHOmgQQDnKlQCeGdX4ZScQyAbLUgGz1gI6cthO3PlDrL+HVPK+W bYfN+Kuo2pkEDgv3UMBPsCq6zrv4hewvDxoQQ8849IuDDTyo2OUnyWT9mbZU2EMMD/0a 2uMrqRsYYneLKYfSLr4K+cEQR4IB8RS6P+SqKMsjNiB2hYPag/0OqgntUEo59w2ovyho uozSDIv4+t59S4asuB0HseQ9KSu/pyArg95ipHHppWkqfzMgVCeWC4M37eLW2dWATqpy kj09H/A85qWIqoT7D/BvafP5pj9YZbzW1UvJCt8HGzFE7KRa4UAmLlZ6K87wWG0sp6Lu Z3GA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=D/z5ByovhoEdVL8szr+fSEwF5ZNkk28Asd+MEkdD3Ag=; b=tnztZA7I5JV958YD6xM+5SQUx5t1Si+kgVG+oCLhrvK/qQqHyOvBa0GQodv9qYxFRS HHphF3r9fKbdgt32bZC8ijrfBCVChQi1rUpufjC0P4LR1T2dU4RnANM8B5HuMh9oPuAq mZVlEcYGiYdq/7SpbFsIntnW5qzUCqQcrhoJnXa+38RabR/iB8842CdFDh0LIPgYZEKW sqFpVBT92MIXo5/TBfKKspm4cvl/RwZODn2FIlfKTnxQ6sVn/1CMhKYRCqdAGaCmjVgW h/yMe8p/6y3vMzTxh00j83ywXlwPD4+2sNMi15o6U/UbwoNnjNqGfchJi7g6xXIGXVQg Sd3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=GziQO65x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i5si8182178edg.592.2020.11.28.16.52.58; Sat, 28 Nov 2020 16:53:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=GziQO65x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729619AbgK2Au1 (ORCPT + 99 others); Sat, 28 Nov 2020 19:50:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40680 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729393AbgK2AuY (ORCPT ); Sat, 28 Nov 2020 19:50:24 -0500 Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C286CC0613D4; Sat, 28 Nov 2020 16:49:59 -0800 (PST) Received: by mail-pg1-x544.google.com with SMTP id 34so7361490pgp.10; Sat, 28 Nov 2020 16:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=D/z5ByovhoEdVL8szr+fSEwF5ZNkk28Asd+MEkdD3Ag=; b=GziQO65x+u6+WDoZ+XN9JcohGtqXWOJB/8548oruYWdOlTqqFPBl9BOvrXP6yjikxi WBeU7LZiVpLv/RPCN6vQAx7JQEBFD7Znjv0EIbOdHYXbdRlYANazPi4waUhUVlvIh88m Q8HguvIVtgJGhFjl5CRq5b6n0ktK0tMI59BRDIfaxO8hpYFVjvJk7wD/9gR2LLvfb/Ee cvt/Uy8Wcy0eFMX34cPqt5c3oPNHvDO17d+eZVvJD1aRe6YbN7bDZEbYmNjSQUKqGRJi +d99YpQ7fcQFDZVBCy1y+/hzuY9kQCkbk6RG2sLp2JbLY8njbQFAKac7o5BMBlKwbuQm Nnqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=D/z5ByovhoEdVL8szr+fSEwF5ZNkk28Asd+MEkdD3Ag=; b=QB4PSAIJP5ntvbedyGRXnTuhDL47wMl6Ai6TlsGdm5vEDGKykxctDPpWy9Ur5XAV8b 2Mcy++P5qiWeoDzpNQXLCGlqx2XCaOMbG0NlzPC8ASv6XCTbanIQ7Z6SDiFlV1c2bmSU SJi7YJpadFlmfqjqKGRyfI8mfdGZr6fKdptGEM5/yTFKXo5LyIdJwUcglZPQ8gSvfCVo jM8bnwm3XRKUdZgUMl50Qj1Qb7SSwT/a3p5Lh4/HSwxCLd24gZZbc6I/rPQyZgHz5I3k bwLjAfhAq4kmHJraJdX8liAZ3L3aXxFH8+7JJDGdHT4bAQgQO+FAHhCTW0bJ+XaHLJF1 ULlg== X-Gm-Message-State: AOAM533uEabqtyz0WsFUk2SzuonJySWR8pF72sNaM3/eX7/gQiD59BAh NjTNw2AV+6OVRRSxvM7WQgChmMnAr/cibw== X-Received: by 2002:a63:ca4d:: with SMTP id o13mr12226852pgi.116.1606610998789; Sat, 28 Nov 2020 16:49:58 -0800 (PST) Received: from sc2-haas01-esx0118.eng.vmware.com ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id gg19sm16444871pjb.21.2020.11.28.16.49.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Nov 2020 16:49:58 -0800 (PST) From: Nadav Amit X-Google-Original-From: Nadav Amit To: linux-fsdevel@vger.kernel.org Cc: Nadav Amit , Jens Axboe , Andrea Arcangeli , Peter Xu , Alexander Viro , io-uring@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH 03/13] selftests/vm/userfaultfd: wake after copy failure Date: Sat, 28 Nov 2020 16:45:38 -0800 Message-Id: <20201129004548.1619714-4-namit@vmware.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20201129004548.1619714-1-namit@vmware.com> References: <20201129004548.1619714-1-namit@vmware.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. There are therefore 3 options: (1) Change the tests to wake on copy failure. (2) Wake faulting thread unconditionally on zero/copy ioctls before returning -EEXIST. (3) Change the userfaultfd_must_wait() to hold locks. This patch took the first approach, but the others are valid solutions with different tradeoffs. Cc: Jens Axboe Cc: Andrea Arcangeli Cc: Peter Xu Cc: Alexander Viro Cc: io-uring@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org Signed-off-by: Nadav Amit --- tools/testing/selftests/vm/userfaultfd.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/tools/testing/selftests/vm/userfaultfd.c b/tools/testing/selftests/vm/userfaultfd.c index 9b0912a01777..f7e6cf43db71 100644 --- a/tools/testing/selftests/vm/userfaultfd.c +++ b/tools/testing/selftests/vm/userfaultfd.c @@ -484,6 +484,18 @@ static void retry_copy_page(int ufd, struct uffdio_copy *uffdio_copy, } } +static void wake_range(int ufd, unsigned long addr, unsigned long len) +{ + struct uffdio_range uffdio_wake; + + uffdio_wake.start = addr; + uffdio_wake.len = len; + + if (ioctl(ufd, UFFDIO_WAKE, &uffdio_wake)) + fprintf(stderr, "error waking %lu\n", + addr), exit(1); +} + static int __copy_page(int ufd, unsigned long offset, bool retry) { struct uffdio_copy uffdio_copy; @@ -507,6 +519,7 @@ static int __copy_page(int ufd, unsigned long offset, bool retry) uffdio_copy.copy); exit(1); } + wake_range(ufd, uffdio_copy.dst, page_size); } else if (uffdio_copy.copy != page_size) { fprintf(stderr, "UFFDIO_COPY unexpected copy %Ld\n", uffdio_copy.copy); exit(1); -- 2.25.1