Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1059976pxm; Wed, 23 Feb 2022 17:05:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJzo/p2i47ObDTOnanf61tyLEumYDMDkrjvvF4bMYmsSz8XS9qs7P7bNjq8TnxQCBod0KNny X-Received: by 2002:a05:6a00:a8b:b0:4e1:52db:9e5c with SMTP id b11-20020a056a000a8b00b004e152db9e5cmr175844pfl.38.1645664717665; Wed, 23 Feb 2022 17:05:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645664717; cv=none; d=google.com; s=arc-20160816; b=thOuFmYF7Sa/JteJU2o7yBwFziph0mMUXsg3DSr17dFZKV6jfLsK/ikKBGfZxGfEVY PUT7r+SSQDB6RlT46w9vWbzyyiMlFl1fBldEiqKG2sy4tqMjNNMriIg5BEWwS1mZdnUs +za5OeAOyp5IrZmqeGV6MqUdt8kOvVcAk0lckgeVLLPmEPnHnpBlPJ4iB1oj9JCkvyhB bgP6ZP56qzXKcbWGZfrq2nbZDEFKp6r5/vl7wGBBZRXg+svEgDaQvBDHbBCf5pJoZeei 4k9soGrrFblIwnYJnfByawGRMhBN90cEd10s8rVUOc7PV4pu4YLAl75KOr0+vVqwQ8l5 Rjog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=8cwho/4LFeXhHXL7I5hRo8DyKgG2IPJibL63s7HKT04=; b=0GTLRFZzi2JnXRlOpF5vx+kFxElftki1IUUxtsp8NwL8OUpfe5524v96g3WZBhvwI7 d/MytE0gC2Z6KGLyrnRRvV8vIj6WMwBH+9Z5dbHcD52Hq/gTUpsrvSXme2QJ0bjRlOxU ao7JrlY37TvKFscQ/bzbl1fcGgekODGfcHBAI4kCINud6WqJn88Brabvehb0CT/+kFCN VgUqIrPoESdT3quFJYGx0FrDIz4Irs/wKzZkxn7p+fMQw80iM9M4kLctql+VROanbdTh oydxBW8PLB5PQdlmpJKWBhOKFW5sWNkNGrTDPoMMH0QvUHxuOpehDEsPTX0UPNNjwrNM 0MTw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id k125si1023529pgc.182.2022.02.23.17.05.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Feb 2022 17:05:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id F3FD314892D; Wed, 23 Feb 2022 16:55:16 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241105AbiBWUZh (ORCPT + 99 others); Wed, 23 Feb 2022 15:25:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51202 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235991AbiBWUZg (ORCPT ); Wed, 23 Feb 2022 15:25:36 -0500 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0ECAB4D620; Wed, 23 Feb 2022 12:25:05 -0800 (PST) Received: from mail-wm1-f50.google.com ([209.85.128.50]) by mrelayeu.kundenserver.de (mreue012 [213.165.67.97]) with ESMTPSA (Nemesis) id 1MOV26-1naljC1Dg6-00PswW; Wed, 23 Feb 2022 21:25:04 +0100 Received: by mail-wm1-f50.google.com with SMTP id d14-20020a05600c34ce00b0037bf4d14dc7so31673wmq.3; Wed, 23 Feb 2022 12:25:04 -0800 (PST) X-Gm-Message-State: AOAM532Hhopo/vBy3TmiOBpaRgXvM2UjODSoa/dPYObvgEusiEOcONLh wuyYBgLKkO2YVHKzGEgQ0KZ5cAkClE4MVvr0h+Y= X-Received: by 2002:a7b:c191:0:b0:37b:b7e3:b930 with SMTP id y17-20020a7bc191000000b0037bb7e3b930mr1072095wmi.35.1645647903930; Wed, 23 Feb 2022 12:25:03 -0800 (PST) MIME-Version: 1.0 References: <20220217184829.1991035-1-jakobkoschel@gmail.com> <20220217184829.1991035-4-jakobkoschel@gmail.com> <6DFD3D91-B82C-469C-8771-860C09BD8623@gmail.com> In-Reply-To: From: Arnd Bergmann Date: Wed, 23 Feb 2022 21:24:47 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 03/13] usb: remove the usage of the list iterator after the loop To: Linus Torvalds Cc: Jakob , Arnd Bergmann , Linux Kernel Mailing List , linux-arch , Greg Kroah-Hartman , Thomas Gleixner , Andy Shevchenko , Andrew Morton , Kees Cook , Mike Rapoport , "Gustavo A. R. Silva" , Brian Johannesmeyer , Cristiano Giuffrida , "Bos, H.J." Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:Jfe1X4m3h3tLbwktyEGuP94khgBT4Wep+vQx1J8+N3UW/OG0iEt vOJrR1p/9DWiu2YmBzYlPQprR4I+LxucIyTfu/EMsf/+vDjstIkoUAk3HsrBrGGiG8vDMRF N2wltb7ExuffaVgjrfbngQ5+/dHd1DxiTCyoIPQ/tb8LKZd1ixhx5BP1lCKAA+oOcQEgux2 4Z4aYDXbpyqGvaM6KZiJg== X-UI-Out-Filterresults: notjunk:1;V03:K0:svdb5o9ahQg=:qV8URQj9Nw2LISLKh2X1FV FrMHvXagSGQbEUxGNyv7vzDUryk2IWUGHe2frVBEvFugjiekwEwk1o+JaGGFNpwkeDjCJRbj0 Qh0KNiRxKcjDqq2ynyURd+w8hvNyLMd7/N3EiuoyjKn5pVSJUU/cNPK7pNs+zngQWofLO6AAa biafejziO4yp34dzf48QnrjHRg7wZjxso/Zn8Q4eH7Dt5YCKwHeQupDVL+DVo34Hm4ZwezEkn W8ZcqjnI/W3FY5FRvyBvLBVOYLzhoS+0W29uPhW48h5VhmGanVBUbFLNLKjuTczf1DLJkFoHZ V9Om8G+xK+NQFRaNlSmRTDVnaRk8pSLe9ebhgqHSCWLqOGTTr/oc9eFKJBfaqBuS9Icyjt5jN 3hQB9AI+bcS5tqW8m9nu7FPbaxossYeiq97ixmqvNM8lJKmQRZ/Fn69UZcW3R4NIBkwWAUvHm I0C3xCAhs+U7Tqb67jkgRkxJJUj+p39cfdflu4k16Tf/d2RZ1Nmf0qKJdLJQjQLcoDgWdJFjZ +1NGY5McKOCkcM79aPkz5OVc5ewxOJ7FleW0sIazWJC1zMyf+SCZZ5nRAtm//tuMzAg2WtVbQ fsmjJslOtrW0kxbA9VUb1aAmvHE5oy+C3g9p7LEFxOvBFRYFCul6YJJuoKqUIendshO0xMa76 DPhmi7QEYsKLjDjopVGMtavX+EqSqWdyug0dzs9BTFqY39FrCqiTHNnZXzC0cNip4o1Q= X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 23, 2022 at 8:23 PM Linus Torvalds wrote: > > On Wed, Feb 23, 2022 at 10:47 AM Linus Torvalds > wrote: > > > > Arnd - remind me, please.. Was there some other problem than just gcc-4.9? I'm pretty sure this was the only thing. And not even because gcc-4.9 didn't support later standards, but because it caused some false-postivee warnings like In file included from ../drivers/usb/core/notify.c:16:0: ../include/linux/notifier.h:117:9: error: initializer element is not constant struct blocking_notifier_head name = \ ^ ../drivers/usb/core/notify.c:21:8: note: in expansion of macro 'BLOCKING_NOTIFIER_HEAD' static BLOCKING_NOTIFIER_HEAD(usb_notifier_list); ^ ../include/linux/notifier.h:117:9: error: (near initialization for 'usb_notifier_list.rwsem.wait_lock') struct blocking_notifier_head name = \ ^ ../drivers/usb/core/notify.c:21:8: note: in expansion of macro 'BLOCKING_NOTIFIER_HEAD' static BLOCKING_NOTIFIER_HEAD(usb_notifier_list); ^ > Hmm. Interesting. I decided to just try it and see for the compiler I > have, and changing the gnu89 to gnu99 I get new warnings > (-Werror=shift-negative-value). FWIW, I think we can go straight to gnu11 in this case even with gcc-5, no need to take gnu99 as an intermediate step. I don't know if there is a practical difference between the two though. gcc-8 and higher also support --std=gnu18 and --std=gnu2x, which also work for building the kernel but would break gcc-5/6/7 support > Very annoying. Especially since negative values are in many contexts > actually *safer* than positive ones when used as a mask, because as > long as the top bit is set in 'int', if the end result is then > expanded to some wider type, the top bit stays set. > > Example: > > unsigned long mask(unsigned long x) > { return x & (~0 << 5); } > > unsigned long badmask(unsigned long x) > { return x & (~0u << 5); } > > One does it properly, the other is buggy. > > Now, with an explicit "unsigned long" like this, some clueless > compiler person might say "just use "~0ul", but that's completely > wrong - because quite often the type is *not* this visible, and the > signed version works *regardless* of type. > > So this Werror=shift-negative-value warning seems to be actively > detrimental, and I'm not seeing the reason for it. Can somebody > explain the thinking for that stupid warning? > > That said, we seem to only have two cases of it in the kernel, at > least by a x86-64 allmodconfig build. So we could examine the types > there, or we could just add '-Wno-shift-negative-value". I looked at the gcc documentation for this flag, and it tells me that it's default-enabled for std=c99 or higher. Turning it on for --std=gnu89 shows the same warning, so at least it doesn't sound like the actual behavior changed, only the warning output. clang does not warn for this code at all, regardless of the --std= flag. Arnd