linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] [v2] staging: rtl8723bs: avoid bogus gcc warning
@ 2021-04-22 15:26 Arnd Bergmann
  2021-04-27  9:32 ` Greg Kroah-Hartman
  0 siblings, 1 reply; 6+ messages in thread
From: Arnd Bergmann @ 2021-04-22 15:26 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Dan Carpenter, Arnd Bergmann, Fabio Aiuto, Ross Schmidt,
	Marco Cesati, Johannes Berg, Ivan Safonov, linux-staging,
	linux-kernel

From: Arnd Bergmann <arnd@arndb.de>

gcc gets confused by some of the type casts and produces an
apparently senseless warning about an out-of-bound memcpy to
an unrelated array in the same structure:

drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function 'rtw_cfg80211_ap_set_encryption':
cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
In file included from drivers/staging/rtl8723bs/include/drv_types.h:32,
                 from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:10:
drivers/staging/rtl8723bs/include/rtw_security.h:98:15: note: at offset [184, 4264] into destination object 'dot11AuthAlgrthm' of size 4
   98 |         u32   dot11AuthAlgrthm;         /*  802.11 auth, could be open, shared, 8021x and authswitch */
      |               ^~~~~~~~~~~~~~~~
cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
drivers/staging/rtl8723bs/include/rtw_security.h:98:15: note: at offset [264, 4344] into destination object 'dot11AuthAlgrthm' of size 4

This is a known gcc bug, and the patch here is only a workaround,
but the approach of using a temporary variable to hold a pointer
to the key also improves readability in addition to avoiding the
warning, so overall this should still help.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
v2: revert unrelated changes in the patch, pointed out by
    Dan Carpenter
---
 .../staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 23 +++++++++++--------
 .../staging/rtl8723bs/os_dep/ioctl_linux.c    | 21 +++++++++--------
 2 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index 89a21eb63c0a..98cbd2fce5cf 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -523,6 +523,9 @@ static int rtw_cfg80211_ap_set_encryption(struct net_device *dev, struct ieee_pa
 	struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
 	struct security_priv *psecuritypriv =  &(padapter->securitypriv);
 	struct sta_priv *pstapriv = &padapter->stapriv;
+	char *grpkey = padapter->securitypriv.dot118021XGrpKey[param->u.crypt.idx].skey;
+	char *txkey = padapter->securitypriv.dot118021XGrptxmickey[param->u.crypt.idx].skey;
+	char *rxkey = padapter->securitypriv.dot118021XGrprxmickey[param->u.crypt.idx].skey;
 
 	param->u.crypt.err = 0;
 	param->u.crypt.alg[IEEE_CRYPT_ALG_NAME_LEN - 1] = '\0';
@@ -605,7 +608,7 @@ static int rtw_cfg80211_ap_set_encryption(struct net_device *dev, struct ieee_pa
 		{
 			if (strcmp(param->u.crypt.alg, "WEP") == 0)
 			{
-				memcpy(psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
+				memcpy(grpkey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
 
 				psecuritypriv->dot118021XGrpPrivacy = _WEP40_;
 				if (param->u.crypt.key_len == 13)
@@ -618,12 +621,12 @@ static int rtw_cfg80211_ap_set_encryption(struct net_device *dev, struct ieee_pa
 			{
 				psecuritypriv->dot118021XGrpPrivacy = _TKIP_;
 
-				memcpy(psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
+				memcpy(grpkey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
 
 				/* DEBUG_ERR("set key length :param->u.crypt.key_len =%d\n", param->u.crypt.key_len); */
 				/* set mic key */
-				memcpy(psecuritypriv->dot118021XGrptxmickey[param->u.crypt.idx].skey, &(param->u.crypt.key[16]), 8);
-				memcpy(psecuritypriv->dot118021XGrprxmickey[param->u.crypt.idx].skey, &(param->u.crypt.key[24]), 8);
+				memcpy(txkey, &(param->u.crypt.key[16]), 8);
+				memcpy(rxkey, &(param->u.crypt.key[24]), 8);
 
 				psecuritypriv->busetkipkey = true;
 
@@ -632,7 +635,7 @@ static int rtw_cfg80211_ap_set_encryption(struct net_device *dev, struct ieee_pa
 			{
 				psecuritypriv->dot118021XGrpPrivacy = _AES_;
 
-				memcpy(psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
+				memcpy(grpkey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
 			}
 			else
 			{
@@ -709,7 +712,7 @@ static int rtw_cfg80211_ap_set_encryption(struct net_device *dev, struct ieee_pa
 			{
 				if (strcmp(param->u.crypt.alg, "WEP") == 0)
 				{
-					memcpy(psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
+					memcpy(grpkey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
 
 					psecuritypriv->dot118021XGrpPrivacy = _WEP40_;
 					if (param->u.crypt.key_len == 13)
@@ -721,12 +724,12 @@ static int rtw_cfg80211_ap_set_encryption(struct net_device *dev, struct ieee_pa
 				{
 					psecuritypriv->dot118021XGrpPrivacy = _TKIP_;
 
-					memcpy(psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
+					memcpy(grpkey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
 
 					/* DEBUG_ERR("set key length :param->u.crypt.key_len =%d\n", param->u.crypt.key_len); */
 					/* set mic key */
-					memcpy(psecuritypriv->dot118021XGrptxmickey[param->u.crypt.idx].skey, &(param->u.crypt.key[16]), 8);
-					memcpy(psecuritypriv->dot118021XGrprxmickey[param->u.crypt.idx].skey, &(param->u.crypt.key[24]), 8);
+					memcpy(txkey, &(param->u.crypt.key[16]), 8);
+					memcpy(rxkey, &(param->u.crypt.key[24]), 8);
 
 					psecuritypriv->busetkipkey = true;
 
@@ -735,7 +738,7 @@ static int rtw_cfg80211_ap_set_encryption(struct net_device *dev, struct ieee_pa
 				{
 					psecuritypriv->dot118021XGrpPrivacy = _AES_;
 
-					memcpy(psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
+					memcpy(grpkey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
 				}
 				else
 				{
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
index 816033b6847c..af77f03df7d0 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_linux.c
@@ -2963,6 +2963,9 @@ static int rtw_set_encryption(struct net_device *dev, struct ieee_param *param,
 	struct mlme_priv *pmlmepriv = &padapter->mlmepriv;
 	struct security_priv *psecuritypriv = &(padapter->securitypriv);
 	struct sta_priv *pstapriv = &padapter->stapriv;
+	char *txkey = padapter->securitypriv.dot118021XGrptxmickey[param->u.crypt.idx].skey;
+	char *rxkey = padapter->securitypriv.dot118021XGrprxmickey[param->u.crypt.idx].skey;
+	char *grpkey = psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey;
 
 	param->u.crypt.err = 0;
 	param->u.crypt.alg[IEEE_CRYPT_ALG_NAME_LEN - 1] = '\0';
@@ -3064,7 +3067,7 @@ static int rtw_set_encryption(struct net_device *dev, struct ieee_param *param,
 	if (!psta && check_fwstate(pmlmepriv, WIFI_AP_STATE)) { /*  group key */
 		if (param->u.crypt.set_tx == 1) {
 			if (strcmp(param->u.crypt.alg, "WEP") == 0) {
-				memcpy(psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
+				memcpy(grpkey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
 
 				psecuritypriv->dot118021XGrpPrivacy = _WEP40_;
 				if (param->u.crypt.key_len == 13)
@@ -3073,11 +3076,11 @@ static int rtw_set_encryption(struct net_device *dev, struct ieee_param *param,
 			} else if (strcmp(param->u.crypt.alg, "TKIP") == 0) {
 				psecuritypriv->dot118021XGrpPrivacy = _TKIP_;
 
-				memcpy(psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
+				memcpy(grpkey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
 
 				/* DEBUG_ERR("set key length :param->u.crypt.key_len =%d\n", param->u.crypt.key_len); */
 				/* set mic key */
-				memcpy(psecuritypriv->dot118021XGrptxmickey[param->u.crypt.idx].skey, &(param->u.crypt.key[16]), 8);
+				memcpy(txkey, &(param->u.crypt.key[16]), 8);
 				memcpy(psecuritypriv->dot118021XGrprxmickey[param->u.crypt.idx].skey, &(param->u.crypt.key[24]), 8);
 
 				psecuritypriv->busetkipkey = true;
@@ -3086,7 +3089,7 @@ static int rtw_set_encryption(struct net_device *dev, struct ieee_param *param,
 			else if (strcmp(param->u.crypt.alg, "CCMP") == 0) {
 				psecuritypriv->dot118021XGrpPrivacy = _AES_;
 
-				memcpy(psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
+				memcpy(grpkey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
 			} else {
 				psecuritypriv->dot118021XGrpPrivacy = _NO_PRIVACY_;
 			}
@@ -3142,7 +3145,7 @@ static int rtw_set_encryption(struct net_device *dev, struct ieee_param *param,
 
 			} else { /* group key??? */
 				if (strcmp(param->u.crypt.alg, "WEP") == 0) {
-					memcpy(psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
+					memcpy(grpkey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
 
 					psecuritypriv->dot118021XGrpPrivacy = _WEP40_;
 					if (param->u.crypt.key_len == 13)
@@ -3150,19 +3153,19 @@ static int rtw_set_encryption(struct net_device *dev, struct ieee_param *param,
 				} else if (strcmp(param->u.crypt.alg, "TKIP") == 0) {
 					psecuritypriv->dot118021XGrpPrivacy = _TKIP_;
 
-					memcpy(psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
+					memcpy(grpkey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
 
 					/* DEBUG_ERR("set key length :param->u.crypt.key_len =%d\n", param->u.crypt.key_len); */
 					/* set mic key */
-					memcpy(psecuritypriv->dot118021XGrptxmickey[param->u.crypt.idx].skey, &(param->u.crypt.key[16]), 8);
-					memcpy(psecuritypriv->dot118021XGrprxmickey[param->u.crypt.idx].skey, &(param->u.crypt.key[24]), 8);
+					memcpy(txkey, &(param->u.crypt.key[16]), 8);
+					memcpy(rxkey, &(param->u.crypt.key[24]), 8);
 
 					psecuritypriv->busetkipkey = true;
 
 				} else if (strcmp(param->u.crypt.alg, "CCMP") == 0) {
 					psecuritypriv->dot118021XGrpPrivacy = _AES_;
 
-					memcpy(psecuritypriv->dot118021XGrpKey[param->u.crypt.idx].skey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
+					memcpy(grpkey, param->u.crypt.key, (param->u.crypt.key_len > 16 ? 16 : param->u.crypt.key_len));
 				} else {
 					psecuritypriv->dot118021XGrpPrivacy = _NO_PRIVACY_;
 				}
-- 
2.29.2


^ permalink raw reply related	[flat|nested] 6+ messages in thread
* Re: [PATCH] [v2] staging: rtl8723bs: avoid bogus gcc warning
  2021-04-22 15:26 [PATCH] [v2] staging: rtl8723bs: avoid bogus gcc warning Arnd Bergmann
@ 2021-04-27  9:32 ` Greg Kroah-Hartman
  2021-04-27 11:59   ` Arnd Bergmann
  0 siblings, 1 reply; 6+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-27  9:32 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Dan Carpenter, Arnd Bergmann, Fabio Aiuto, Ross Schmidt,
	Marco Cesati, Johannes Berg, Ivan Safonov, linux-staging,
	linux-kernel

On Thu, Apr 22, 2021 at 05:26:19PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> gcc gets confused by some of the type casts and produces an
> apparently senseless warning about an out-of-bound memcpy to
> an unrelated array in the same structure:
> 
> drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function 'rtw_cfg80211_ap_set_encryption':
> cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
> In file included from drivers/staging/rtl8723bs/include/drv_types.h:32,
>                  from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:10:
> drivers/staging/rtl8723bs/include/rtw_security.h:98:15: note: at offset [184, 4264] into destination object 'dot11AuthAlgrthm' of size 4
>    98 |         u32   dot11AuthAlgrthm;         /*  802.11 auth, could be open, shared, 8021x and authswitch */
>       |               ^~~~~~~~~~~~~~~~
> cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
> drivers/staging/rtl8723bs/include/rtw_security.h:98:15: note: at offset [264, 4344] into destination object 'dot11AuthAlgrthm' of size 4
> 
> This is a known gcc bug, and the patch here is only a workaround,
> but the approach of using a temporary variable to hold a pointer
> to the key also improves readability in addition to avoiding the
> warning, so overall this should still help.

What version of gcc causes this?  Should this go into 5.13-final and be
backported?  Or is this only showing up on "unreleased" versions of gcc
and it is safe to wait until 5.14?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] [v2] staging: rtl8723bs: avoid bogus gcc warning
  2021-04-27  9:32 ` Greg Kroah-Hartman
