Message ID | f44680f5-df08-4034-9ed7-6d43ee4c4c2a@app.fastmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp861371vqo; Thu, 6 Apr 2023 01:25:06 -0700 (PDT) X-Google-Smtp-Source: AKy350YZ9x9BknBfxqDfx7ViDItaOf7lqOgxnOA2ooXaYyFpdJE+lvgyrbMRwIgIroTqLhwHhiMr X-Received: by 2002:a17:907:7893:b0:933:44ef:851e with SMTP id ku19-20020a170907789300b0093344ef851emr5284257ejc.55.1680769506030; Thu, 06 Apr 2023 01:25:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680769506; cv=none; d=google.com; s=arc-20160816; b=Q7twZfC1FLMX6Zt3ptv6keOFQpLbiBQSXaGj2KPf8ddlqOEV3G1YxtqsLi4WgTD56X jpI4sRWnmiJzSquyzX0ba692Lg38H/5FscKHMHUBG2o+B7E3KNYUFmLPL0OvPBguLw3T CV0k6qrym6dQryQkanE82BDt/ZDC3GbsVkZdk415GzAU7C1ShpOJc/+YWynDxqK0jxYH KUb2onqL3Y0WgPUjUtOy7h+ZVrP+wcT3XXhgkHKGKOzjLF+hqgE0B7Pl6GPGNoDQmuhg JCwIDiYOC/688FPtFRVWbYuYaA8VzZcQbi6hJ/MGFmzTm4gSYBaQig7FuZVvkGI4A7Ji Yydg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:subject:cc:to:from:date:message-id:mime-version :user-agent:feedback-id:dkim-signature:dkim-signature; bh=sC3OcFARCK6wqn3B9SU+8yo+bZ6jV1elvr18iH9YA44=; b=egJxQ5WgSiIQ1IX8CR3ygxLssU2qpvBpEP7YYfqbLFIznXF0TOdWykl091hsrUKKI/ RBjYYAZ6ntTjmZATCQjol+pznf0F+6A/8teawG7yOU/8nuGpLr+aL/bPvngNMpzcTidu CGfuNQSK4p86H/fYJZf2YDwmcIb9xOFz7xvB2XxzrXVAPh8WLdDT7HGITqzEKANiYWbv vk7SlMWDShkxVI7QRr6dMtwswnSilM9m7n2XGCYYJsLNnUkSTMOjT4o7iTIQ6k0T7d5G YI+9LFj/MterXT8dwpmfateAYUm2HnMA/lJVLqiqsGZAJ4iYIv1YsgyBpWAMfexsJlUs 98ag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@arndb.de header.s=fm2 header.b=jfIQrCC4; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=tgtKQ6fp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xd12-20020a170907078c00b00933433c48bbsi898701ejb.572.2023.04.06.01.24.42; Thu, 06 Apr 2023 01:25:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@arndb.de header.s=fm2 header.b=jfIQrCC4; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=tgtKQ6fp; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235624AbjDFINh (ORCPT <rfc822;lkml4gm@gmail.com> + 99 others); Thu, 6 Apr 2023 04:13:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235579AbjDFINf (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 6 Apr 2023 04:13:35 -0400 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B830C6581; Thu, 6 Apr 2023 01:13:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7F3CF5C00DC; Thu, 6 Apr 2023 04:13:27 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Thu, 06 Apr 2023 04:13:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t=1680768807; x=1680855207; bh=sC3OcFARCK6wqn3B9SU+8yo+b Z6jV1elvr18iH9YA44=; b=jfIQrCC4W93F7GUUr15gh2UlzM+Ji/wULzYDTudF7 1j4NRroit0TwW8EdXv7m7IMfS/gpFJhNKBC90/h++Y3RQeKLGOX7grAycNSKvErF 6JUjWkYn5K+RTIT7t5iJ2mvs1ln1Sd5w77x+vNikcwyNHjFefvOtsV2DF0xZQ/dH o1QuQoA+nLYndw/noTE8TTQFhTQ5mQlnLiXypMhOQae4uXFYAbLnTA19ImY78x7u Fbt+LrACPoXoiVJQWi8X1XPNJrkw7UfjMFMY1IDORLeU0Iszd/Q/S5yHZx6rnGt9 mMdssk8tQypvlvgrpxJbNx2EFemeWPd13enC8pc+5Ni/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1680768807; x=1680855207; bh=sC3OcFARCK6wqn3B9SU+8yo+bZ6jV1elvr1 8iH9YA44=; b=tgtKQ6fpnUVCyNa+j5riZz0tRDmguh/7FoOSWAe3whmaMkOGOVP dFx3JkfdP6IjGJvnImxDZiNojZxYqmeKesiP3Bi35RF7RA00F4UcGjibN2AX94tI RdCeQRRpW2AyzPyDhsHmvbbqaE7alcPbbXzwWxIjZVOFDE4oDcntsDbrh/kbbZ9A VHIQWkt/ZcZU2OKQZQPzlIiOhl+Qc5CgSuFkl2svnfhfM6nwx4MBAbmMAhzX6Wqn 9kJJWYCrN2sH1m6SjmZHpMozwYA3rf/1fY0qpjlk4ZO85miOYwmuWs+wwrZU1LHW Ka07dH5SbJ7egUTLHRrF/vG98gy8JtaX5pQ== X-ME-Sender: <xms:J38uZKaBHdFKwk-BSK6A0zfnVz024pv5D3fFuDMAwNk7RgqAKKm62A> <xme:J38uZNZzCU24OxXAokr-xiDkoKLqlFFafSoE7jcFwP-THfsP6_NlXk6lzKSwcI6du z6PH0AX0FCpeigj1p8> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdejvddgudefvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfffhffvvefutgesthdtredtreertdenucfhrhhomhepfdetrhhn ugcuuegvrhhgmhgrnhhnfdcuoegrrhhnugesrghrnhgusgdruggvqeenucggtffrrghtth gvrhhnpeeffeeuhfekjeevtddvtdelledttddtjeegvdfhtdduvdfhueekudeihfejtefg ieenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprghrnhgusegrrhhnuggsrdguvg X-ME-Proxy: <xmx:J38uZE_uwJ_gkkDdjm03tsFUtQOGcpLsNzypHoPk-eZyB20H0OleSQ> <xmx:J38uZMrd99LBbF_GOSB9Oqcc3YY7bD0-_iH6u87XB5d1r73xDB6lWQ> <xmx:J38uZFqvSGOastlpoKRTHku5VbHnQCeEPe3Q76fQbwGBmtQuRmHaKw> <xmx:J38uZM2NFOwA3IJoaYbJ1JsMqPfcbN7h2IA_m5PHJCC5ThGaMZm6og> Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 439FDB60093; Thu, 6 Apr 2023 04:13:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-334-g8c072af647-fm-20230330.001-g8c072af6 Mime-Version: 1.0 Message-Id: <f44680f5-df08-4034-9ed7-6d43ee4c4c2a@app.fastmail.com> Date: Thu, 06 Apr 2023 10:12:53 +0200 From: "Arnd Bergmann" <arnd@arndb.de> To: "Linus Torvalds" <torvalds@linux-foundation.org> Cc: Linux-Arch <linux-arch@vger.kernel.org>, linux-kernel@vger.kernel.org, "Vladimir Oltean" <vladimir.oltean@nxp.com>, "Matt Evans" <mev@rivosinc.com> Subject: [GIT PULL] asm-generic fixes for 6.3 Content-Type: text/plain X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762414565739864732?= X-GMAIL-MSGID: =?utf-8?q?1762414565739864732?= |
Series |
[GIT,PULL] asm-generic fixes for 6.3
|
|
Pull-request
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-fixes-6.3Message
Arnd Bergmann
April 6, 2023, 8:12 a.m. UTC
The following changes since commit fe15c26ee26efa11741a7b632e9f23b01aca4cc6: Linux 6.3-rc1 (2023-03-05 14:52:03 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-fixes-6.3 for you to fetch changes up to 656e9007ef5862746cdf7ac16267c8e06e7b0989: asm-generic: avoid __generic_cmpxchg_local warnings (2023-04-04 17:58:11 +0200) ---------------------------------------------------------------- asm-generic fixes for 6.3 These are minor fixes to address false-positive build warnings: Some of the less common I/O accessors are missing __force casts and cause sparse warnings for their implied byteswap, and a recent change to __generic_cmpxchg_local() causes a warning about constant integer truncation. ---------------------------------------------------------------- Arnd Bergmann (1): asm-generic: avoid __generic_cmpxchg_local warnings Vladimir Oltean (2): asm-generic/io.h: suppress endianness warnings for readq() and writeq() asm-generic/io.h: suppress endianness warnings for relaxed accessors include/asm-generic/atomic.h | 4 ++-- include/asm-generic/cmpxchg-local.h | 12 ++++++------ include/asm-generic/cmpxchg.h | 6 +++--- include/asm-generic/io.h | 16 ++++++++-------- 4 files changed, 19 insertions(+), 19 deletions(-)
Comments
On Thu, Apr 6, 2023 at 1:13 AM Arnd Bergmann <arnd@arndb.de> wrote: > > Some of the less common I/O accessors are missing __force casts and > cause sparse warnings for their implied byteswap, and a recent change > to __generic_cmpxchg_local() causes a warning about constant integer > truncation. Ugh. I'm not super-happy about those casts, and maybe sparse should be less chatty about these things. It shouldn't be impossible to have sparse not warn about losing bits in casts in code that is statically dead. But we seem to have lost our sparse maintainer, so I've pulled this. I also wish we had a size-specific version of "_Generic()" instead of having to play games with "switch (sizeof(..))" like we traditionally do. But things like xchg() and user accesses really just care about the size of the object, and there is no size-specific "_Generic()" thing, and I can't think of any cute trick either. Linus
The pull request you sent on Thu, 06 Apr 2023 10:12:53 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git tags/asm-generic-fixes-6.3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fcff5f99eaf06ff6818e14751ffeeb677a325127
Thank you!
On Thu, Apr 6, 2023, at 19:04, Linus Torvalds wrote: > On Thu, Apr 6, 2023 at 1:13 AM Arnd Bergmann <arnd@arndb.de> wrote: >> >> Some of the less common I/O accessors are missing __force casts and >> cause sparse warnings for their implied byteswap, and a recent change >> to __generic_cmpxchg_local() causes a warning about constant integer >> truncation. > > Ugh. I'm not super-happy about those casts, and maybe sparse should be > less chatty about these things. It shouldn't be impossible to have > sparse not warn about losing bits in casts in code that is statically > dead. > > But we seem to have lost our sparse maintainer, so I've pulled this. > > I also wish we had a size-specific version of "_Generic()" instead of > having to play games with "switch (sizeof(..))" like we traditionally > do. > > But things like xchg() and user accesses really just care about the > size of the object, and there is no size-specific "_Generic()" thing, > and I can't think of any cute trick either. There is actually one idea I had a while ago that would (mostly) solve this: As far as I can tell, almost no users of {cmp,}xchg{,_local,_relaxed,acquire,release} that actually use 8-bit and 16-bit objects, and they are not even implemented on some architectures. There is already a special case for the 64-bit xchg()/cmpxchg() variants that can get called on 32-bit architectures, so what I'd prefer is having each architecture implement only explicit fixed length cmpxchg8(), cmpxchg16(), cmpgxchg32() and optionally cmpxchg64() interfaces as normal inline functions that work on the respective integer types. The existing interfaces then just need to deal with non-integer arguments (four byte structures, pointers) that they handle today, as well as multiplexing between the 32-bit and 64-bit integers on 64-bit architectures. That still leaves a theoretical sparse warning when something passes a 64-bit constant, but I don't think any code does that. Arnd
On Thu, Apr 6, 2023 at 1:03 PM Arnd Bergmann <arnd@arndb.de> wrote: > > As far as I can tell, almost no users of > {cmp,}xchg{,_local,_relaxed,acquire,release} that actually use > 8-bit and 16-bit objects, and they are not even implemented on > some architectures. Yeah, I think we only have a driver or two that wants to do a 8/16-bit cmpxchg, and many architectures don't support it at all natively (ie it has to be implemented as a load-mask-store). But iirc we *did* have a couple of uses, so.. > There is already a special case for the 64-bit xchg()/cmpxchg() > variants that can get called on 32-bit architectures, so what > I'd prefer is having each architecture implement only explicit > fixed length cmpxchg8(), cmpxchg16(), cmpgxchg32() and optionally > cmpxchg64() interfaces as normal inline functions that work on > the respective integer types. Hmm. Maybe. Except the reason we have those size-dependent macros is that it is *really* really convenient - to the point of being very important - when different architectures (or different kernel configurations) end up causing the same logical thing to have different sizes. The whole "switch (sizeof(x))" model with complex macros is very ugly and I'd much rather strive to implement something that is much more geared to actual compiler issues where the compiler really explicitly does select the right thign (rather than have the preprocessor expand it to multiple things and then depending on the optimizer to do the "selection"). But at the same time, aside from the macro ugliness, it really ends up being *hugely* powerful as a concept, and avoiding a lot of conditionals in the use cases. Now, cmpxchg *may* be uncommon enough that the use cases are limited enough that the "generic size" model wouldn't be worth it there, but I was really thinking about the more generic cases. Things like "get_user()" and "put_user()" would be *entirely* useless without the automatic sizing. How do I know? because we originally didn't have "get_user()". We had "get_fs_byte()" and "get_fs_word()" etc. The "fs" part was due to the original x86 implementation, so ignore the naming, but the issue with "just use fixed types" really DOES NOT WORK when different architectures have different types. So switching over to "get_user()" that just automatically did the right thing based on size instead of the size-specific ones really was a huge deal. There's no way we could ever go back. And while 'cmpxchg()' is the problem case here, I really think it would be lovely if we had some nice *unified* way of handling these "use size of access to determine variant" thing. Something like _Generic, just based on size. I guess __builtin_choose_expr() might be the right way to go there. That's very much a "compiler statically picks one over the other" interface. I despise the syntax, which is why it's not very commonly used, but it might be what we should use. Of course, another reason - other than syntax - for our "switch (sizeof())" model is simply history. The kernel "get_user()" interfaces go back to 1995 and Linux-1.3.0, and actually predates __builtin_choose_expt() support in gcc by several years. Gcc only started doing that in 2001 (gcc-3.4.5) So we do have a few uses of __builtin_choose_expr() in the kernel, but our really old interfaces simply didn't even have it available. Linus