Skip to contentSkip to conversation

4.4.269-rc1 review

PATCH In review Greg Kroah-Hartman 6 participants 197 messages May 20, 2021 Page 2 of 2

Subsystems (2)
lore
Share & tools
lore
author maintainer
#187 lore raw

PATCH 187/190 ip6_tunnel: sit: proper dev_{hold|put} in ndo_[un]init methods

In reply to Greg Kroah-Hartman

From: Eric Dumazet <[email protected]>

commit 48bb5697269a7cbe5194dbb044dc38c517e34c58 upstream.

Same reasons than for the previous commits :
6289a98f0817 ("sit: proper dev_{hold|put} in ndo_[un]init methods") 40cb881b5aaa ("ip6_vti: proper dev_{hold|put} in ndo_[un]init methods") 7f700334be9a ("ip6_gre: proper dev_{hold|put} in ndo_[un]init methods")

After adopting CONFIG_PCPU_DEV_REFCNT=n option, syzbot was able to trigger a warning [1]

Issue here is that:

- all dev_put() should be paired with a corresponding prior dev_hold().

- A driver doing a dev_put() in its ndo_uninit() MUST also do a dev_hold() in its ndo_init(), only when ndo_init() is returning 0.

Otherwise, register_netdevice() would call ndo_uninit() in its error path and release a refcount too soon.

[1]

WARNING: CPU: 1 PID: 21059 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31
Modules linked in:
CPU: 1 PID: 21059 Comm: syz-executor.4 Not tainted 5.12.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:refcount_warn_saturate+0xbf/0x1e0 lib/refcount.c:31
Code: 1d 6a 5a e8 09 31 ff 89 de e8 8d 1a ab fd 84 db 75 e0 e8 d4 13 ab fd 48 c7 c7 a0 e1 c1 89 c6 05 4a 5a e8 09 01 e8 2e 36 fb 04 <0f> 0b eb c4 e8 b8 13 ab fd 0f b6 1d 39 5a e8 09 31 ff 89 de e8 58
RSP: 0018:ffffc900025aefe8 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000040000 RSI: ffffffff815c51f5 RDI: fffff520004b5def
RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815bdf8e R11: 0000000000000000 R12: ffff888023488568
R13: ffff8880254e9000 R14: 00000000dfd82cfd R15: ffff88802ee2d7c0
FS:  00007f13bc590700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f0943e74000 CR3: 0000000025273000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 __refcount_dec include/linux/refcount.h:344 [inline]
 refcount_dec include/linux/refcount.h:359 [inline]
 dev_put include/linux/netdevice.h:4135 [inline]
 ip6_tnl_dev_uninit+0x370/0x3d0 net/ipv6/ip6_tunnel.c:387
 register_netdevice+0xadf/0x1500 net/core/dev.c:10308
 ip6_tnl_create2+0x1b5/0x400 net/ipv6/ip6_tunnel.c:263
 ip6_tnl_newlink+0x312/0x580 net/ipv6/ip6_tunnel.c:2052
 __rtnl_newlink+0x1062/0x1710 net/core/rtnetlink.c:3443
 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3491
 rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5553
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502
 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
 sock_sendmsg_nosec net/socket.c:654 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:674
 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixes 919067cc845f ("net: add CONFIG_PCPU_DEV_REFCNT")
---
 net/ipv6/ip6_tunnel.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv6/ip6_tunnel.c +1 -1
@@ -261,7 +261,6 @@ static int ip6_tnl_create2(struct net_de
 
 	strcpy(t->parms.name, dev->name);
 
-	dev_hold(dev);
 	ip6_tnl_link(ip6n, t);
 	return 0;
 
@@ -1581,6 +1580,7 @@ ip6_tnl_dev_init_gen(struct net_device *
 		return ret;
 	}
 
+	dev_hold(dev);
 	return 0;
 }
 
author maintainer
#188 lore raw

PATCH 188/190 ipv6: remove extra dev_hold() for fallback tunnels

In reply to Greg Kroah-Hartman

From: Eric Dumazet <[email protected]>

commit 0d7a7b2014b1a499a0fe24c9f3063d7856b5aaaf upstream.

My previous commits added a dev_hold() in tunnels ndo_init(), but forgot to remove it from special functions setting up fallback tunnels.

Fallback tunnels do call their respective ndo_init()

This leads to various reports like :

unregister_netdevice: waiting for ip6gre0 to become free. Usage count = 2

Fixes 48bb5697269a ("ip6_tunnel: sit: proper dev_{hold|put} in ndo_[un]init methods")
Fixes 6289a98f0817 ("sit: proper dev_{hold|put} in ndo_[un]init methods")
Fixes 40cb881b5aaa ("ip6_vti: proper dev_{hold|put} in ndo_[un]init methods")
Fixes 7f700334be9a ("ip6_gre: proper dev_{hold|put} in ndo_[un]init methods")
---
 net/ipv6/ip6_gre.c    |    3 ---
 net/ipv6/ip6_tunnel.c |    1 -
 net/ipv6/ip6_vti.c    |    1 -
 net/ipv6/sit.c        |    1 -
 4 files changed, 6 deletions(-)