@ 2021-04-27 11:59   ` Arnd Bergmann
  2021-04-27 12:41     ` Greg Kroah-Hartman
  0 siblings, 1 reply; 6+ messages in thread
From: Arnd Bergmann @ 2021-04-27 11:59 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Dan Carpenter, Fabio Aiuto, Ross Schmidt, Marco Cesati,
	Johannes Berg, Ivan Safonov, linux-staging,
	Linux Kernel Mailing List

On Tue, Apr 27, 2021 at 11:33 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Thu, Apr 22, 2021 at 05:26:19PM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > gcc gets confused by some of the type casts and produces an
> > apparently senseless warning about an out-of-bound memcpy to
> > an unrelated array in the same structure:
> >
> > drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function 'rtw_cfg80211_ap_set_encryption':
> > cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
> > In file included from drivers/staging/rtl8723bs/include/drv_types.h:32,
> >                  from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:10:
> > drivers/staging/rtl8723bs/include/rtw_security.h:98:15: note: at offset [184, 4264] into destination object 'dot11AuthAlgrthm' of size 4
> >    98 |         u32   dot11AuthAlgrthm;         /*  802.11 auth, could be open, shared, 8021x and authswitch */
> >       |               ^~~~~~~~~~~~~~~~
> > cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
> > drivers/staging/rtl8723bs/include/rtw_security.h:98:15: note: at offset [264, 4344] into destination object 'dot11AuthAlgrthm' of size 4
> >
> > This is a known gcc bug, and the patch here is only a workaround,
> > but the approach of using a temporary variable to hold a pointer
> > to the key also improves readability in addition to avoiding the
> > warning, so overall this should still help.
>
> What version of gcc causes this?  Should this go into 5.13-final and be
> backported?  Or is this only showing up on "unreleased" versions of gcc
> and it is safe to wait until 5.14?

