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 ED1A3C27C4F for ; Sun, 23 Jun 2024 23:16:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0566B6B0484; Sun, 23 Jun 2024 19:16:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 005B56B0485; Sun, 23 Jun 2024 19:16:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0F8B6B0486; Sun, 23 Jun 2024 19:16:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C4B8E6B0484 for ; Sun, 23 Jun 2024 19:16:20 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3561D120964 for ; Sun, 23 Jun 2024 23:16:20 +0000 (UTC) X-FDA: 82263714120.07.D7D0234 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf10.hostedemail.com (Postfix) with ESMTP id 42524C0002 for ; Sun, 23 Jun 2024 23:16:18 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=hoJ9m5DJ; dkim=pass header.d=linutronix.de header.s=2020e header.b=IM8gAc0L; spf=pass (imf10.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719184565; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Awfxb6K8YyyiKriFuf6T4876/ylOHxEjEiYm6TdruTc=; b=XCcZnEqG+4V5TXT1l/ALxB7fBjYJ9odBxs/DXFIZQ6vV90fJvbmwsMv45y7WqaBZER63hg 0Xfz/MCZamwldA/1nrBI0fXDEEPccvrphkN2ahaG3gG/vB6dJqvxa9GmEMW820yXFPlRse IwfOccYbhMOXPOA8oUJCaeCtMvLW9aw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719184565; a=rsa-sha256; cv=none; b=kDVcLag0miLVc9Zughi39D/2cOcB/otzscwYa6/El6mb6VnuvqYdqwliCzuikar8LFi7vk gcDV+gNZfOC24PqZgn0MlJSOFOxq8qG+gMiiXnCdo2MKxggBKfCuN+dH81ipxLeTz3nIKZ 7MNNCcaOXCWI22NfBsKMGKRGPU64yN8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=hoJ9m5DJ; dkim=pass header.d=linutronix.de header.s=2020e header.b=IM8gAc0L; spf=pass (imf10.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1719184575; 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=Awfxb6K8YyyiKriFuf6T4876/ylOHxEjEiYm6TdruTc=; b=hoJ9m5DJ7CxadEFUBc8Yw75bhjjtIBXWTyZwXsKl3M5gg++/2sD4zfI880ytdCq8HzIMPH ggTH5f3dfYmWW+yfQuKgXEbQXGJR7t/wVl6Jc6AAYrwomrB8nnnckjZKRu2MVOsyZ4R28T AHOqtwKc53O1dti5K4KQ5jos815JM5z+gLC/LuA/OxxoYwSbiuiZwt+yfD3jezgI6Durtr 5JTon4K4GJxEJm6n3ZpicI95PbhQUPRfI6Cnvn9MU5L7pYCGCQhFkXvav+hQM01Jhwql2n xXzqJYcdiui9xfZDyoIAWqHy9cEFBGMRZ5JzWEWoZHSeb5kwDJm+G70r1xQ77A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1719184575; 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=Awfxb6K8YyyiKriFuf6T4876/ylOHxEjEiYm6TdruTc=; b=IM8gAc0LXIokS5JU7NKxUScCyhyj4TWpOD9X5OJsotej6pOmvtVwVLl55Zq5uuVOvuMEnx QiSecQhayyiYIhBA== To: Kent Overstreet Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Jens Axboe , brauner@kernel.org, viro@zeniv.linux.org.uk, Bernd Schubert , linux-mm@kvack.org, Josef Bacik Subject: Re: [PATCH 3/5] fs: sys_ringbuffer In-Reply-To: References: <20240603003306.2030491-1-kent.overstreet@linux.dev> <20240603003306.2030491-4-kent.overstreet@linux.dev> <87frt39ujz.ffs@tglx> Date: Mon, 24 Jun 2024 01:16:15 +0200 Message-ID: <87a5jb9rnk.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Stat-Signature: z6mon3htkb5bt39kxz6oakcpu81g5tcd X-Rspamd-Queue-Id: 42524C0002 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1719184578-763080 X-HE-Meta: U2FsdGVkX1+5+04vn95rzuhscfXripasUT4SlCW0WAftaLlW7fYYeIj0lkHPYRaB6aISGOdV6n7J6EtOkLEDoz8it/ebPobW1/CswQArGPG+G39ZErI0V9jrtlu42Z4D6MzJrwgUotY/Goqol85cscbt/tQDCKbusIdZmRVNFQBGQkg/YOywwMq8N1TvYOjUpZOcsFqYVzBhaSwupdTo0EN63luXuCk/EYCGcWjdvAyFVEmTC3r/EMnN0xtmGj3V2qk6W6xi3jNZc8IVfEzHluIs7Esa65D9LYktOFG4shcyU2RFzBGZGN/GO+M8P4OhHdP+hybuZXlnhmiWLSH/li5JRgImburAHTmrtHVd+t2Z7SKarFe4WtnV2gMiaAmw3ew56Dog9H1OR4jL7+zyelJh14J1x9tPWgPYeMuxHkIVjIbSwoPvEOokT+vyBoWnvIpP/5GC2QsvS6XTC67uQWOdgPnxZkPuEzE21RdQW4EOf956MH5EmHCseLAJie8UR9w+oMpel+J8l5iJhWNpk4kOWBB1Vx5E+8eS2pHzo7q5KsWwdocw5NHNDcTB7VGk+JF+OrLQBDgYE2Ln/g0b0Ejqyh6YXgJsWmDZG1R9M8qoP7RIoLiqXNKOjV4fqsNtkurEWJfT7Kc1l3QlTxsQJwiauyH0VKkPR45Smwvawxyn6EvBZhqk+3xxUD4xWulvM4CwXndDE3g5rDNqsBFJkq3oD2On93HfFv8V3BG3QVfh3FidIm4PMd1VYacz26W73JJZHIZBzlUlnYeJOXZFdV3cZQJERk6tGcPJ5mrVYPJY1WiZ2Ht9RTpw/Y1nAazHGvRCieBbhwuJqN9+8bDwylEIC1FDFMk9sobraxC+EqIQYCF6aQsEUuJOINoX6uAd6j1IdkOekhnurYeBKU1L9miNULLrtaHYHpW8CCUTH1uyhUQpfULbfAeoC9ocSJZY/FaUsa0t8bT7kOCqWtk Lb0qIzMe 6BPel4orWuGhJs72HyHklPHJ8IbeAvNslIfMZ4ZWytjSChQeUD/aZCWRmBZwLwVgto9odLeRYwnMgf+B0Pb2JscXxTSMguqDhs8LVlWy2QlNHUkulCeCGt+BhjGoGJ19IjzVeHJbX4PRCVHIT/lrNrx0O1JUJROBKhLFr5nvSDLARLEogR53oXabHQg== 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: List-Subscribe: List-Unsubscribe: Kent! On Sun, Jun 23 2024 at 18:21, Kent Overstreet wrote: > On Mon, Jun 24, 2024 at 12:13:36AM +0200, Thomas Gleixner wrote: >> > + /* >> > + * We use u32s because this type is shared between the kernel and >> > + * userspace - ulong/size_t won't work here, we might be 32bit userland >> > + * and 64 bit kernel, and u64 would be preferable (reduced probability >> > + * of ABA) but not all architectures can atomically read/write to a u64; >> > + * we need to avoid torn reads/writes. >> >> union rbmagic { >> u64 __val64; >> struct { >> // TOOTIRED: Add big/little endian voodoo >> u32 __val32; >> u32 __unused; >> }; >> }; >> >> Plus a bunch of accessors which depend on BITS_PER_LONG, no? > > Not sure I follow? > > I know biendian machines exist, but I've never heard of both big and > little endian being used at the same time. Nor why we'd care about > BITS_PER_LONG? This just uses fixed size integer types. Read your comment above. Ideally you want to use u64, right? The problem is that you can't do this unconditionally because of 32-bit systems which do not support 64-bit atomics. So a binary which is compiled for 32-bit might unconditionally want the 32-bit accessors. Ditto for 32-bit kernels. The 64bit kernel where it runs on wants to utilize u64, right? That's fortunately a unidirectional problem as 64-bit user space cannot run on a 32-bit kernel ever. struct ringbuffer_ctrl { union rbmagic head; ... }; #ifdef __BITS_PER_LONG == 64 static __always_inline u64 read_head(struct ringbuffer_ctrl *rb) { return rb->head.__val64; } static __always_inline void write_head(struct ringbuffer_ctrl *rb, u64 val) { rb->head.__val64 = val; } #else static __always_inline u64 read_head(struct ringbuffer_ctrl *rb) { return rb->head.__val32; } static __always_inline void write_head(struct ringbuffer_ctrl *rb, u64 val) { rb->head.__val32 = (u32)val; } #endif A 64-bit kernel uses u64 while a 32-bit kernel uses u32. Same for user space. The ABA concern for 32-bit does not go away, but for 64-bit userspace you get what you want, no? Now why do you have to care about endianess? union rbmagic { u64 __val64; struct { u32 __val32; u32 __unused; }; }; works only correctly for LE. But it does not work for BE because BE obviously requires the u32 members to be in reverse order: union rbmagic { u64 __val64; struct { u32 __unused; u32 __val32; }; }; That's a compile time decision. You can't run a BE binary on a LE kernel or the other way around. So they have to agree on the endianess, but BE has the reverse byte order. That's why you need to have another #ifdef there. Thanks, tglx