net/ipv6/ip6_gre.c +0 -3
@@ -350,7 +350,6 @@ static struct ip6_tnl *ip6gre_tunnel_loc
 	if (!(nt->parms.o_flags & GRE_SEQ))
 		dev->features |= NETIF_F_LLTX;
 
-	dev_hold(dev);
 	ip6gre_tunnel_link(ign, nt);
 	return nt;
 
@@ -1310,8 +1309,6 @@ static void ip6gre_fb_tunnel_init(struct
 	strcpy(tunnel->parms.name, dev->name);
 
 	tunnel->hlen		= sizeof(struct ipv6hdr) + 4;
-
-	dev_hold(dev);
 }
 
 
net/ipv6/ip6_tunnel.c +0 -1
@@ -1614,7 +1614,6 @@ static int __net_init ip6_fb_tnl_dev_ini
 	struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id);
 
 	t->parms.proto = IPPROTO_IPV6;
-	dev_hold(dev);
 
 	rcu_assign_pointer(ip6n->tnls_wc[0], t);
 	return 0;
net/ipv6/ip6_vti.c +0 -1
@@ -931,7 +931,6 @@ static int __net_init vti6_fb_tnl_dev_in
 	struct vti6_net *ip6n = net_generic(net, vti6_net_id);
 
 	t->parms.proto = IPPROTO_IPV6;
-	dev_hold(dev);
 
 	rcu_assign_pointer(ip6n->tnls_wc[0], t);
 	return 0;
net/ipv6/sit.c +0 -1
@@ -1413,7 +1413,6 @@ static void __net_init ipip6_fb_tunnel_i
 	iph->ihl		= 5;
 	iph->ttl		= 64;
 
-	dev_hold(dev);
 	rcu_assign_pointer(sitn->tunnels_wc[0], tunnel);
 }
 
author maintainer
#189 lore raw

PATCH 189/190 xhci: Do not use GFP_KERNEL in (potentially) atomic context

In reply to Greg Kroah-Hartman

From: Christophe JAILLET <[email protected]>

commit dda32c00c9a0fa103b5d54ef72c477b7aa993679 upstream.

'xhci_urb_enqueue()' is passed a 'mem_flags' argument, because "URBs may be submitted in interrupt context" (see comment related to 'usb_submit_urb()' in 'drivers/usb/core/urb.c')

So this flag should be used in all the calling chain. Up to now, 'xhci_check_maxpacket()' which is only called from 'xhci_urb_enqueue()', uses GFP_KERNEL.

Be safe and pass the mem_flags to this function as well.

Fixes ddba5cd0aeff ("xhci: Use command structures when queuing commands on the command ring")
[iwamatsu: Adjust context]
---
 drivers/usb/host/xhci.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/usb/host/xhci.c +3 -3
