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 8EB77C433EF for ; Sun, 22 May 2022 21:09:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A505B8D0002; Sun, 22 May 2022 17:09:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FF9A8D0001; Sun, 22 May 2022 17:09:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A00D8D0002; Sun, 22 May 2022 17:09:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 556C58D0001 for ; Sun, 22 May 2022 17:09:41 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 374A020B20 for ; Sun, 22 May 2022 11:44:22 +0000 (UTC) X-FDA: 79493195964.28.38B260F Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf30.hostedemail.com (Postfix) with ESMTP id 07C0A800D1 for ; Sun, 22 May 2022 11:43:54 +0000 (UTC) Received: by mail-ej1-f43.google.com with SMTP id f21so9749147ejh.11 for ; Sun, 22 May 2022 04:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=BOcP7c+b/aIig+wDwK1ySXDPQYBqPco/XJdaO5tL43M=; b=HbiWaat1vy9fqglT1AQ5mQ5JjCpkhO+E8jnEtRhzPiif0qrvDKKdx8B95OMkJtx62f 50z5Sn4S5OQoHLNAGBGDcg/pM3dJVc3FeOKAJ33h9DBUzBryUmLfBVNeEMKJeo3lBUaX xorGA9zq+QsM0EimtbURXWG1azBOZqa655UGvWWFRHq2vv0bEgZ9hUSxdC7AyrZSM0K1 gmpjbX5Ksc66SeqRZbC++YgqZxATC9x3cgK6OQg6EKrLFj22uin13ycLwqXmbpFKdEyk gTfnlwyzGuksJcevZj0OkBT28KA9vQfDd/xROApkgmO1+q7Yd8+18f+ljXPwZEs2QkaW cj4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=BOcP7c+b/aIig+wDwK1ySXDPQYBqPco/XJdaO5tL43M=; b=zevScgzFtAnnNqEd9gE5ZbfJ4FJvt70kU+xV3z81YDdh6HpsgGHEKHKHSgTeERCWvN eVvhEy5VpoANMIMmj7oINRQKADwIELlXhU8lzs9SkDVn4vAl9uRfxc+6zjh542kLgfes SSEPBcL3nhXADxS4kA1S+dZtSp6tJlWUa28scB2RI6Z2/wJyYPufErzrH+WqVACltfFh ymy/anACPVYBgd15BNYy0JfrDesLTyfXFPv6jQUBGnlJRqi6Qe7h8cIIjWWP98e87q+P fxJSZtkL2RTbyZYDO1LQ+3oD3NVJ0dQOOGfpo2b7IRfEt+RFfZNHl4ESLVaXX9z+XrHx v5xA== X-Gm-Message-State: AOAM531fEnQZBU1v79eiwm2ksh8K7o3dNuzpmpLN7xXTReE6tJo4Fwd4 seEK8/010Auer3LxEDmbk8A= X-Google-Smtp-Source: ABdhPJzRfCqhzI7QwnogN+fhYc0fh38naDmT7SQjDe2PeOI83f57DAXoKHZfwtI5G/K8ujCSqBK8Kw== X-Received: by 2002:a17:907:6d98:b0:6fe:b83f:802d with SMTP id sb24-20020a1709076d9800b006feb83f802dmr6984772ejc.182.1653219860369; Sun, 22 May 2022 04:44:20 -0700 (PDT) Received: from mail (239.125-180-91.adsl-dyn.isp.belgacom.be. [91.180.125.239]) by smtp.gmail.com with ESMTPSA id 5-20020a170906024500b006fe8bf56f53sm4766942ejl.43.2022.05.22.04.44.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 May 2022 04:44:19 -0700 (PDT) Date: Sun, 22 May 2022 13:44:18 +0200 From: Luc Van Oostenryck To: Geert Uytterhoeven Cc: Guenter Roeck , kernel test robot , Andrew Morton , linux-staging@lists.linux.dev, "open list:TI ETHERNET SWITCH DRIVER (CPSW)" , linux-nvme@lists.infradead.org, linux-hwmon@vger.kernel.org, Linux Fbdev development list , KVM list , DRI Development , amd-gfx list , Linux Memory Management List , linux-sparse@vger.kernel.org, linux-m68k Subject: Re: [linux-next:master] BUILD REGRESSION 736ee37e2e8eed7fe48d0a37ee5a709514d478b3 Message-ID: <20220522114418.vcirenoehfx4efas@mail> References: <6285958d.+Z2aDZ4O1Y9eiazd%lkp@intel.com> <0530d502-1291-23f3-64ac-97bd38a26bd4@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=HbiWaat1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf30.hostedemail.com: domain of luc.vanoostenryck@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=luc.vanoostenryck@gmail.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 07C0A800D1 X-Stat-Signature: ud8juoenyfqetan3t3bm4zi9987fpoj4 X-HE-Tag: 1653219834-20495 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: On Fri, May 20, 2022 at 02:40:20PM +0200, Geert Uytterhoeven wrote: > Hi Günter > > On Thu, May 19, 2022 at 8:48 AM Guenter Roeck wrote: > > This is getting tiresome. Every driver using outb() on m68k will > > experience that "problem". As far as I can see, it is caused by > > > > #define out_8(addr,b) (void)((*(__force volatile u8 *) (unsigned long)(addr)) = (b)) Not directly related to the root cause but the cast on the LHS is over-complex. *) If the types are correct, 'addr' should always be a 'u8 __iomem *'. Casting it to an unsigned long will throw away all type checking: pointers of any size, of any address space, any kind of integer, any scalar value will be silently be accepted. *) Then, when casting an integer to a pointer '__force' is unneeded because it's meaningless (because the integer has no type info about the pointee). The most correct way to write the above would be: static inline void out_8(u8 __iomem *addr, ... b) { *((__force volatile u8 *)addr) = b; } this way, you can typecheck 'addr' (but maybe it's the idea/the argument is not always type clean?). Otherwise, if the cast to unsigned long is kept, '__force' can be removed. > > Indeed. > > For the sparse people: > > The full error is: > > drivers/net/appletalk/cops.c:382:17: error: incompatible types > in conditional expression (different base types): > drivers/net/appletalk/cops.c:382:17: unsigned char > drivers/net/appletalk/cops.c:382:17: void > > Basically, sparse doesn't like "a ? b : c", if the return types of > b and c don't match, even if the resulting value is not used. Well, you know that the motivation for sparse was to be stricter than GCC. In this case it's simply what is required by the standard: n1570 (C11) 6.5.15 One of the following shall hold for the second and third operands: — both operands have arithmetic type; — both operands have the same structure or union type; — both operands have void type; — both operands are pointers to qualified or unqualified versions of compatible types; — one operand is a pointer and the other is a null pointer constant; or — one operand is a pointer to an object type and the other is a pointer to a qualified or unqualified version of void. Also, yes, the type checking is independent from the fact of being used or not (because the type of an expression must be know before any kind of processing can be done on its value). > E.g. outb() on m68k: > > #define outb(val, port) (((port) < 1024 && ISA_TYPE == > ISA_TYPE_ENEC) ? isa_rom_outb((val), (port)) : isa_outb((val), > (port))) > > where isa_rom_outb() leads to rom_out_8() returning u8, while > isa_outb() leads to the out_8() that includes the cast to void. > > So the best solution seems to be to add more "(void)" casts, to e.g. > rom_out_8() and friends? I kinda think so, yes (I suppose that rom_out_8() is never used as returning a non-void value). But in truth, I think it's the excessive use of relatively complex macros that is the real problem (an using a conditional expression not for its value but for its side-effects). Can't outb() be written as something like: static inline void outb(....) { if (port < 1024 && ISA_TYPE == ISA_TYPE_ENEC) isa_rom_outb(val, port); else isa_outb(val, port); } With this you have better type checking, no trickery, no need for extra casts, no problems with double evaluation, it's more readable (to me), ... But yes, I suppose it's not really simple to convert all this. Sorry for no being more helpful. Best regards, -- Luc