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 9B0D9C433F5 for ; Sat, 7 May 2022 13:14:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1446469AbiEGNS0 (ORCPT ); Sat, 7 May 2022 09:18:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44714 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357403AbiEGNSY (ORCPT ); Sat, 7 May 2022 09:18:24 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6906A4666F; Sat, 7 May 2022 06:14:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2B00BB80833; Sat, 7 May 2022 13:14:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE553C385A9; Sat, 7 May 2022 13:14:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651929274; bh=9uTgmNAvlTbzN50Cu5IwNYqzF7atwTKQUljfe2kjZUc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NYZWIxr7bdtZV5TCcT29L1SoUFnfl0Drt2zM3YTpcRSmzMXOH2zT2baV4RKv/+juu BeDMU08ud7wEyHs+PdV76d+h0FPoWNnkiKsYboYXuD0asYcJpn1MYIybfLSkxaveRD uQQFXFWzr9gQFnG/xPzoBv9obxrCScP/SadNv3PCPo2G03s6CjQbtW7kU30vam9nvR Gf9YIXbw31u1k0y0AlA3If+Fygh/BycEfiWjNZ4jYfFCmNDyTDxL258IRkv/OGg8DJ x/as86QX/Y3tXnRDq/97ZySrx3YSbvxuVWbYl92I7gnkngH5rRb0u87EFe1JeEtcqb h3B3YManvPOXw== Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-2f7d7e3b5bfso105856877b3.5; Sat, 07 May 2022 06:14:34 -0700 (PDT) X-Gm-Message-State: AOAM5324RKs/khNVpfgto0nIU6Tw7t5R03GZYazMMiGH6m4oKC3eUQGE 4aM8eXq+3QcHFlQ8KhlBeB5lY/Q4ExXiQrTN8lU= X-Google-Smtp-Source: ABdhPJxbpJWGFV6icMBoxijo70JK/8WaaDtoVIOoN93PiTf8ADZqw87+hT03oX7HblceCPV66kg3inBF049Gp/XoA2E= X-Received: by 2002:a81:1697:0:b0:2fa:32f9:78c8 with SMTP id 145-20020a811697000000b002fa32f978c8mr6670913yww.135.1651929273816; Sat, 07 May 2022 06:14:33 -0700 (PDT) MIME-Version: 1.0 References: <20220505195342.GA509942@bhelgaas> <22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org> <105ccec439f709846e82b69cb854ac825d7a6a49.camel@linux.ibm.com> <7dfa7578-039-e132-c573-ad89bd3215@linux-m68k.org> In-Reply-To: <7dfa7578-039-e132-c573-ad89bd3215@linux-m68k.org> From: Arnd Bergmann Date: Sat, 7 May 2022 15:14:16 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary To: Finn Thain Cc: Niklas Schnelle , Bjorn Helgaas , Arnd Bergmann , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-arch , linux-pci , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Paul Walmsley , Palmer Dabbelt , Albert Ou , Yoshinori Sato , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "open list:ALPHA PORT" , "moderated list:ARM PORT" , "open list:IA64 (Itanium) PLATFORM" , "open list:M68K ARCHITECTURE" , "open list:MIPS" , "open list:PARISC ARCHITECTURE" , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , "open list:RISC-V ARCHITECTURE" , "open list:SUPERH" , "open list:SPARC + UltraSPARC (sparc/sparc64)" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-sh@vger.kernel.org On Sat, May 7, 2022 at 2:01 AM Finn Thain wrote: > On Fri, 6 May 2022, Niklas Schnelle wrote: > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote: > > > On Thu, 5 May 2022, Bjorn Helgaas wrote: > > > > > > > > I mooted a s390 inb() implementation like "return ~0" because that's > > > > what happens on most arches when there's no device to respond to the > > > > inb(). > > > > > > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter > > > > drivers that use I/O ports in some cases but not others. But maybe > > > > it's the most practical way. > > > > > > > > > > Do you mean, "the most practical way to avoid a compiler warning on > > > s390"? What about "#pragma GCC diagnostic ignored"? > > > > This actually happens with clang. > > That suggests a clang bug to me. If you believe GCC should behave like > clang, then I guess the pragma above really is the one you want. If you > somehow feel that the kernel should cater to gcc and clang even where they > disagree then you would have to use "#pragma clang diagnostic ignored". I don't see how you can blame the compiler for this. On architectures with a zero PCI_IOBASE, an inb(0x2f8) literally becomes var = *(u8*)((NULL + 0x2f8); If you run a driver that does this, the kernel gets a page fault for the NULL page and reports an Oops. clang tells you 'warning: performing pointer arithmetic on a null pointer has undefined behavior', which is not exactly spot on, but close enough to warn you that you probably shouldn't do this. gcc doesn't warn here, but it does warn about an array out-of-bounds access when you pass such a pointer into memcpy or another string function. > > Apart from that, I think this would also fall under the same argument as > > the original patch Linus unpulled. We would just paint over someting > > that we know at compile time won't work: > > > > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/ > > > > I wasn't advocating adding any warnings. > > If you know at compile time that a driver won't work, the usual solution > is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no > longer appropriate for drivers that use IO ports? This was never an option, we rely on 'make allmodconfig' to build without warnings on all architectures for finding regressions. Any driver that depends on architecture specific interfaces must not get selected on architectures that don't have those interfaces. Arnd 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 20441C433F5 for ; Sat, 7 May 2022 13:15:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=lydorKhcVj0U0FgCIe+MSeKcsIk//1KUStOuXcMH8gU=; b=CYb1E/64gCBRS3 2r0FY4eXFBeFkgZaCdF94YGYkCNVSiMTE1yIgnx0cbTqShR2tp4p9to1ucXv7RfHSIrKMk2BlhR8W /JEStLphOsdSoyMKjaUBwWyz070wG9uxWNl7hedf5nLkqQEEaFi6lCCrC+TGRZuQQ9Ejl7kB857fa Ckt2STh8D+gFDKZUAZIFV2bXolZUp8BL8v2HwWUcfTwzOQRlsMXmO8KXuLRhVRAdmSWNrz0ews+fZ mOxyid7m62GaxXc/4wuENtIrVavzfYFlqC8kDA4Cdtuh0C9e4cUZBV4ADXIL9gBGFbKJELxjzgwEd CDz2gkzZ6wgTOGiXlOpw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nnKGy-007FU5-Ao; Sat, 07 May 2022 13:15:00 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nnKGm-007FQu-Hg; Sat, 07 May 2022 13:14:50 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E33CEB80882; Sat, 7 May 2022 13:14:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 216E9C385B1; Sat, 7 May 2022 13:14:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651929285; bh=9uTgmNAvlTbzN50Cu5IwNYqzF7atwTKQUljfe2kjZUc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iDB5qYBiUdSDJDY3O1arHfq2ckrvDBaDIMlb7N58i6l8UufbIQONCWG8ZbwlwTljF KyZo/hhehnk7kRManj/hXE/Xf6ablwp6uaz3H+cBB4vBVPeAgH732SRJbXPv9Dr4k0 S7zoxMWxBPrPYWsEJfLjGVmZbARPc6NzJX2LtXm+eLiMebx1S4KIEnelXP2SHvorOM eK4JRw+FZBI1rgbtWeqvQmurUOzyYr1JkAmvNV2ZlZyNux/dZ4x1R7e4c8ddbBifDP oQqQITpYOOXmUtpX0yuTadeMaMIgc907CguayKPAWLawKbG0wnf2Tss7SLDlp09t3c SAr9UQSbLHl0Q== Received: by mail-yb1-f174.google.com with SMTP id y2so17288749ybi.7; Sat, 07 May 2022 06:14:45 -0700 (PDT) X-Gm-Message-State: AOAM531f/lACT3F4nWFoWNsxrWmZXJV5ehRFFK8liGGqsiOzVHANAhIX GGmHLXdMVA+FH6S1HB8jhz8N1XoW2snKMyI3tyM= X-Google-Smtp-Source: ABdhPJxbpJWGFV6icMBoxijo70JK/8WaaDtoVIOoN93PiTf8ADZqw87+hT03oX7HblceCPV66kg3inBF049Gp/XoA2E= X-Received: by 2002:a81:1697:0:b0:2fa:32f9:78c8 with SMTP id 145-20020a811697000000b002fa32f978c8mr6670913yww.135.1651929273816; Sat, 07 May 2022 06:14:33 -0700 (PDT) MIME-Version: 1.0 References: <20220505195342.GA509942@bhelgaas> <22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org> <105ccec439f709846e82b69cb854ac825d7a6a49.camel@linux.ibm.com> <7dfa7578-039-e132-c573-ad89bd3215@linux-m68k.org> In-Reply-To: <7dfa7578-039-e132-c573-ad89bd3215@linux-m68k.org> From: Arnd Bergmann Date: Sat, 7 May 2022 15:14:16 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary To: Finn Thain Cc: Niklas Schnelle , Bjorn Helgaas , Arnd Bergmann , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-arch , linux-pci , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Paul Walmsley , Palmer Dabbelt , Albert Ou , Yoshinori Sato , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "open list:ALPHA PORT" , "moderated list:ARM PORT" , "open list:IA64 (Itanium) PLATFORM" , "open list:M68K ARCHITECTURE" , "open list:MIPS" , "open list:PARISC ARCHITECTURE" , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , "open list:RISC-V ARCHITECTURE" , "open list:SUPERH" , "open list:SPARC + UltraSPARC (sparc/sparc64)" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220507_061448_907872_14745F05 X-CRM114-Status: GOOD ( 28.27 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Sat, May 7, 2022 at 2:01 AM Finn Thain wrote: > On Fri, 6 May 2022, Niklas Schnelle wrote: > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote: > > > On Thu, 5 May 2022, Bjorn Helgaas wrote: > > > > > > > > I mooted a s390 inb() implementation like "return ~0" because that's > > > > what happens on most arches when there's no device to respond to the > > > > inb(). > > > > > > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter > > > > drivers that use I/O ports in some cases but not others. But maybe > > > > it's the most practical way. > > > > > > > > > > Do you mean, "the most practical way to avoid a compiler warning on > > > s390"? What about "#pragma GCC diagnostic ignored"? > > > > This actually happens with clang. > > That suggests a clang bug to me. If you believe GCC should behave like > clang, then I guess the pragma above really is the one you want. If you > somehow feel that the kernel should cater to gcc and clang even where they > disagree then you would have to use "#pragma clang diagnostic ignored". I don't see how you can blame the compiler for this. On architectures with a zero PCI_IOBASE, an inb(0x2f8) literally becomes var = *(u8*)((NULL + 0x2f8); If you run a driver that does this, the kernel gets a page fault for the NULL page and reports an Oops. clang tells you 'warning: performing pointer arithmetic on a null pointer has undefined behavior', which is not exactly spot on, but close enough to warn you that you probably shouldn't do this. gcc doesn't warn here, but it does warn about an array out-of-bounds access when you pass such a pointer into memcpy or another string function. > > Apart from that, I think this would also fall under the same argument as > > the original patch Linus unpulled. We would just paint over someting > > that we know at compile time won't work: > > > > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/ > > > > I wasn't advocating adding any warnings. > > If you know at compile time that a driver won't work, the usual solution > is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no > longer appropriate for drivers that use IO ports? This was never an option, we rely on 'make allmodconfig' to build without warnings on all architectures for finding regressions. Any driver that depends on architecture specific interfaces must not get selected on architectures that don't have those interfaces. Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F1754C433EF for ; Sat, 7 May 2022 13:15:26 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KwSbd1nnxz3cHs for ; Sat, 7 May 2022 23:15:25 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=iDB5qYBi; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=139.178.84.217; helo=dfw.source.kernel.org; envelope-from=arnd@kernel.org; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=iDB5qYBi; dkim-atps=neutral Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4KwSZw1zPHz3bZC for ; Sat, 7 May 2022 23:14:48 +1000 (AEST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 92AC7611BE for ; Sat, 7 May 2022 13:14:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05179C385A9 for ; Sat, 7 May 2022 13:14:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651929285; bh=9uTgmNAvlTbzN50Cu5IwNYqzF7atwTKQUljfe2kjZUc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iDB5qYBiUdSDJDY3O1arHfq2ckrvDBaDIMlb7N58i6l8UufbIQONCWG8ZbwlwTljF KyZo/hhehnk7kRManj/hXE/Xf6ablwp6uaz3H+cBB4vBVPeAgH732SRJbXPv9Dr4k0 S7zoxMWxBPrPYWsEJfLjGVmZbARPc6NzJX2LtXm+eLiMebx1S4KIEnelXP2SHvorOM eK4JRw+FZBI1rgbtWeqvQmurUOzyYr1JkAmvNV2ZlZyNux/dZ4x1R7e4c8ddbBifDP oQqQITpYOOXmUtpX0yuTadeMaMIgc907CguayKPAWLawKbG0wnf2Tss7SLDlp09t3c SAr9UQSbLHl0Q== Received: by mail-yb1-f172.google.com with SMTP id f38so17353145ybi.3 for ; Sat, 07 May 2022 06:14:44 -0700 (PDT) X-Gm-Message-State: AOAM5320NsZbhTFX0pVz5XzCPRZNzvb3atNnwEsuLUe9s204Yf/oLCgf qrFr+rnG2MoyzY+bXAGp4kR6REBGpesH5jEwpyo= X-Google-Smtp-Source: ABdhPJxbpJWGFV6icMBoxijo70JK/8WaaDtoVIOoN93PiTf8ADZqw87+hT03oX7HblceCPV66kg3inBF049Gp/XoA2E= X-Received: by 2002:a81:1697:0:b0:2fa:32f9:78c8 with SMTP id 145-20020a811697000000b002fa32f978c8mr6670913yww.135.1651929273816; Sat, 07 May 2022 06:14:33 -0700 (PDT) MIME-Version: 1.0 References: <20220505195342.GA509942@bhelgaas> <22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org> <105ccec439f709846e82b69cb854ac825d7a6a49.camel@linux.ibm.com> <7dfa7578-039-e132-c573-ad89bd3215@linux-m68k.org> In-Reply-To: <7dfa7578-039-e132-c573-ad89bd3215@linux-m68k.org> From: Arnd Bergmann Date: Sat, 7 May 2022 15:14:16 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary To: Finn Thain Content-Type: text/plain; charset="UTF-8" X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rich Felker , "open list:IA64 \(Itanium\) PLATFORM" , "open list:SUPERH" , Catalin Marinas , Dave Hansen , "open list:MIPS" , "James E.J. Bottomley" , "open list:SPARC + UltraSPARC \(sparc/sparc64\)" , "open list:RISC-V ARCHITECTURE" , Will Deacon , linux-arch , Yoshinori Sato , Helge Deller , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , Russell King , Ingo Molnar , Geert Uytterhoeven , linux-pci , Bjorn Helgaas , Matt Turner , Albert Ou , Arnd Bergmann , Niklas Schnelle , "open list:M68K ARCHITECTURE" , Ivan Kokshaysky , Paul Walmsley , Thomas Gleixner , "moderated list:ARM PORT" , Richard Henderson , Michal Simek , Thomas Bogendoerfer , "open list:PARISC ARCHITECTURE" , Greg Kroah-Hartman , Linux Kernel Mailing List , Palmer Dabbelt , "open list:ALPHA PORT" , Borislav Petkov , "open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)" , "David S. Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Sat, May 7, 2022 at 2:01 AM Finn Thain wrote: > On Fri, 6 May 2022, Niklas Schnelle wrote: > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote: > > > On Thu, 5 May 2022, Bjorn Helgaas wrote: > > > > > > > > I mooted a s390 inb() implementation like "return ~0" because that's > > > > what happens on most arches when there's no device to respond to the > > > > inb(). > > > > > > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter > > > > drivers that use I/O ports in some cases but not others. But maybe > > > > it's the most practical way. > > > > > > > > > > Do you mean, "the most practical way to avoid a compiler warning on > > > s390"? What about "#pragma GCC diagnostic ignored"? > > > > This actually happens with clang. > > That suggests a clang bug to me. If you believe GCC should behave like > clang, then I guess the pragma above really is the one you want. If you > somehow feel that the kernel should cater to gcc and clang even where they > disagree then you would have to use "#pragma clang diagnostic ignored". I don't see how you can blame the compiler for this. On architectures with a zero PCI_IOBASE, an inb(0x2f8) literally becomes var = *(u8*)((NULL + 0x2f8); If you run a driver that does this, the kernel gets a page fault for the NULL page and reports an Oops. clang tells you 'warning: performing pointer arithmetic on a null pointer has undefined behavior', which is not exactly spot on, but close enough to warn you that you probably shouldn't do this. gcc doesn't warn here, but it does warn about an array out-of-bounds access when you pass such a pointer into memcpy or another string function. > > Apart from that, I think this would also fall under the same argument as > > the original patch Linus unpulled. We would just paint over someting > > that we know at compile time won't work: > > > > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/ > > > > I wasn't advocating adding any warnings. > > If you know at compile time that a driver won't work, the usual solution > is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no > longer appropriate for drivers that use IO ports? This was never an option, we rely on 'make allmodconfig' to build without warnings on all architectures for finding regressions. Any driver that depends on architecture specific interfaces must not get selected on architectures that don't have those interfaces. Arnd 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2DBF2C433EF for ; Sat, 7 May 2022 13:15:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5iLnCfDdTcvEwUjZ8CjH03y/VxAuDhHfndPG8SHKAR4=; b=CzYgvpVaaGoPjh 5GV41qZJtYeMFE8/8D7RhHuR/Zkiebe3P1rirEYV8mwrzpmo2zr8vBWNy50r+ZfxhTAVhC52U+Wwb fp+itNFKpEyi4YV5AzSvZrBCh5cSdOJ3pp8EDibNGJDHioWY5oicBY664ClxyNV5C8ve3Tnbt4QWn N2G3+fvNgF5xP/gvm4VQQFYRG4DvvdUePHPSI/AszOK0fndFrebJTQykfHY7wadYtdyPo2vCbIpHg Vgg3jPCutesj6lmrvaOYWnkxEfRZ2lOVJK22Sld0jXL3yGOSmiYdNECA7v+umT8mnCkREe4h4WhPt 8RjB9/k4Gg1b27zpXzbA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nnKGp-007FRz-MO; Sat, 07 May 2022 13:14:51 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nnKGm-007FQu-Hg; Sat, 07 May 2022 13:14:50 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E33CEB80882; Sat, 7 May 2022 13:14:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 216E9C385B1; Sat, 7 May 2022 13:14:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651929285; bh=9uTgmNAvlTbzN50Cu5IwNYqzF7atwTKQUljfe2kjZUc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=iDB5qYBiUdSDJDY3O1arHfq2ckrvDBaDIMlb7N58i6l8UufbIQONCWG8ZbwlwTljF KyZo/hhehnk7kRManj/hXE/Xf6ablwp6uaz3H+cBB4vBVPeAgH732SRJbXPv9Dr4k0 S7zoxMWxBPrPYWsEJfLjGVmZbARPc6NzJX2LtXm+eLiMebx1S4KIEnelXP2SHvorOM eK4JRw+FZBI1rgbtWeqvQmurUOzyYr1JkAmvNV2ZlZyNux/dZ4x1R7e4c8ddbBifDP oQqQITpYOOXmUtpX0yuTadeMaMIgc907CguayKPAWLawKbG0wnf2Tss7SLDlp09t3c SAr9UQSbLHl0Q== Received: by mail-yb1-f174.google.com with SMTP id y2so17288749ybi.7; Sat, 07 May 2022 06:14:45 -0700 (PDT) X-Gm-Message-State: AOAM531f/lACT3F4nWFoWNsxrWmZXJV5ehRFFK8liGGqsiOzVHANAhIX GGmHLXdMVA+FH6S1HB8jhz8N1XoW2snKMyI3tyM= X-Google-Smtp-Source: ABdhPJxbpJWGFV6icMBoxijo70JK/8WaaDtoVIOoN93PiTf8ADZqw87+hT03oX7HblceCPV66kg3inBF049Gp/XoA2E= X-Received: by 2002:a81:1697:0:b0:2fa:32f9:78c8 with SMTP id 145-20020a811697000000b002fa32f978c8mr6670913yww.135.1651929273816; Sat, 07 May 2022 06:14:33 -0700 (PDT) MIME-Version: 1.0 References: <20220505195342.GA509942@bhelgaas> <22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org> <105ccec439f709846e82b69cb854ac825d7a6a49.camel@linux.ibm.com> <7dfa7578-039-e132-c573-ad89bd3215@linux-m68k.org> In-Reply-To: <7dfa7578-039-e132-c573-ad89bd3215@linux-m68k.org> From: Arnd Bergmann Date: Sat, 7 May 2022 15:14:16 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary To: Finn Thain Cc: Niklas Schnelle , Bjorn Helgaas , Arnd Bergmann , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-arch , linux-pci , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Paul Walmsley , Palmer Dabbelt , Albert Ou , Yoshinori Sato , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "open list:ALPHA PORT" , "moderated list:ARM PORT" , "open list:IA64 (Itanium) PLATFORM" , "open list:M68K ARCHITECTURE" , "open list:MIPS" , "open list:PARISC ARCHITECTURE" , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , "open list:RISC-V ARCHITECTURE" , "open list:SUPERH" , "open list:SPARC + UltraSPARC (sparc/sparc64)" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220507_061448_907872_14745F05 X-CRM114-Status: GOOD ( 28.27 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, May 7, 2022 at 2:01 AM Finn Thain wrote: > On Fri, 6 May 2022, Niklas Schnelle wrote: > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote: > > > On Thu, 5 May 2022, Bjorn Helgaas wrote: > > > > > > > > I mooted a s390 inb() implementation like "return ~0" because that's > > > > what happens on most arches when there's no device to respond to the > > > > inb(). > > > > > > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter > > > > drivers that use I/O ports in some cases but not others. But maybe > > > > it's the most practical way. > > > > > > > > > > Do you mean, "the most practical way to avoid a compiler warning on > > > s390"? What about "#pragma GCC diagnostic ignored"? > > > > This actually happens with clang. > > That suggests a clang bug to me. If you believe GCC should behave like > clang, then I guess the pragma above really is the one you want. If you > somehow feel that the kernel should cater to gcc and clang even where they > disagree then you would have to use "#pragma clang diagnostic ignored". I don't see how you can blame the compiler for this. On architectures with a zero PCI_IOBASE, an inb(0x2f8) literally becomes var = *(u8*)((NULL + 0x2f8); If you run a driver that does this, the kernel gets a page fault for the NULL page and reports an Oops. clang tells you 'warning: performing pointer arithmetic on a null pointer has undefined behavior', which is not exactly spot on, but close enough to warn you that you probably shouldn't do this. gcc doesn't warn here, but it does warn about an array out-of-bounds access when you pass such a pointer into memcpy or another string function. > > Apart from that, I think this would also fall under the same argument as > > the original patch Linus unpulled. We would just paint over someting > > that we know at compile time won't work: > > > > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/ > > > > I wasn't advocating adding any warnings. > > If you know at compile time that a driver won't work, the usual solution > is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no > longer appropriate for drivers that use IO ports? This was never an option, we rely on 'make allmodconfig' to build without warnings on all architectures for finding regressions. Any driver that depends on architecture specific interfaces must not get selected on architectures that don't have those interfaces. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Date: Sat, 07 May 2022 13:14:16 +0000 Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary Message-Id: List-Id: References: <20220505195342.GA509942@bhelgaas> <22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org> <105ccec439f709846e82b69cb854ac825d7a6a49.camel@linux.ibm.com> <7dfa7578-039-e132-c573-ad89bd3215@linux-m68k.org> In-Reply-To: <7dfa7578-039-e132-c573-ad89bd3215@linux-m68k.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Finn Thain Cc: Niklas Schnelle , Bjorn Helgaas , Arnd Bergmann , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-arch , linux-pci , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael Ellerman , Paul Walmsley , Palmer Dabbelt , Albert Ou , Yoshinori Sato , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "open list:ALPHA PORT" , "moderated list:ARM PORT" , "open list:IA64 (Itanium) PLATFORM" , "open list:M68K ARCHITECTURE" , "open list:MIPS" , "open list:PARISC ARCHITECTURE" , "open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)" , "open list:RISC-V ARCHITECTURE" , "open list:SUPERH" , "open list:SPARC + UltraSPARC (sparc/sparc64)" On Sat, May 7, 2022 at 2:01 AM Finn Thain wrote: > On Fri, 6 May 2022, Niklas Schnelle wrote: > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote: > > > On Thu, 5 May 2022, Bjorn Helgaas wrote: > > > > > > > > I mooted a s390 inb() implementation like "return ~0" because that's > > > > what happens on most arches when there's no device to respond to the > > > > inb(). > > > > > > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter > > > > drivers that use I/O ports in some cases but not others. But maybe > > > > it's the most practical way. > > > > > > > > > > Do you mean, "the most practical way to avoid a compiler warning on > > > s390"? What about "#pragma GCC diagnostic ignored"? > > > > This actually happens with clang. > > That suggests a clang bug to me. If you believe GCC should behave like > clang, then I guess the pragma above really is the one you want. If you > somehow feel that the kernel should cater to gcc and clang even where they > disagree then you would have to use "#pragma clang diagnostic ignored". I don't see how you can blame the compiler for this. On architectures with a zero PCI_IOBASE, an inb(0x2f8) literally becomes var = *(u8*)((NULL + 0x2f8); If you run a driver that does this, the kernel gets a page fault for the NULL page and reports an Oops. clang tells you 'warning: performing pointer arithmetic on a null pointer has undefined behavior', which is not exactly spot on, but close enough to warn you that you probably shouldn't do this. gcc doesn't warn here, but it does warn about an array out-of-bounds access when you pass such a pointer into memcpy or another string function. > > Apart from that, I think this would also fall under the same argument as > > the original patch Linus unpulled. We would just paint over someting > > that we know at compile time won't work: > > > > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/ > > > > I wasn't advocating adding any warnings. > > If you know at compile time that a driver won't work, the usual solution > is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no > longer appropriate for drivers that use IO ports? This was never an option, we rely on 'make allmodconfig' to build without warnings on all architectures for finding regressions. Any driver that depends on architecture specific interfaces must not get selected on architectures that don't have those interfaces. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary Date: Sat, 7 May 2022 15:14:16 +0200 Message-ID: References: <20220505195342.GA509942@bhelgaas> <22bec167-241f-2cbe-829f-a3f65e40e71@linux-m68k.org> <105ccec439f709846e82b69cb854ac825d7a6a49.camel@linux.ibm.com> <7dfa7578-039-e132-c573-ad89bd3215@linux-m68k.org> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651929274; bh=9uTgmNAvlTbzN50Cu5IwNYqzF7atwTKQUljfe2kjZUc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=NYZWIxr7bdtZV5TCcT29L1SoUFnfl0Drt2zM3YTpcRSmzMXOH2zT2baV4RKv/+juu BeDMU08ud7wEyHs+PdV76d+h0FPoWNnkiKsYboYXuD0asYcJpn1MYIybfLSkxaveRD uQQFXFWzr9gQFnG/xPzoBv9obxrCScP/SadNv3PCPo2G03s6CjQbtW7kU30vam9nvR Gf9YIXbw31u1k0y0AlA3If+Fygh/BycEfiWjNZ4jYfFCmNDyTDxL258IRkv/OGg8DJ x/as86QX/Y3tXnRDq/97ZySrx3YSbvxuVWbYl92I7gnkngH5rRb0u87EFe1JeEtcqb h3B3YManvPOXw== In-Reply-To: <7dfa7578-039-e132-c573-ad89bd3215@linux-m68k.org> List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Finn Thain Cc: Niklas Schnelle , Bjorn Helgaas , Arnd Bergmann , Greg Kroah-Hartman , Linux Kernel Mailing List , linux-arch , linux-pci , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Michal Simek , Thomas Bogendoerfer , "James E.J. Bottomley" , Helge Deller , Michael On Sat, May 7, 2022 at 2:01 AM Finn Thain wrote: > On Fri, 6 May 2022, Niklas Schnelle wrote: > > On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote: > > > On Thu, 5 May 2022, Bjorn Helgaas wrote: > > > > > > > > I mooted a s390 inb() implementation like "return ~0" because that's > > > > what happens on most arches when there's no device to respond to the > > > > inb(). > > > > > > > > The HAS_IOPORT dependencies are fairly ugly IMHO, and they clutter > > > > drivers that use I/O ports in some cases but not others. But maybe > > > > it's the most practical way. > > > > > > > > > > Do you mean, "the most practical way to avoid a compiler warning on > > > s390"? What about "#pragma GCC diagnostic ignored"? > > > > This actually happens with clang. > > That suggests a clang bug to me. If you believe GCC should behave like > clang, then I guess the pragma above really is the one you want. If you > somehow feel that the kernel should cater to gcc and clang even where they > disagree then you would have to use "#pragma clang diagnostic ignored". I don't see how you can blame the compiler for this. On architectures with a zero PCI_IOBASE, an inb(0x2f8) literally becomes var = *(u8*)((NULL + 0x2f8); If you run a driver that does this, the kernel gets a page fault for the NULL page and reports an Oops. clang tells you 'warning: performing pointer arithmetic on a null pointer has undefined behavior', which is not exactly spot on, but close enough to warn you that you probably shouldn't do this. gcc doesn't warn here, but it does warn about an array out-of-bounds access when you pass such a pointer into memcpy or another string function. > > Apart from that, I think this would also fall under the same argument as > > the original patch Linus unpulled. We would just paint over someting > > that we know at compile time won't work: > > > > https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/ > > > > I wasn't advocating adding any warnings. > > If you know at compile time that a driver won't work, the usual solution > is scripts/config -d CONFIG_SOME_UNDESIRED_DRIVER. Why is that no > longer appropriate for drivers that use IO ports? This was never an option, we rely on 'make allmodconfig' to build without warnings on all architectures for finding regressions. Any driver that depends on architecture specific interfaces must not get selected on architectures that don't have those interfaces. Arnd