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 5F76EC433F5 for ; Sun, 30 Jan 2022 06:24:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 999576B0072; Sun, 30 Jan 2022 01:24:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 949306B0073; Sun, 30 Jan 2022 01:24:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85EC16B0074; Sun, 30 Jan 2022 01:24:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by kanga.kvack.org (Postfix) with ESMTP id 7A47B6B0072 for ; Sun, 30 Jan 2022 01:24:00 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2E9608126966 for ; Sun, 30 Jan 2022 06:24:00 +0000 (UTC) X-FDA: 79085963040.29.CB53BAA Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by imf07.hostedemail.com (Postfix) with ESMTP id C6C2140004 for ; Sun, 30 Jan 2022 06:23:59 +0000 (UTC) Received: by mail-pj1-f42.google.com with SMTP id d5so10548561pjk.5 for ; Sat, 29 Jan 2022 22:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:content-transfer-encoding:mime-version:subject:message-id:date :cc:to; bh=lLgjuXXMh7wGSsLO5QtsPtIxGD3RrDU20Y6vRv87tkE=; b=kXunjOU2Wc0s7Uf2pcB0ARQFg4XQj4dvxaktUNYBu+UzKe38R4cdNN9pt6c4WE+teZ jG420pcTYigaykKu8ju4HORidBZavpUyNdKXeCejL7uPC2BzgnDqr4aAKMAnC29D06xY tJ2Bk83AFhWHcEBr7jzwhLavoo/8DMxLW5ASrZUQkRPLl2N1ZpyYj+76qvwQYDID93xS zFLazQkxSVSPiswOi+bl5KkRYjHz/nERTpVibNVmwA4duaENyzfcwNJ2js1kNBi0SFot AJ8hD+dngocpaj9UzyfUzsK6q0nXrNih6AdvvxgCYMBJQlhAvLv92YF2XJrhNpvD/TXW u9Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:cc:to; bh=lLgjuXXMh7wGSsLO5QtsPtIxGD3RrDU20Y6vRv87tkE=; b=JoA9dW5Qx3DRLDLxOEyI6hxRntoOKuJN1aJLxL2mqclQVct9v2nOqhZ2oC2llPRsjd OEtpHy3vpdaAlzKwT3WBvWTVX0csvm0gexd0fFhJpMxutF530wW/4BlOmmOsdWatQe4H jn0F2tf3jKKy1E0NIyBL4QisGrKSDbRp5icljOsHmSkGk3hrBZhdOjbiLwVNObb8AcMS 1pBeNCCQgyrU5yb+qpBTVXvMnpEtSvzUKA1AH1wNFLAim4tGuVbpMpR1mDjnWIv6vJAt t7r8B84ZAGTiYGo5kw1qH6IsaQvTcdz1E1UQdRmbLu3s4BtRvYBcjE2VXRupejQ2grPr zOFQ== X-Gm-Message-State: AOAM530u5XhV0tmciHQe7nrBEzGiHonRFwitVI6AyEqRnQ3vXYhmsicT Tzu3RjPDgjVbd7y+uVBtf+A= X-Google-Smtp-Source: ABdhPJwbtwd38YXBKJDpAZOyYZzZbYuwhZf9xsg6ihl+RUsevo2zNohIUndPmNSlbe+/0wrfPW041Q== X-Received: by 2002:a17:902:6948:: with SMTP id k8mr16013090plt.136.1643523837478; Sat, 29 Jan 2022 22:23:57 -0800 (PST) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id h10sm3964831pgk.0.2022.01.29.22.23.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Jan 2022 22:23:56 -0800 (PST) From: Nadav Amit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: userfaultfd: usability issue due to lack of UFFD events ordering Message-Id: Date: Sat, 29 Jan 2022 22:23:55 -0800 Cc: Linux-MM To: David Hildenbrand , Mike Rapoport , Andrea Arcangeli , Peter Xu X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Stat-Signature: ab8f1ucpb3k9euh716twyab6b64u34cm X-Rspam-User: nil Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=kXunjOU2; spf=pass (imf07.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.216.42 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: C6C2140004 X-HE-Tag: 1643523839-85709 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000100, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. Obviously, it does not make sense to keep holding mm-lock while notifying the user, as it can even lead to deadlocks. Userspace UFFD-monitors can workaround this issue by using seccomp+ptrace instead of UFFD-events to obtain order of the events or examine /proc/[pid]/smaps. Yet, this introduces overheads, is complicated, and I doubt anyone does so. I wonder if the API is reasonable, or whether I am missing something. Thanks, Nadav [*] Note that I do not discuss UFFD-monitor issued ioctl's, but the order between UFFD-events.