As I understand, this is related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673

gcc-11.1.0 has now been released and it produces this warning.

        Arnd

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] [v2] staging: rtl8723bs: avoid bogus gcc warning
  2021-04-27 11:59   ` Arnd Bergmann
@ 2021-04-27 12:41     ` Greg Kroah-Hartman
  2021-04-27 13:00       ` Arnd Bergmann
  0 siblings, 1 reply; 6+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-27 12:41 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Dan Carpenter, Fabio Aiuto, Ross Schmidt, Marco Cesati,
	Johannes Berg, Ivan Safonov, linux-staging,
	Linux Kernel Mailing List

On Tue, Apr 27, 2021 at 01:59:32PM +0200, Arnd Bergmann wrote:
> On Tue, Apr 27, 2021 at 11:33 AM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Apr 22, 2021 at 05:26:19PM +0200, Arnd Bergmann wrote:
> > > From: Arnd Bergmann <arnd@arndb.de>
> > >
> > > gcc gets confused by some of the type casts and produces an
> > > apparently senseless warning about an out-of-bound memcpy to
> > > an unrelated array in the same structure:
> > >
> > > drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function 'rtw_cfg80211_ap_set_encryption':
> > > cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
> > > In file included from drivers/staging/rtl8723bs/include/drv_types.h:32,
> > >                  from drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:10:
> > > drivers/staging/rtl8723bs/include/rtw_security.h:98:15: note: at offset [184, 4264] into destination object 'dot11AuthAlgrthm' of size 4
> > >    98 |         u32   dot11AuthAlgrthm;         /*  802.11 auth, could be open, shared, 8021x and authswitch */
> > >       |               ^~~~~~~~~~~~~~~~
> > > cc1: error: writing 8 bytes into a region of size 0 [-Werror=stringop-overflow=]
> > > drivers/staging/rtl8723bs/include/rtw_security.h:98:15: note: at offset [264, 4344] into destination object 'dot11AuthAlgrthm' of size 4
> > >
> > > This is a known gcc bug, and the patch here is only a workaround,
> > > but the approach of using a temporary variable to hold a pointer
> > > to the key also improves readability in addition to avoiding the
> > > warning, so overall this should still help.
> >
> > What version of gcc causes this?  Should this go into 5.13-final and be
> > backported?  Or is this only showing up on "unreleased" versions of gcc
> > and it is safe to wait until 5.14?
> 
> As I understand, this is related to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673
> 
> gcc-11.1.0 has now been released and it produces this warning.

What's the odds we can get gcc to fix their bug, as it's not a kernel
issue?  :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] [v2] staging: rtl8723bs: avoid bogus gcc warning
  2021-04-27 12:41     ` Greg Kroah-Hartman
