From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B2BC1D5CFB for ; Sun, 8 Mar 2026 10:08:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772964513; cv=none; b=Xz/Wkim5yKFkS62+f0vR76yZOd0Ll/mCFstO1VK82yR0HtXoEZ9iR5a/d8WNHp9KaXjrcokUWgcc+LEB6O4foI57GcycxLnYjjtGXE69BKHcZv/8AvJ237Id+j5fqh045qfm3Mdc+6J9p3VQnlHuaQ7ZDLKY+ttUMNAem4UbxV0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772964513; c=relaxed/simple; bh=j8KqWUe4dOFfgAVxHdIR8d2Hy24ezYs4DCRRG3FQD14=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=B6AA5j7gDM/MO3c3kQXdlboqsI5RsTqEF+kF4I2GLQJa1eBICV1fDemCOk41/EAV3PjEaKLPQooPBmLM7MKpOfeNVyVpvfkb51ag/C1kshRUBfHQ3LvrNAUvU8TloarG1XN5/2kJ8wzm1XsjtrGcmvu7uQ+o6043XqZd7MnGo6o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Zyx6sSo4; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Zyx6sSo4" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-48535a0ef86so2983195e9.1 for ; Sun, 08 Mar 2026 03:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772964510; x=1773569310; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=CUOiK7ETWKURNC4k+PsoZDFEtQAHoDgcYfh4e3dhZZk=; b=Zyx6sSo4UJaKulnV8h5B0p5EZetrtKk+Y1EP1R4Yt9Q9JidvpTG6fCQberXkNNYXfD 7WPiEkDxxMNxoSd+oVfCGrIaLZUqkUeq3xGgTmg8f3b9g2a6tzWrpcopqgPxZzXT3FD6 lKOuilccPnaP6tdLVT5okqz3VtmXyTsbVvpdDdGUAMl+LkhshlAwTUxd+abcKbhJhTYP zjnL+1zH93plzUbcFIsQUTudPU3uE8yYeDBuXR47CDbHhGeJcXcwIS/Nuv8dPzI/WcVA gyO4p3Z1Z6RNEDshKIpbvsUk/F/VxMcHtb8SRWk3CQSGJV3XWViyP3Itshz8KhISFCGT 5sZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772964510; x=1773569310; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=CUOiK7ETWKURNC4k+PsoZDFEtQAHoDgcYfh4e3dhZZk=; b=Mgz2JDGF2sOJ+DAs3Lt5Ugh9rdrUQrKDU2nUQKDCbobT3IoJpsoD8jV/3TZCfC3R+/ OAaXyqSjES3uju7UJC5wlukzZQbgAp1l+AChPhe46kwBIlDzSZLwxgsyQjn5ypm4UfZ/ HErlZ7vuY7qqfU6iSFEdZsIkSTKp6XimFC7ufTkGlybOiMg40+yT/69jPXHxrEkNS3bd 74QftDkCHqugVYcjtQhe/Sqjs7edhtED0fOVbQd0cujcZ3pDntYUVirn6GQGNiJedSyN INiBrk/c4QGpI9KbpYvOy1hTjXwjsHaofOQiLG7xL6gcmawe97l446Jb2Zs0LiWk5pFL d4mA== X-Forwarded-Encrypted: i=1; AJvYcCXUJEC8T0gite9ZQHmz/wAJRR50oF4+rXsmi7E70FVev4BlR4CAfLIHWUgXMBw9IV8Xvk6ZMruCBVMpZmU=@vger.kernel.org X-Gm-Message-State: AOJu0YyD2/4gwqZI+1fm1E3FiqrMFuRj28XI54+Ft6N25E28+kcxY9KX pvOANEUp4TdANSwB2zViN17RkdSEbqFjqWSZmj+TaJhjdGp2aRmAM1I9 X-Gm-Gg: ATEYQzxZMMBXfU1YzBHeV4Z8Vr1zcAdcN/XrgTW3RKyyueraO5KiWeu0uf5OLl+T9BD mA+US9iROPfEB0LwZZ5d4A2QZn6xoZXj0R1jX97+JaUX/s/Gw6XZjz/giH8GHlJLw8Y9k/loLDL M9+s6QubLQTFOSoqXsLz+jad3HoX6imem5cgJDvxvS/bka3/psYsHivWGxHhTSnjNmXl68gKgJs YMqqvVP5UwVkSpbpOZAXoOMDD2Fuh9DO1yUafrRzoSpieXZmflvzXNSJStvdQVUO3f5Hym/cX3E J0oZOX3GMD5GuGB+XgUKL/LAsEov/mshBcd0nJAAV2MFdR78Mbvn06DveFllc57bW/Rl7Y64G39 OGSiHl89eIXdajGCKBOEos4WA33TKRrsJyZqH11ektXEjOqFEk1lxfxzDqZrvreVbEWOS8kKfac VN/dJ7SlONZ1LKg0iTg2mxCqGf8IabTqV0+HgFiTu2xPfQanOQXCpnER43GEt1bhze X-Received: by 2002:a05:600c:c173:b0:485:3812:36dc with SMTP id 5b1f17b1804b1-485381238b3mr22370555e9.9.1772964509979; Sun, 08 Mar 2026 03:08:29 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae46353sm19262201f8f.33.2026.03.08.03.08.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 03:08:29 -0700 (PDT) Date: Sun, 8 Mar 2026 10:08:28 +0000 From: David Laight To: Eric Dumazet Cc: Linus Torvalds , linux-kernel , Thomas Gleixner , Eric Dumazet , Christophe Leroy , Dave Hansen , Kuniyuki Iwashima Subject: Re: [PATCH v3] eventpoll: Convert epoll_put_uevent() to scoped user access Message-ID: <20260308100828.11826dda@pumpkin> In-Reply-To: References: <20260307200715.1464206-1-edumazet@google.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 8 Mar 2026 06:19:13 +0100 Eric Dumazet wrote: > On Sun, Mar 8, 2026 at 12:45=E2=80=AFAM Linus Torvalds > wrote: > > > > On Sat, 7 Mar 2026 at 15:33, Linus Torvalds > > wrote: =20 > > > > > > Oh well. This makes one little piece of the kernel better, even if > > > other horrors lurk everywhere... =20 > > > > Side note: if you want to improve code generation just a *tiny* bit > > more, you should make that epoll_put_uevent() return a success value > > instead ot the updated pointer value. > > > > Because right now the caller does this: > > > > events =3D epoll_put_uevent(revents, epi->event.data, e= vents); > > if (!events) { > > > > and that "if (!events)" test triggers even for the success case, > > because the compiler doesn't know whether the "uevent+1" might > > overflow (and we really *do* want to make sure the compiler doesn't > > remove overflow checks even if it causes these kinds of issues). > > > > If epoll_put_uevent() just returns a success/fail marker (or 0/-EFAULT > > or whatever), we wouldn't have that issue. > > > > HOWEVER - the same magical ARM case would need to be dealt with - the > > real size of the user space notion of "struct epoll_event" isn't > > actually known to generic code, because it ends up depending on > > architecture-specific packing issues. > > > > So you'd have to pass in 'events' by reference and epoll_put_uevent() > > would still update it. > > > > Probably not worth it - it would mainly get rid of a perfectly > > predicted conditional branch, and might possibly help a tiny bit with > > register liveness analysis. But it's unlikely to have any really > > visible effects - it's not like the clac/stac overhead. > > > > But since I looked at the generated code, I thought I'd mention it. > > > > Linus =20 >=20 > Thanks Linus >=20 > BTW, not really a bug, but we could remove these extra semicolons > added in af4e9ef3d784 ("uaccess: Fix scoped_user_read_access() for > 'pointer to const'") >=20 > diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h > index 809e4f7dfdbd4d4426ef38457ae108f119cb1bee..cdce14d864d6b71ea87396aee= 35acd6c9f188ae0 > 100644 > --- a/include/linux/uaccess.h > +++ b/include/linux/uaccess.h > @@ -654,15 +654,15 @@ static inline void user_access_restore(unsigned > long flags) { } > static __always_inline void __scoped_user_read_access_end(const void *p) > { > user_read_access_end(); > -}; > +} > static __always_inline void __scoped_user_write_access_end(const void *p) > { > user_write_access_end(); > -}; > +} > static __always_inline void __scoped_user_rw_access_end(const void *p) > { > user_access_end(); > -}; > +} I was clearly writing those too quickly... David >=20 > /** > * __scoped_user_access_begin - Start a scoped user access >=20