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 AD8F1C433EF for ; Mon, 31 Jan 2022 10:48:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 439276B0071; Mon, 31 Jan 2022 05:48:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E6CA6B0073; Mon, 31 Jan 2022 05:48:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D5E76B0074; Mon, 31 Jan 2022 05:48:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0202.hostedemail.com [216.40.44.202]) by kanga.kvack.org (Postfix) with ESMTP id 1AA146B0071 for ; Mon, 31 Jan 2022 05:48:33 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C7E0B987A1 for ; Mon, 31 Jan 2022 10:48:32 +0000 (UTC) X-FDA: 79090258464.25.0696088 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf14.hostedemail.com (Postfix) with ESMTP id 5ECC7100007 for ; Mon, 31 Jan 2022 10:48:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643626111; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qS6XHeB6l0OyzAHe06aDhlYTLQgVWp2TLQmkqKpwAr8=; b=X+ZEb6oYzDScedzqKd3JYErInogKJsuMWdq7rbq6TQB5700NxpNucPb/8/dk/7jWnFHrmP 7nsdDs7NhHBbTcfZC8SXuG+UH+t4QuasE6IlP2So9VZ0OzuxeRvpI+RNQfsPPHzz798PZX bSoZp5x4FruzL6e9HF8t8yxGm52fwHc= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-241-H9YS6ykwNXeKchaTRZK1bg-1; Mon, 31 Jan 2022 05:48:30 -0500 X-MC-Unique: H9YS6ykwNXeKchaTRZK1bg-1 Received: by mail-wm1-f70.google.com with SMTP id bg16-20020a05600c3c9000b0034bea12c043so10166106wmb.7 for ; Mon, 31 Jan 2022 02:48:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=qS6XHeB6l0OyzAHe06aDhlYTLQgVWp2TLQmkqKpwAr8=; b=yTqJn8hWHKsVHFAcqf398eTlYAsxaPt9MMbaVP1Y8srzQRoIcaSnzPp4IBPoMRYR7A gypMpwBQA9xMt03jz4nx47IANd8bZxZtMzGb+4ruc0sPPbjrGIE17kX25kiVE9uaJE+x jYy9Xkk7TdqHjBg8xBLhj3dmXaxVeNDi7D+MB9KOOeiqdNqpvwIlcTdcF7efUiiuFnnd AGuE8qekhB4iZyRorttBRIwIEDEPhR7y0GKo3824pJmoCDTkwVFZSooMryFX1y/509Xs ZtymGHy2uoLTcYP2HCddVYO7zc55lGY21LLT1HRH4XwSx9DtaUrJ0GbN4SsfSYrzH0a6 5Agw== X-Gm-Message-State: AOAM532bEgnkF5rfQ7rGlMQ1I8NaErUnmb75Zug4nkEWGCXiWdhsQ0nM E2oshEqHuiEyA29lcsqYYlcUTyiT+JCJvF3cVatuzvKeFIDxuiQEA9VWTA+YEbwJb/Dz+mJwTJt iJdZSfVl4m1Q= X-Received: by 2002:a5d:47cf:: with SMTP id o15mr16818718wrc.577.1643626108953; Mon, 31 Jan 2022 02:48:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJzgWhIgcKESKX2k9pbeE7zrNYllB+n9xQrP/V+K8wIbR8bX9APS2iVOpTRgUlPfNr/qsrIkHg== X-Received: by 2002:a5d:47cf:: with SMTP id o15mr16818706wrc.577.1643626108778; Mon, 31 Jan 2022 02:48:28 -0800 (PST) Received: from ?IPV6:2003:cb:c709:b200:f007:5a26:32e7:8ef5? (p200300cbc709b200f0075a2632e78ef5.dip0.t-ipconnect.de. [2003:cb:c709:b200:f007:5a26:32e7:8ef5]) by smtp.gmail.com with ESMTPSA id u19sm8410740wmm.39.2022.01.31.02.48.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Jan 2022 02:48:28 -0800 (PST) Message-ID: <11831b20-0b46-92df-885a-1220430f9257@redhat.com> Date: Mon, 31 Jan 2022 11:48:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: userfaultfd: usability issue due to lack of UFFD events ordering To: Mike Rapoport , Nadav Amit Cc: Mike Rapoport , Andrea Arcangeli , Peter Xu , Linux-MM References: From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 5ECC7100007 X-Stat-Signature: sde8h1jtgjngg589778ouk4t9x7x9wwc X-Rspam-User: nil Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=X+ZEb6oY; spf=none (imf14.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1643626112-419817 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 31.01.22 11:42, Mike Rapoport wrote: > Hi Nadav, > > On Sat, Jan 29, 2022 at 10:23:55PM -0800, Nadav Amit wrote: >> Using userfautlfd and looking at the kernel code, I encountered a usability >> issue that complicates userspace UFFD-monitor implementation. I obviosuly >> might be wrong, so I would appreciate a (polite?) feedback. I do have a >> userspace workaround, but I thought it is worthy to share and to hear your >> opinion, as well as feedback from other UFFD users. >> >> The issue I encountered regards the ordering of UFFD events tbat might not >> reflect the actual order in which events took place. >> >> In more detail, UFFD events (e.g., unmap, fork) are not ordered against >> themselves [*]. The mm-lock is dropped before notifying the userspace >> UFFD-monitor, and therefore there is no guarantee as to whether the order of >> the events actually reflects the order in which the events took place. >> This can prevent a UFFD-monitor from using the events to track which >> ranges are mapped. Specifically, UFFD_EVENT_FORK message and a >> UFFD_EVENT_UNMAP message (which reflects unmap in the parent process) can >> be reordered, if the events are triggered by two different threads. In >> this case the UFFD-monitor cannot figure from the events whether the >> child process has the unmapped memory range still mapped (because fork >> happened first) or not. > > Yeah, it seems that something like this is possible: > > > fork() munmap() > mmap_write_unlock(); > mmap_write_lock_killable(); > do_things(); > mmap_{read,write}_unlock(); > userfaultfd_unmap_complete(); > dup_userfaultfd_complete(); > I was thinking about other possible races, e.g., MADV_DONTNEED/MADV_FREE racing with UFFD_EVENT_PAGEFAULT -- where we only hold the mmap_lock in read mode. But not sure if they apply. The fork() vs. munmap() is somewhat "obviously problematic" :) -- Thanks, David / dhildenb