@@ -1302,7 +1302,7 @@ static int xhci_configure_endpoint(struc
  * we need to issue an evaluate context command and wait on it.
  */
 static int xhci_check_maxpacket(struct xhci_hcd *xhci, unsigned int slot_id,
-		unsigned int ep_index, struct urb *urb)
+		unsigned int ep_index, struct urb *urb, gfp_t mem_flags)
 {
 	struct xhci_container_ctx *out_ctx;
 	struct xhci_input_control_ctx *ctrl_ctx;
@@ -1333,7 +1333,7 @@ static int xhci_check_maxpacket(struct x
 		 * changes max packet sizes.
 		 */
 
-		command = xhci_alloc_command(xhci, false, true, GFP_KERNEL);
+		command = xhci_alloc_command(xhci, false, true, mem_flags);
 		if (!command)
 			return -ENOMEM;
 
@@ -1440,7 +1440,7 @@ int xhci_urb_enqueue(struct usb_hcd *hcd
 		 */
 		if (urb->dev->speed == USB_SPEED_FULL) {
 			ret = xhci_check_maxpacket(xhci, slot_id,
-					ep_index, urb);
+					ep_index, urb, mem_flags);
 			if (ret < 0) {
 				xhci_urb_free_priv(urb_priv);
 				urb->hcpriv = NULL;
author maintainer
#190 lore raw

PATCH 190/190 iio: tsl2583: Fix division by a zero lux_val

In reply to Greg Kroah-Hartman

From: Colin Ian King <[email protected]>

commit af0e1871d79cfbb91f732d2c6fa7558e45c31038 upstream.

The lux_val returned from tsl2583_get_lux can potentially be zero, so check for this to avoid a division by zero and an overflowed gain_trim_val.

Fixes clang scan-build warning:

drivers/iio/light/tsl2583.c:345:40: warning: Either the condition 'lux_val<0' is redundant or there is division by zero at line 345. [zerodivcond]

Fixes ac4f6eee8fe8 ("staging: iio: TAOS tsl258x: Device driver")
[iwamatsu: Change file path.]
---
 drivers/staging/iio/light/tsl2583.c |    9 +++++++++
 1 file changed, 9 insertions(+)
drivers/staging/iio/light/tsl2583.c +9 -0
@@ -378,6 +378,15 @@ static int taos_als_calibrate(struct iio
 		dev_err(&chip->client->dev, "taos_als_calibrate failed to get lux\n");
 		return lux_val;
 	}
+
+	/* Avoid division by zero of lux_value later on */
+	if (lux_val == 0) {
+		dev_err(&chip->client->dev,
+			"%s: lux_val of 0 will produce out of range trim_value\n",
+			__func__);
+		return -ENODATA;
+	}
+
 	gain_trim_val = (unsigned int) (((chip->taos_settings.als_cal_target)
 			* chip->taos_settings.als_gain_trim) / lux_val);
 
#191 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.269 release. There are 190 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sat, 22 May 2021 09:20:38 +0000. Anything received after that time might be too late.

All mips builds still fail.

Building mips:defconfig ... failed
--------------
Error log:
In file included from include/linux/kernel.h:136,
from include/asm-generic/bug.h:13,
from arch/mips/include/asm/bug.h:41,
from include/linux/bug.h:4,
from include/linux/page-flags.h:9,
from kernel/bounds.c:9:
arch/mips/include/asm/div64.h:59:30: error: expected identifier or '(' before '{' token
59 | #define __div64_32(n, base) ({ \
| ^
include/asm-generic/div64.h:35:17: note: in expansion of macro '__div64_32'

   35 | extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
      |                 ^~~~~~~~~~

It looks like the changes conflict with the code in include/asm-generic/div64.h. That code is completely different in later kernel versions.

Guenter

author maintainer
#192 lore raw
Quoted 25 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.269 release. There are 190 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sat, 22 May 2021 09:20:38 +0000. Anything received after that time might be too late.

All mips builds still fail.

Building mips:defconfig ... failed
--------------
Error log:
In file included from include/linux/kernel.h:136,
from include/asm-generic/bug.h:13,
from arch/mips/include/asm/bug.h:41,
from include/linux/bug.h:4,
from include/linux/page-flags.h:9,
from kernel/bounds.c:9:
arch/mips/include/asm/div64.h:59:30: error: expected identifier or '(' before '{' token
59 | #define __div64_32(n, base) ({ \
| ^
include/asm-generic/div64.h:35:17: note: in expansion of macro '__div64_32'

Quoted 5 lines
   35 | extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
      |                 ^~~~~~~~~~

It looks like the changes conflict with the code in include/asm-generic/div64.h. That code is completely different in later kernel versions.

Now dropped.

thanks,

greg k-h

#193 lore raw
In reply to Guenter Roeck
Quoted 23 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.269 release. There are 190 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sat, 22 May 2021 09:20:38 +0000. Anything received after that time might be too late.

All mips builds still fail.

Building mips:defconfig ... failed
--------------
Error log:
In file included from include/linux/kernel.h:136,
from include/asm-generic/bug.h:13,
from arch/mips/include/asm/bug.h:41,
from include/linux/bug.h:4,
from include/linux/page-flags.h:9,
from kernel/bounds.c:9:
arch/mips/include/asm/div64.h:59:30: error: expected identifier or '(' before '{' token

Quoted 8 lines
    59 | #define __div64_32(n, base) ({      \
       |                              ^
include/asm-generic/div64.h:35:17: note: in expansion of macro '__div64_32'
    35 | extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
       |                 ^~~~~~~~~~

It looks like the changes conflict with the code in include/asm-generic/div64.h. That code is completely different in later kernel versions.

LKFT build system also found these MIPS builds failed.

- Naresh

Tested-by on the v1 series
#194 lore raw
In reply to Greg Kroah-Hartman

Hi!

Quoted 4 lines

This is the start of the stable review cycle for the 4.4.269 release. There are 190 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

CIP testing did not find any problems here:

https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.4.y

Best regards,
Pavel

Signature · 2 lines
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
maintainer Tested-by on the v1 series
#195 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.269 release. There are 190 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sat, 22 May 2021 09:20:38 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 8 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.269-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

All tests passing for Tegra ...

Test results for stable-v4.4:

    6 builds:	6 pass, 0 fail
    12 boots:	12 pass, 0 fail
    30 tests:	30 pass, 0 fail

Linux version: 4.4.269-rc1-g8605df0345a8
Boards tested: tegra124-jetson-tk1, tegra20-ventana,

                tegra30-cardhu-a04

Jon

Tested-by on the v1 series
#196 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.4.269 release. There are 190 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Sat, 22 May 2021 09:20:38 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

Quoted 9 lines
	https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.269-rc1.gz

or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah