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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9EFFCC7618D for ; Thu, 6 Apr 2023 20:03:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236345AbjDFUD2 (ORCPT ); Thu, 6 Apr 2023 16:03:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39004 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237421AbjDFUDT (ORCPT ); Thu, 6 Apr 2023 16:03:19 -0400 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA7B083D0; Thu, 6 Apr 2023 13:03:17 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 03CAB5C018C; Thu, 6 Apr 2023 16:03:17 -0400 (EDT) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Thu, 06 Apr 2023 16:03:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1680811396; x=1680897796; bh=alW+rItMMZUBv3x2WJDrCkS16QOeGSZn6sF y9BwGDDA=; b=a1ENtT/Kd7sEGN62GAhjp4PF0eOGkwiuFTaHixKRImwlqxVJjGB tKW5nMApOSWk0uUQ871fNLq8480laJcgHpmaK1x0Klpy+cTCLzCl/oYjCLuDn94A kRzS8wNPGgtWMxSWyLL2G3Loft5y4HhwSDYuFfxC87arv7nBfzbWWeW4mOBdIDB8 h0F7AoHmI1Ezo9HI6DRnDumpeAKvXLKpY9gktbcA8Pf21Fhm291PYtqeQliLnva8 muW4htisShgzyKXsOWafQXG6e8H1uPJdDfirl/FBsDBWPpnF1uOFowBlYY0DOP5C VTJafPktTik6jWUF1Zk/Ike8Yf26I6w69tA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references: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= 1680811396; x=1680897796; bh=alW+rItMMZUBv3x2WJDrCkS16QOeGSZn6sF y9BwGDDA=; b=MucNCKYY+nfqafXm7sZiWP3KvPbHU5kIN2coW9dtgElWX2c4PKl n8xoeGpegG69jbejq8lxquHD3k7hOKcYUX6YsrkVeT6XU/3Ju3feFlTefh9VUJOy MyJ/SDJWSQrkyK4eO992pjmPgAe36gp8CusyHNq5tzrlk1gaDDXqD/bsH8xvWyDH U/zhiI8zG98YmPaRlz5vKtZNnLSzC5zyY8ly1ZMLOrwYgNJhXFaUZpqE5moP0DpK Ya2C8M/suVJhTLD8+fODywpuF7+MLQfDdX2dKaZbX3EqkEGZCHIEEpNCoW1UrnfD OTbA7AY5Lf/dJ+Og58KAjMsfhWIlfylkwJw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdejfedgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgfgsehtqhertderreejnecuhfhrohhmpedf tehrnhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrf grthhtvghrnhepgeefjeehvdelvdffieejieejiedvvdfhleeivdelveehjeelteegudek tdfgjeevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eprghrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9BB63B6008D; Thu, 6 Apr 2023 16:03:16 -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: In-Reply-To: References: Date: Thu, 06 Apr 2023 22:02:45 +0200 From: "Arnd Bergmann" To: "Linus Torvalds" Cc: Linux-Arch , linux-kernel@vger.kernel.org, "Vladimir Oltean" , "Matt Evans" Subject: Re: [GIT PULL] asm-generic fixes for 6.3 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 6, 2023, at 19:04, Linus Torvalds wrote: > On Thu, Apr 6, 2023 at 1:13=E2=80=AFAM Arnd Bergmann w= rote: >> >> 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