From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793439677; b=hfBJpTPhRMEeQRTmQIiC/cwuc0anD3TnXTbik1J1YGvi7qyOI9Fw8qMnAVHh4uzstp9V APjDl/TBTnhh1o23+kcXA9HWLtH7B1Eien1L5UXmRlHqkESQ817FM/7eYVFdridFFShlk RG+siLf7Z4+JV3A/QLnXmtOGgXZik9ju1J6B/wgLbG9ytoKiQl/s0oChLV/FErfu0OiUa gWg85iSE8dipD/iVu8RWP/nb3Ch7fwVa1A42UWI7t2ZNdW0UyM8D27QWqWlkUMaJBmtdH 5pfKwZw1ohJo9KcWwDRkbsiq+a6GF5Cp4mgU/hT8IVPnhiqH6jIlMLPgWplcIiJWSSw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793439677; h=Received:DKIM-Signature:From:Date:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding:Message-Id:References:In-Reply-To:To:Cc: X-Mailer:X-Developer-Signature:X-Developer-Key; bh=UtgaK5EERO1GGEhTGodSTh9d2aQEbh7tZUgBnXPi378=; b=V4+IV6WZemx6KGCwKlct70jjjUP8oxvlEyfxjpNgpKcHFbWvAmqYEP/TmYnVojsNyxNS D59I+Ut11INPzgooySHOta20xYkItwI+xlYCosC9ew5lqasJkIp/WlgL06n+oKTBSxe/g qTvGoF/UFnF6BNWrFzXo4irMLFkdrK5NskfSbiN+rcb+hM4a46N+Mc0HiKGvnx8lMKR5y BcVQR6/59aF/vxmZw0Jqr7a+u77pV7QYOtnZKrvpOK0IKpYtR/uLDQqvv+2+wWYRncpef fC0bR9aP11MouqWrJwH6f8AkJ2hOudd7kI1M9/rwRkBGvvVxV8YdD93nWYEXqwAHvTA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=dXjd47I5; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F36A0606A31C; Sat, 31 Oct 2026 09:41:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=dXjd47I5 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 693D41F000C1; Sat, 31 Oct 2026 09:41:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793439676; bh=UtgaK5EERO1GGEhTGodSTh9d2aQEbh7tZUgBnXPi378=; h=From:Date:Subject:References:In-Reply-To:To:Cc; b=dXjd47I5b873C5hOOHYSu8ebp4K8YqRwxt2AMgh9TU5wXBGFQ8VpBmBBwidpEUoeQ fMjYRdJEfRkx7utnc60zGHK13AzfUUZwhDc9DZs5e7wWKETurtgsi5sMSzACyoX6aE AdbvsYFlemwmljukT15fZvMAhETH+Codrn0QLiBEZa3zJXHUZsllTe4czIrikkHb1R b3VE7Q5FZbpio92/nqmGC8DShC2+0SuXxJxHq9ddq3lH5HfnL2uCJ0tiAdyN8PcHNU dgjoxM+XN+cSNi5hGtlML69Zj+EnJkAo+eyQIAJxO42w2Q18ggyai31M0QFzHnJiDj xev2E75em2PFw== From: "David Hildenbrand (Arm)" Date: Sat, 31 Oct 2026 10:39:33 +0100 Subject: [PATCH v3 04/47] mm/memfd: make f_pos accesses atomic X-Mailing-List: linux-cxl@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20261031-fixes_core-v3-4-d6437171ecc3@kernel.org> References: <20261031-fixes_core-v3-0-d6437171ecc3@kernel.org> In-Reply-To: <20261031-fixes_core-v3-0-d6437171ecc3@kernel.org> To: Andrew Morton , Johannes Weiner , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Kairui Song , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Baoquan He , Baolin Wang , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Kees Cook , Peter Zijlstra , Jann Horn , Pedro Falcato , Hugh Dickins , Pasha Tatashin , Pratyush Yadav , "Matthew Wilcox (Oracle)" , Jan Kara , Zi Yan , Lance Yang , Rik van Riel , Harry Yoo , Alistair Popple , Nico Pache , Ryan Roberts , Dev Jain , Usama Arif , Kiryl Shutsemau , Matthew Brost , John Hubbard , Peter Xu , Will Deacon , "Aneesh Kumar K.V" , Nick Piggin , Oscar Salvador , Minchan Kim , Muchun Song , Xu Xin , Chengming Zhou , Chris Li , Kemeng Shi , Nhat Pham , Youngjun Park , Gregory Price , Joshua Hahn , Rakie Kim , Ying Huang , Jason Gunthorpe Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-cxl@vger.kernel.org, Josef Bacik , stable@vger.kernel.org, Muhammad Usama Anjum , "David Hildenbrand (Arm)" X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=2827; i=david@kernel.org; h=from:subject:message-id; bh=SDZRDly1DR5dPZ6jcWm3nd9SG3ocTLJmjE4kP1Q8ggo=; b=owGbwMvMwCF2/OVpCdfQ3ZWMp9WSGLKebk/V4mLn+Bp8xq9obaZAt8WnGB4VpRPBMkWyzUVOG il+7QwdpSwMYhwMsmKKLEHB9w1evlxXW+3Gxwwzh5UJZAgDF6cATGTdDYa/8r0/2YsmGsemzpsb m/fZ0FNN4mm7L6fZ88lv8i9/Yak8yMjwYVNNYKZSRXHESfXwqEm1ec0PZQRkwqvvn98jVOIXbc4 KAA== X-Developer-Key: i=david@kernel.org; a=openpgp; fpr=1BD9CAAD735C4C3A460DFCCA4DDE10F700FF835A From: Josef Bacik Commit 9c225f2655e3 ("vfs: atomic f_pos accesses as per POSIX") made read(), write() and lseek() on a shared open file description of a regular file serialize on ->f_pos_lock. The flag that asks for it, FMODE_ATOMIC_POS, is set in do_dentry_open(). A memfd is a regular file too, but its struct file comes from alloc_file_pseudo() and never passes through do_dentry_open(), so it does not get the flag: CPU0 CPU1 write(memfd, "a", 1) write(memfd, "b", 1) pos = file->f_pos (= 0) pos = file->f_pos (= 0) vfs_write(..., &pos) vfs_write(..., &pos) file->f_pos = pos (= 1) file->f_pos = pos (= 1) One of the two bytes is overwritten. Two threads writing 100000 bytes each, one at a time, to a memfd end up with a file that is far shorter than 200000 bytes, while the same program on a tmpfs file never loses a byte. Set the flag when the memfd is created. As for any other regular file the lock is only taken if the file is reachable in more than one way, and nothing a memfd does in read or write waits for another operation on the same file. This cannot be done for all alloc_file_pseudo() files: anon inode files such as eventfd are S_IFREG as well, and a blocked read holding ->f_pos_lock would lock out the write that is supposed to wake it. Fix generated by an LLM and sent by Josef Bacik in private. Fixes: 9183df25fe7b ("shm: add memfd_create() syscall") Cc: stable@vger.kernel.org Signed-off-by: Josef Bacik [ david: minor description tweaks ] Reviewed-by: Rik van Riel Reviewed-by: Gregory Price (Meta) Tested-by: Gregory Price (Meta) Signed-off-by: Gregory Price (Meta) Reviewed-by: Mike Rapoport (Microsoft) Acked-by: Lorenzo Stoakes (ARM) Reviewed-by: Pedro Falcato Reviewed-by: Kiryl Shutsemau (Meta) Reviewed-by: Pasha Tatashin Tested-by: Muhammad Usama Anjum Signed-off-by: David Hildenbrand (Arm) --- mm/memfd.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/memfd.c b/mm/memfd.c index 0f6fff004f5e4..0e3ff3eebfa82 100644 --- a/mm/memfd.c +++ b/mm/memfd.c @@ -482,6 +482,8 @@ struct file *memfd_alloc_file(const char *name, unsigned int flags) } file->f_mode |= FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE; + /* a regular file like any other: POSIX.1-2008/SUSv4 Section XSI 2.9.7 */ + file->f_mode |= FMODE_ATOMIC_POS; file->f_flags |= O_LARGEFILE; if (flags & MFD_NOEXEC_SEAL) { -- 2.43.0