@ 2021-04-27 13:00       ` Arnd Bergmann
  2021-04-27 16:08         ` Greg Kroah-Hartman
  0 siblings, 1 reply; 6+ messages in thread
From: Arnd Bergmann @ 2021-04-27 13:00 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Dan Carpenter, Fabio Aiuto, Ross Schmidt, Marco Cesati,
	Johannes Berg, Ivan Safonov, linux-staging,
	Linux Kernel Mailing List

On Tue, Apr 27, 2021 at 2:42 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, Apr 27, 2021 at 01:59:32PM +0200, Arnd Bergmann wrote:
> > On Tue, Apr 27, 2021 at 11:33 AM Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:

> > >
> > > What version of gcc causes this?  Should this go into 5.13-final and be
> > > backported?  Or is this only showing up on "unreleased" versions of gcc
> > > and it is safe to wait until 5.14?
> >
> > As I understand, this is related to
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673
> >
> > gcc-11.1.0 has now been released and it produces this warning.
>
> What's the odds we can get gcc to fix their bug, as it's not a kernel
> issue?  :)

I think there is a high chance it will get fixed in gcc-11.2 or 12.1, but
anyone using gcc-11.1 will still have the problem.

        Arnd

^ permalink raw reply	[flat|nested] 6+ messages in thread
* Re: [PATCH] [v2] staging: rtl8723bs: avoid bogus gcc warning
  2021-04-27 13:00       ` Arnd Bergmann
@ 2021-04-27 16:08         ` Greg Kroah-Hartman
  0 siblings, 0 replies; 6+ messages in thread
