4.4.269-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 187/190 ip6_tunnel: sit: proper dev_{hold|put} in ndo_[un]init methods
In reply to Greg Kroah-HartmanFrom: 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
--- 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_destrcpy (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 ; }
Greg Kroah-Hartman
maintainerPATCH 188/190 ipv6: remove extra dev_hold() for fallback tunnels
In reply to Greg Kroah-HartmanFrom: 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
--- 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_locif (!(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(structstrcpy (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_inistruct 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_instruct 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); }
Greg Kroah-Hartman
maintainerPATCH 189/190 xhci: Do not use GFP_KERNEL in (potentially) atomic context
In reply to Greg Kroah-HartmanFrom: 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.
--- 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 ;
Greg Kroah-Hartman
maintainerPATCH 190/190 iio: tsl2583: Fix division by a zero lux_val
In reply to Greg Kroah-HartmanFrom: 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]
--- 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 iiodev_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);
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
Greg Kroah-Hartman
maintainerQuoted 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 frominclude/linux/kernel.h:136,
frominclude/asm-generic/bug.h:13,
fromarch/mips/include/asm/bug.h:41,
frominclude/linux/bug.h:4,
frominclude/linux/page-flags.h:9,
fromkernel/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
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 frominclude/linux/kernel.h:136,
frominclude/asm-generic/bug.h:13,
fromarch/mips/include/asm/bug.h:41,
frominclude/linux/bug.h:4,
frominclude/linux/page-flags.h:9,
fromkernel/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
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
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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 failLinux version: 4.4.269-rc1-g8605df0345a8
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Jon
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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