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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E579FC433EF for ; Thu, 10 Feb 2022 07:48:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C8636B0075; Thu, 10 Feb 2022 02:48:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 278726B007B; Thu, 10 Feb 2022 02:48:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 166CB6B007D; Thu, 10 Feb 2022 02:48:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0137.hostedemail.com [216.40.44.137]) by kanga.kvack.org (Postfix) with ESMTP id 075696B0075 for ; Thu, 10 Feb 2022 02:48:42 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id BA207824C44D for ; Thu, 10 Feb 2022 07:48:41 +0000 (UTC) X-FDA: 79126093242.09.F57A0AD Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf18.hostedemail.com (Postfix) with ESMTP id 24D6E1C0006 for ; Thu, 10 Feb 2022 07:48:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644479320; 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=T7Yv/upGKeuJnrrvPFPMM0Euz/xVfQsz/woiQvJNATs=; b=IyuXfFuvpo4RDQbcLdInm3Si/lAiuy0S6u1OQwd/o/bV2zwzZ++nKBoqJO83SqtHP3FoIi hJeVlJNB0c4zxflXDVXOIAy6mhVvEOqLr6i1/kgXDpvbeIIQdHFSX0BWUUDqt3y58BGDKj zcq5aHQvT9snSfvWc+LODgE7gLWPjEU= Received: from mail-pf1-f197.google.com (mail-pf1-f197.google.com [209.85.210.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-605-c2YoG2UrMQilvRiaxRAB9A-1; Thu, 10 Feb 2022 02:48:38 -0500 X-MC-Unique: c2YoG2UrMQilvRiaxRAB9A-1 Received: by mail-pf1-f197.google.com with SMTP id k80-20020a628453000000b004e042d3910eso3801333pfd.5 for ; Wed, 09 Feb 2022 23:48:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=T7Yv/upGKeuJnrrvPFPMM0Euz/xVfQsz/woiQvJNATs=; b=Z5q5u5Fv80BF1eNJ3iq+KUwHGKYmi6MFN12Kh7MaA/LE8Yv+MWmSmSYy0J2Fy6xssS fdwy4EbJX+mQZGPf9PrH3PV0rT5D/S5NuJq0+wMP1tsXaGXysSzy+iB9+Qes+tt+iuEC HrfuOhyOOCvnFFb+9FiogvmG6/Q8/JT0a4MMIp36ry2tzp7fNg3mbjXQV8jQHcrSrC3f 4oBgAmsm3po04jDr7fGKoLGHOKCWqQ5hWGc8YccNK3zeiYHe0oUPNTqlf6hFk+crOgc6 cX0as+XlYxCBCL5gbMaDzmJKsqb4MjVz2LsAaT3ZbercrwzFygH7FpRVjsJYMV0/hWHU Lhow== X-Gm-Message-State: AOAM531mFbg4/yCBfK09Kd6i24nqmIpYV4LRMEVaXgkp43OOFyr2ntWl Nfa6co9eDIPsTAcd2O3c3YRsCyumZWmIDjzWfSxnqr5gy0s2MXEqmMrr0YcEFxATbZC66/6MZCO HBU9Ooh39lE4= X-Received: by 2002:a63:c007:: with SMTP id h7mr5280570pgg.422.1644479317541; Wed, 09 Feb 2022 23:48:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJy6SUTLriEpQ21KCknFCBq/7rO5yGLiVn2eJRMKJagDPT/biRyYpCmBul0xqH8SSiWQgc83Qw== X-Received: by 2002:a63:c007:: with SMTP id h7mr5280552pgg.422.1644479317307; Wed, 09 Feb 2022 23:48:37 -0800 (PST) Received: from xz-m1.local ([94.177.118.72]) by smtp.gmail.com with ESMTPSA id j7sm20558773pfa.36.2022.02.09.23.48.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 23:48:36 -0800 (PST) Date: Thu, 10 Feb 2022 15:48:30 +0800 From: Peter Xu To: Nadav Amit Cc: Mike Rapoport , David Hildenbrand , Mike Rapoport , Andrea Arcangeli , Linux-MM Subject: Re: userfaultfd: usability issue due to lack of UFFD events ordering Message-ID: References: <11831b20-0b46-92df-885a-1220430f9257@redhat.com> <63a8a665-4431-a13c-c320-1b46e5f62005@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Stat-Signature: i1t5nyh19coo1nemfiark74w9krd5shx X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=IyuXfFuv; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf18.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=peterx@redhat.com X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 24D6E1C0006 X-HE-Tag: 1644479320-787836 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: Hi, Nadav & all, On Mon, Jan 31, 2022 at 02:39:01PM -0800, Nadav Amit wrote: > There are use-cases in which you do need to know the order between > user-initiated MADV_DONTNEED and page-faults. For instance, if you > build a userspace paging mechanism, you need to know whether the > page content is zero or whatever is held in the disk. When there's no uffd monitor, concurrent page faults with MADV_DONTNEED can already result in undefined behavior, right? Assuming the page fault is a write with non-zero data, then the page can either contain zero or non-zero data at last, IIUC. If above is true, I'm wondering whether it's already impossible to do it right when there is an uffd monitor? Thanks, -- Peter Xu