Message ID | 20230623152443.2296825-1-arnd@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp5876115vqr; Fri, 23 Jun 2023 09:00:33 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4b62RUmRnAu46kX4cKywF/2v+P7uamzLKmi8x2VdrtFgmUL6do+kg7bCFWrluIprMcAMrZ X-Received: by 2002:a05:6a20:7346:b0:100:15c4:23af with SMTP id v6-20020a056a20734600b0010015c423afmr12780026pzc.60.1687536033377; Fri, 23 Jun 2023 09:00:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687536033; cv=none; d=google.com; s=arc-20160816; b=eX2ydlnMz/GgX8USXmUPq5EJMDX8B5t8QMSzGxSNa3016brUdPWacRWC6YiftRp68i FRppPP9dHnp6THzAq9W4OjBpOGTl9K2v871+Pg0HbN4Q7Ky/OnBt6aWTYe0uqqWaQ+AM xk/6lLe+gVy+i4yTgEnJXCUnQJ9lR2esfOdFKPanj3Y5ZGRuGxCn87qI4Mcy6RXRDqTb UBhIR+bDbEGB8MwDAZcU9R+jl2HhMC+yeFGJ0sXR06+CXaDHUyqvN73/YeqVzdsljmoe lwpGOZU9dbEnvD3Sx/GQEag5M54urSaE7fESLRKW7y7QYv4IzIoCULdtRTnnxDoxhyEi TCUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=coFgCqOTB8MvClb8Nls3IHBhJBMCfDPdOvFaoOpq31w=; b=OCGbpvgFyPr+azlLspagmuO8xUE3DOwbmJrGUJkl7LlbRY7S0XG2MfMqEzQTmaMG8y OYQ+MfjU0tAm2qCcCtXgoXwfzYuh53vn8hYKU4CtXowR/u/gsWjx3SW7OAJm6vOfcIiw qSwl28aYHCCJaZ3xN6P6xBYaBmbyHuej3oL+X9Pxf25RxB8KORNyo7j/8zo+sfLH2xfg 3iC1mvnMks9ethP9pNK3iw5GpPNswApL4zv1J2/aCkTHANnVqT8OHfvUw6l0EEYIZHtc XApFYV2s1dLB+XeNudycyXcPJE7X6+F+KU2VSiQ4c9inX6QOit9dWJxnwz+iXZqnyTEB IG6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=P5hRm+79; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p6-20020a625b06000000b00666acab17acsi2469317pfb.318.2023.06.23.09.00.16; Fri, 23 Jun 2023 09:00:33 -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=@kernel.org header.s=k20201202 header.b=P5hRm+79; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232367AbjFWPZO (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Fri, 23 Jun 2023 11:25:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232211AbjFWPZN (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 23 Jun 2023 11:25:13 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 313621BF2; Fri, 23 Jun 2023 08:25:12 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B7A2761AA0; Fri, 23 Jun 2023 15:25:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 730FFC433C8; Fri, 23 Jun 2023 15:25:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687533911; bh=PWzWmQ+cBgJK6M6TA5MtMDmO0z6eE5AOkMWX2YVaO2k=; h=From:To:Cc:Subject:Date:From; b=P5hRm+79D+2sZ4kgfzfW91OywrM3XnOisdudNi2GlRMtyg5UH0fJKk2zIoCvyQc0P OwxUG8xC5hN6tuNUjuWTNRak3gq/OOfYS97/iZCng3xsnGxJBupj1nQL4aFhvctmTl augdY8OVO3DMh8cmyA8rxuEBFe/VRRgZQOTlmPsUAmYmcvKAUXHz+EIfDEAFO5yorG jOArBFZOJ+JaLhy4odrlwAyqdOyzmGfQemDAzuZZPVMFdSw6hqjMbX4XQiLJ8l/Zjj z3IgMXZdxB3oDlwbQ0XHp6Lf1srAPR+fS7bEartCAlVGgVq1o5ryKAW6kT7e8BK7jn CoDA9RnFTW+uA== From: Arnd Bergmann <arnd@kernel.org> To: Christian Lamparter <chunkeey@googlemail.com>, Kalle Valo <kvalo@kernel.org>, Kees Cook <keescook@chromium.org>, Johannes Berg <johannes.berg@intel.com> Cc: Arnd Bergmann <arnd@arndb.de>, linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/2] carl9170: re-fix fortified-memset warning Date: Fri, 23 Jun 2023 17:23:59 +0200 Message-Id: <20230623152443.2296825-1-arnd@kernel.org> X-Mailer: git-send-email 2.39.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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?1769509784157164358?= X-GMAIL-MSGID: =?utf-8?q?1769509784157164358?= |
Series |
[1/2] carl9170: re-fix fortified-memset warning
|
|
Commit Message
Arnd Bergmann
June 23, 2023, 3:23 p.m. UTC
From: Arnd Bergmann <arnd@arndb.de> The carl9170_tx_release() function sometimes triggers a fortified-memset warning in my randconfig builds: In file included from include/linux/string.h:254, from drivers/net/wireless/ath/carl9170/tx.c:40: In function 'fortify_memset_chk', inlined from 'carl9170_tx_release' at drivers/net/wireless/ath/carl9170/tx.c:283:2, inlined from 'kref_put' at include/linux/kref.h:65:3, inlined from 'carl9170_tx_put_skb' at drivers/net/wireless/ath/carl9170/tx.c:342:9: include/linux/fortify-string.h:493:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 493 | __write_overflow_field(p_size_field, size); Kees previously tried to avoid this by using memset_after(), but it seems this does not fully address the problem. I noticed that the memset_after() here is done on a different part of the union (status) than the original cast was from (rate_driver_data), which may confuse the compiler. Unfortunately, the memset_after() trick does not work on driver_rates[] because that is part of an anonymous struct, and I could not get struct_group() to do this either. Using two separate memset() calls on the two members does address the warning though. Fixes: fb5f6a0e8063b ("mac80211: Use memset_after() to clear tx status") Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/net/wireless/ath/carl9170/tx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Comments
On 6/23/23 17:23, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > The carl9170_tx_release() function sometimes triggers a fortified-memset > warning in my randconfig builds: > > In file included from include/linux/string.h:254, > from drivers/net/wireless/ath/carl9170/tx.c:40: > In function 'fortify_memset_chk', > inlined from 'carl9170_tx_release' at drivers/net/wireless/ath/carl9170/tx.c:283:2, > inlined from 'kref_put' at include/linux/kref.h:65:3, > inlined from 'carl9170_tx_put_skb' at drivers/net/wireless/ath/carl9170/tx.c:342:9: > include/linux/fortify-string.h:493:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] > 493 | __write_overflow_field(p_size_field, size); > > Kees previously tried to avoid this by using memset_after(), but it seems > this does not fully address the problem. I noticed that the memset_after() > here is done on a different part of the union (status) than the original > cast was from (rate_driver_data), which may confuse the compiler. > > Unfortunately, the memset_after() trick does not work on driver_rates[] > because that is part of an anonymous struct, and I could not get > struct_group() to do this either. Using two separate memset() calls > on the two members does address the warning though. > > Fixes: fb5f6a0e8063b ("mac80211: Use memset_after() to clear tx status") > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Wait! I want to point out this funny thing is happening in ath too! https://lore.kernel.org/linux-wireless/TYAP286MB03154F9AAFD4C35BEEDE4A99BC4CA@TYAP286MB0315.JPNP286.PROD.OUTLOOK.COM/T/#mf1b8919a000fe661803c17073f48b3c410888541 And that patch got NACK by Jiri Slaby because like me he suspects that this is a compiler bug. so, what's going wrong with fortified there? Thanks, Christian
On Fri, Jun 23, 2023, at 17:38, Christian Lamparter wrote: > On 6/23/23 17:23, Arnd Bergmann wrote: > > Wait! I want to point out this funny thing is happening in ath too! > > https://lore.kernel.org/linux-wireless/TYAP286MB03154F9AAFD4C35BEEDE4A99BC4CA@TYAP286MB0315.JPNP286.PROD.OUTLOOK.COM/T/#mf1b8919a000fe661803c17073f48b3c410888541 > > And that patch got NACK by Jiri Slaby because like me he suspects that > this is a compiler bug. FWIW, that is one I don't see with clang-17 or gcc-13. The one I'm addressing here is the only thing I see in ath wireless with the default set of warning options, though this driver does have a couple of others that are unrelated, when you enable the source data check in memcpy() by building with W=1. In file included from drivers/net/wireless/ath/ath9k/xmit.c:17: In file included from include/linux/dma-mapping.h:7: In file included from include/linux/string.h:254: /home/arnd/arm-soc/include/linux/fortify-string.h:592:4: error: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] __read_overflow2_field(q_size_field, size); ^ include/linux/fortify-string.h:592:4: error: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] 2 errors generated. /home/arnd/arm-soc/include/linux/fortify-string.h:592:4: error: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] __read_overflow2_field(q_size_field, size); > so, what's going wrong with fortified there? Kees might have a better answer to that, my best guess is that the one I'm addressing stems from the confusion between different union members. Doing the randconfig builds with the latest compilers, carl9170 is the only one I see with fortified-string warnings, and there are a few dozen other drivers that I see with W=1, including one that affects all wireless drivers. Arnd
On 6/23/23 18:05, Arnd Bergmann wrote: > On Fri, Jun 23, 2023, at 17:38, Christian Lamparter wrote: >> On 6/23/23 17:23, Arnd Bergmann wrote: >> >> Wait! I want to point out this funny thing is happening in ath too! >> >> https://lore.kernel.org/linux-wireless/TYAP286MB03154F9AAFD4C35BEEDE4A99BC4CA@TYAP286MB0315.JPNP286.PROD.OUTLOOK.COM/T/#mf1b8919a000fe661803c17073f48b3c410888541 >> >> And that patch got NACK by Jiri Slaby because like me he suspects that >> this is a compiler bug. > > FWIW, that is one I don't see with clang-17 or gcc-13. The one I'm addressing > here is the only thing I see in ath wireless with the default set of > warning options, though this driver does have a couple of others that > are unrelated, when you enable the source data check in memcpy() by > building with W=1. > > In file included from drivers/net/wireless/ath/ath9k/xmit.c:17: > In file included from include/linux/dma-mapping.h:7: > In file included from include/linux/string.h:254: > /home/arnd/arm-soc/include/linux/fortify-string.h:592:4: error: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] > __read_overflow2_field(q_size_field, size); > ^ > include/linux/fortify-string.h:592:4: error: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] > 2 errors generated. > /home/arnd/arm-soc/include/linux/fortify-string.h:592:4: error: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] > __read_overflow2_field(q_size_field, size); > >> so, what's going wrong with fortified there? > > Kees might have a better answer to that, my best guess is that > the one I'm addressing stems from the confusion between different > union members. > > Doing the randconfig builds with the latest compilers, carl9170 is the > only one I see with fortified-string warnings, and there are a few > dozen other drivers that I see with W=1, including one that affects > all wireless drivers. Hm, question here (to Jiri as well). Do you think that a workaround patch for these sort-of-obvious-but-compiler-bug-but-failed-to-make-a-simple-reproducer would be OK to get NACKed? In my case, I fiddled around with it and replaced the the cc_ani memset in the following way: | memset(&common->cc_survey, 0, sizeof(common->cc_survey)); |- memset(&common->cc_ani, 0, sizeof(common->cc_ani)); |+ common->cc_ani.cycles = common->cc_ani.rx_busy = common->cc_ani.rx_frame = common->cc_ani.tx_frame = 0; (Note here: cc_survey and cc_ani are of the same struct ath_cycle_counters! and they are right next to each other! Even better: reordering the memset in the code does not help. Reordering it in the ath_common does!) This is less intrusive since it only replaces one line... but I'm afraid it too will get flagged for the same reason... Maybe can someone give Shiji Yang, or me, if he has lost interest, some guidance on how this can be addressed? Best Regards, Christian
On Fri, Jun 23, 2023 at 05:23:59PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > The carl9170_tx_release() function sometimes triggers a fortified-memset > warning in my randconfig builds: > > In file included from include/linux/string.h:254, > from drivers/net/wireless/ath/carl9170/tx.c:40: > In function 'fortify_memset_chk', > inlined from 'carl9170_tx_release' at drivers/net/wireless/ath/carl9170/tx.c:283:2, > inlined from 'kref_put' at include/linux/kref.h:65:3, > inlined from 'carl9170_tx_put_skb' at drivers/net/wireless/ath/carl9170/tx.c:342:9: > include/linux/fortify-string.h:493:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] > 493 | __write_overflow_field(p_size_field, size); > > Kees previously tried to avoid this by using memset_after(), but it seems > this does not fully address the problem. I noticed that the memset_after() > here is done on a different part of the union (status) than the original > cast was from (rate_driver_data), which may confuse the compiler. > > Unfortunately, the memset_after() trick does not work on driver_rates[] > because that is part of an anonymous struct, and I could not get > struct_group() to do this either. Using two separate memset() calls > on the two members does address the warning though. > > Fixes: fb5f6a0e8063b ("mac80211: Use memset_after() to clear tx status") > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > drivers/net/wireless/ath/carl9170/tx.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/ath/carl9170/tx.c b/drivers/net/wireless/ath/carl9170/tx.c > index 6bb9aa2bfe654..88ef6e023f826 100644 > --- a/drivers/net/wireless/ath/carl9170/tx.c > +++ b/drivers/net/wireless/ath/carl9170/tx.c > @@ -280,7 +280,8 @@ static void carl9170_tx_release(struct kref *ref) > * carl9170_tx_fill_rateinfo() has filled the rate information > * before we get to this point. > */ > - memset_after(&txinfo->status, 0, rates); > + memset(&txinfo->pad, 0, sizeof(txinfo->pad)); > + memset(&txinfo->rate_driver_data, 0, sizeof(txinfo->rate_driver_data)); This is "accidentally" equivalent, which makes me nervous. It was designed to clear everything after "rates", regardless of padding, etc. What I don't get is why the warning is being emitted. It boils down to an expansion of this: memset(__ptr + offsetofend(typeof(*(obj)), member), __val, sizeof(*(obj)) - offsetofend(typeof(*(obj)), member)); into: memset(&txinfo->status + offsetofend(struct ieee80211_tx_info, rates), 0, sizeof(txinfo->status - offsetofend(struct ieee80211_tx_info, rates))) Is offsetofend() broken?
On Fri, Jun 23, 2023 at 06:05:57PM +0200, Arnd Bergmann wrote: > Doing the randconfig builds with the latest compilers, carl9170 is the > only one I see with fortified-string warnings, and there are a few > dozen other drivers that I see with W=1, including one that affects > all wireless drivers. Can you post the config that triggers this? I can't reproduce this warning... -Kees
On 23. 06. 23, 19:15, Christian Lamparter wrote: > On 6/23/23 18:05, Arnd Bergmann wrote: >> On Fri, Jun 23, 2023, at 17:38, Christian Lamparter wrote: >>> On 6/23/23 17:23, Arnd Bergmann wrote: >>> >>> Wait! I want to point out this funny thing is happening in ath too! >>> >>> https://lore.kernel.org/linux-wireless/TYAP286MB03154F9AAFD4C35BEEDE4A99BC4CA@TYAP286MB0315.JPNP286.PROD.OUTLOOK.COM/T/#mf1b8919a000fe661803c17073f48b3c410888541 >>> >>> And that patch got NACK by Jiri Slaby because like me he suspects that >>> this is a compiler bug. >> >> FWIW, that is one I don't see with clang-17 or gcc-13. The one I'm >> addressing >> here is the only thing I see in ath wireless with the default set of >> warning options, though this driver does have a couple of others that >> are unrelated, when you enable the source data check in memcpy() by >> building with W=1. >> >> In file included from drivers/net/wireless/ath/ath9k/xmit.c:17: >> In file included from include/linux/dma-mapping.h:7: >> In file included from include/linux/string.h:254: >> /home/arnd/arm-soc/include/linux/fortify-string.h:592:4: error: call >> to '__read_overflow2_field' declared with 'warning' attribute: >> detected read beyond size of field (2nd parameter); maybe use >> struct_group()? [-Werror,-Wattribute-warning] >> __read_overflow2_field(q_size_field, size); >> ^ >> include/linux/fortify-string.h:592:4: error: call to >> '__read_overflow2_field' declared with 'warning' attribute: detected >> read beyond size of field (2nd parameter); maybe use struct_group()? >> [-Werror,-Wattribute-warning] >> 2 errors generated. >> /home/arnd/arm-soc/include/linux/fortify-string.h:592:4: error: call >> to '__read_overflow2_field' declared with 'warning' attribute: >> detected read beyond size of field (2nd parameter); maybe use >> struct_group()? [-Werror,-Wattribute-warning] >> __read_overflow2_field(q_size_field, size); >> >>> so, what's going wrong with fortified there? >> >> Kees might have a better answer to that, my best guess is that >> the one I'm addressing stems from the confusion between different >> union members. >> >> Doing the randconfig builds with the latest compilers, carl9170 is the >> only one I see with fortified-string warnings, and there are a few >> dozen other drivers that I see with W=1, including one that affects >> all wireless drivers. > > Hm, question here (to Jiri as well). Do you think that a workaround patch > for these > sort-of-obvious-but-compiler-bug-but-failed-to-make-a-simple-reproducer > would be OK to get NACKed? In my case, I fiddled around with it and > replaced the > the cc_ani memset in the following way: > > | memset(&common->cc_survey, 0, sizeof(common->cc_survey)); > |- memset(&common->cc_ani, 0, sizeof(common->cc_ani)); > |+ common->cc_ani.cycles = common->cc_ani.rx_busy = > common->cc_ani.rx_frame = common->cc_ani.tx_frame = 0; Nah, you are still changing the code for the compiler. And espectially this one calls for troubles later -- when cc_ani changes. Again, work also with compiler guys, they are usually helpful. Both in helping to understand the issue (from the compiler POV) and provide a fix/workaround. Even this carl9170 change looks very bad to me. While "memset_after(&txinfo->status, 0, rates);" means exactly what it does, those two memsets barely. It took me a while to understand what is going on and that it is the same. Don't do this. Perhaps we need memset_no_check()? thanks,
diff --git a/drivers/net/wireless/ath/carl9170/tx.c b/drivers/net/wireless/ath/carl9170/tx.c index 6bb9aa2bfe654..88ef6e023f826 100644 --- a/drivers/net/wireless/ath/carl9170/tx.c +++ b/drivers/net/wireless/ath/carl9170/tx.c @@ -280,7 +280,8 @@ static void carl9170_tx_release(struct kref *ref) * carl9170_tx_fill_rateinfo() has filled the rate information * before we get to this point. */ - memset_after(&txinfo->status, 0, rates); + memset(&txinfo->pad, 0, sizeof(txinfo->pad)); + memset(&txinfo->rate_driver_data, 0, sizeof(txinfo->rate_driver_data)); if (atomic_read(&ar->tx_total_queued)) ar->tx_schedule = true;