From: Greg Kroah-Hartman @ 2021-04-27 16:08 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Dan Carpenter, Fabio Aiuto, Ross Schmidt, Marco Cesati,
	Johannes Berg, Ivan Safonov, linux-staging,
	Linux Kernel Mailing List

On Tue, Apr 27, 2021 at 03:00:28PM +0200, Arnd Bergmann wrote:
> On Tue, Apr 27, 2021 at 2:42 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Tue, Apr 27, 2021 at 01:59:32PM +0200, Arnd Bergmann wrote:
> > > On Tue, Apr 27, 2021 at 11:33 AM Greg Kroah-Hartman
> > > <gregkh@linuxfoundation.org> wrote:
> 
> > > >
> > > > What version of gcc causes this?  Should this go into 5.13-final and be
> > > > backported?  Or is this only showing up on "unreleased" versions of gcc
> > > > and it is safe to wait until 5.14?
> > >
> > > As I understand, this is related to
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673
> > >
> > > gcc-11.1.0 has now been released and it produces this warning.
> >
> > What's the odds we can get gcc to fix their bug, as it's not a kernel
> > issue?  :)
> 
> I think there is a high chance it will get fixed in gcc-11.2 or 12.1, but
> anyone using gcc-11.1 will still have the problem.

Ugh, ok, I'll queue it up for 5.13-final.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-04-27 16:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-22 15:26 [PATCH] [v2] staging: rtl8723bs: avoid bogus gcc warning Arnd Bergmann
2021-04-27  9:32 ` Greg Kroah-Hartman
2021-04-27 11:59   ` Arnd Bergmann
2021-04-27 12:41     ` Greg Kroah-Hartman
2021-04-27 13:00       ` Arnd Bergmann
2021-04-27 16:08         ` Greg Kroah-Hartman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).