Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kernel deadlock when canbus is configured #24

Closed
mpvader opened this issue May 11, 2016 · 7 comments
Closed

kernel deadlock when canbus is configured #24

mpvader opened this issue May 11, 2016 · 7 comments
Assignees

Comments

@mpvader
Copy link
Contributor

mpvader commented May 11, 2016

Summary

When enabling can0 in /etc/network/interfaces, deadlocks appear in the logs, after boot. Therefore canbus is not yet enabled on the standard image. See below for an example log output with a deadlock. The killed project, vrmlogger, has nothing to do with canbus. And not always the same process crashes, this example contains vrmlogger but rebooting several times also shows other processes.

Reproduce the issue

Download this image into a standard beaglebone black (no custom capes or connecting anything to the canbus is required):
https://www.dropbox.com/s/0dp6m3ly6m66fcj/venus-image-beaglebone-20160710135100.rootfs.wic?dl=0

Note that any of our images will do: the issue has been present since the beginning of adding the beaglebone to venus

Burn to disk and run the image. Then modify /etc/network/interfacs, and uncomment these five lines:

auto can0
iface can0 inet manual
        pre-up ip link set $IFACE type can bitrate 250000 restart-ms 100
        up /sbin/ifconfig $IFACE up
        down /sbin/ifconfig $IFACE down

Reboot again, and you'll see the deadlock in the console within minutes.

Current workaround (to test hardware for example):

Don't enable it via /etc/network/interfaces, but enable the canbus manually. Note that below step then needs to be done after every boot. And note that the workaround might not even be necessary: I never tried if, although there is a lock, the canbus works when autoconfigured.

Manually enabling canbus from the commandline:

$ ip link set can1 up type can bitrate 250000
[   40.275265] c_can_platform 481d0000.can can1: setting BTR=1c05 BRPE=0000
[   40.283244] IPv6: ADDRCONF(NETDEV_CHANGE): can1: link becomes ready

Same for setting up can0, it can be done manually without getting the locking problem:
$ ip link set can0 up type can bitrate 250000
[   47.574025] c_can_platform 481cc000.can can0: setting BTR=1c05 BRPE=0000
[   47.581372] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready

To actually make our canbus<->D-Bus driver work with one of the interfaces, modify /service/vecan-dbus/run, add selecting the right interface. The run file should look like this:

$ cat /service/vecan-dbus/run
#!/bin/sh
exec 2>&1
exec softlimit -d 2000000 -s 1000000 -a 100000000 /opt/color-control/vecan-dbus/vecan-dbus --banner --log-before 25 --log-after 25 -vv -c socketcan:can1

Note that enabling both canbusses without changing above config line will cause for an endless restarting service: 100% processor usage.

@mpvader mpvader self-assigned this May 11, 2016
@mpvader
Copy link
Contributor Author

mpvader commented May 22, 2016

Log output showing the error:

Configuring network interfaces... [    6.557104] net eth0: initializing cpsw version 1.12 (0)
[    6.565215] net eth0: phy found : id is : 0x7c0f1
[    6.570314] libphy: PHY 4a101000.mdio:01 not found
[    6.575342] net eth0: phy 4a101000.mdio:01 not found on slave 1
[    6.587466] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
udhcpc (v1.23.2) started
Sending discover...
Sending discover...
Sending discover...
No lease, forking to background
[   15.831436] c_can_platform 481cc000.can can0: setting BTR=1c05 BRPE=0000
done.
Starting system message bus: Setting up watches.
Watches established.
/var/run/dbus/ CREATE system_bus_socket
Starting syslogd/klogd: done
Starting php-fpm  done
Starting Connection Manager
Starting Hiawatha Web Server: hiawatha.
Starting crond: OK
Starting simple-upnpd
dbus[880]: [system] Activating service name='fi.w1.wpa_supplicant1' (using servicehelper)
dbus[880]: [system] Successfully activated service 'fi.w1.wpa_supplicant1'
[   24.279456] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
[   24.393464] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.29

beaglebone login: [   24.656378] random: nonblocking pool is initialized
[   25.206929] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   26.730822] wlan0: authenticate with 98:fc:11:ae:b5:04
[   26.831685] wlan0: send auth to 98:fc:11:ae:b5:04 (try 1/3)
[   26.843218] wlan0: authenticated
[   26.881219] wlan0: associate with 98:fc:11:ae:b5:04 (try 1/3)
[   26.899338] wlan0: RX AssocResp from 98:fc:11:ae:b5:04 (capab=0x431 status=0 aid=4)
[   26.959517] wlan0: associated
[   26.963460] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   34.681228] c_can_platform 481cc000.can can0: setting BTR=1c05 BRPE=0000
[   34.688347]
[   34.689907] =================================
[   34.694470] [ INFO: inconsistent lock state ]
[   34.699038] 4.1.15-venus #1 Not tainted
[   34.703054] ---------------------------------
[   34.707619] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[   34.713915] vrmlogger.py/956 [HC0[0]:SC1[1]:HE1:SE0] takes:
[   34.719756]  (pinctrl_list_mutex){+.?...}, at: [<c02586d4>] pinctrl_get+0x2c/0x458
[   34.727732] {SOFTIRQ-ON-W} state was registered at:
[   34.732843]   [<c04be4a8>] mutex_lock_nested+0x44/0x34c
[   34.738334]   [<c02586d4>] pinctrl_get+0x2c/0x458
[   34.743268]   [<c0258b2c>] devm_pinctrl_get+0x2c/0x68
[   34.748566]   [<c02c1b58>] pinctrl_bind_pins+0x2c/0xf8
[   34.753960]   [<c02a9708>] driver_probe_device+0x60/0x2b8
[   34.759632]   [<c02a9a38>] __driver_attach+0x94/0x98
[   34.764840]   [<c02a7e54>] bus_for_each_dev+0x68/0x9c
[   34.770140]   [<c02a8f90>] bus_add_driver+0x14c/0x1f4
[   34.775439]   [<c02aa1cc>] driver_register+0x78/0xf8
[   34.780647]   [<c06c2a3c>] regulator_dummy_init+0x64/0x88
[   34.786318]   [<c06c277c>] regulator_init+0x90/0xa8
[   34.791435]   [<c0009638>] do_one_initcall+0x8c/0x1d8
[   34.796736]   [<c069ed30>] kernel_init_freeable+0x120/0x1c0
[   34.802585]   [<c04b93dc>] kernel_init+0x8/0xe8
[   34.807347]   [<c000f238>] ret_from_fork+0x14/0x3c
[   34.812378] irq event stamp: 174360
[   34.816031] hardirqs last  enabled at (174360): [<c0071778>] vprintk_emit+0x220/0x588
[   34.824256] hardirqs last disabled at (174359): [<c00715a8>] vprintk_emit+0x50/0x588
[   34.832379] softirqs last  enabled at (174246): [<c0035aa4>] __do_softirq+0x2d4/0x364
[   34.840604] softirqs last disabled at (174253): [<c0035e68>] irq_exit+0xfc/0x130
[   34.848362]
[   34.848362] other info that might help us debug this:
[   34.855204]  Possible unsafe locking scenario:
[   34.855204]
[   34.861408]        CPU0
[   34.863966]        ----
[   34.866524]   lock(pinctrl_list_mutex);
[   34.870549]   <Interrupt>
[   34.873289]     lock(pinctrl_list_mutex);
[   34.877495]
[   34.877495]  *** DEADLOCK ***
[   34.877495]
[   34.883702] 1 lock held by vrmlogger.py/956:
[   34.888173]  #0:  (((&priv->restart_timer))){+.-...}, at: [<c007c620>] call_timer_fn+0x0/0x194
[   34.897231]
[   34.897231] stack backtrace:
[   34.901801] CPU: 0 PID: 956 Comm: vrmlogger.py Not tainted 4.1.15-venus #1
[   34.909007] Hardware name: Generic AM33XX (Flattened Device Tree)
[   34.915411] [<c00147c4>] (unwind_backtrace) from [<c0012914>] (show_stack+0x10/0x14)
[   34.923536] [<c0012914>] (show_stack) from [<c04bb8bc>] (print_usage_bug.part.12+0x290/0x29c)
[   34.932480] [<c04bb8bc>] (print_usage_bug.part.12) from [<c0066484>] (mark_lock+0x68c/0x770)
[   34.941331] [<c0066484>] (mark_lock) from [<c0067158>] (__lock_acquire+0x6cc/0x1da0)
[   34.949452] [<c0067158>] (__lock_acquire) from [<c006912c>] (lock_acquire+0xac/0x12c)
[   34.957666] [<c006912c>] (lock_acquire) from [<c04be4a8>] (mutex_lock_nested+0x44/0x34c)
[   34.966154] [<c04be4a8>] (mutex_lock_nested) from [<c02586d4>] (pinctrl_get+0x2c/0x458)
[   34.974560] [<c02586d4>] (pinctrl_get) from [<c02d91c8>] (c_can_start+0x200/0x2c8)
[   34.982502] [<c02d91c8>] (c_can_start) from [<c02d92a4>] (c_can_set_mode+0x14/0x68)
[   34.990535] [<c02d92a4>] (c_can_set_mode) from [<c02d7a00>] (can_restart+0x94/0xc8)
[   34.998567] [<c02d7a00>] (can_restart) from [<c007c6b4>] (call_timer_fn+0x94/0x194)
[   35.006597] [<c007c6b4>] (call_timer_fn) from [<c007ca88>] (run_timer_softirq+0x1ec/0x2cc)
[   35.015266] [<c007ca88>] (run_timer_softirq) from [<c00358d4>] (__do_softirq+0x104/0x364)
[   35.023844] [<c00358d4>] (__do_softirq) from [<c0035e68>] (irq_exit+0xfc/0x130)
[   35.031513] [<c0035e68>] (irq_exit) from [<c00729cc>] (__handle_domain_irq+0x58/0xa8)
[   35.039727] [<c00729cc>] (__handle_domain_irq) from [<c0009458>] (omap_intc_handle_irq+0xc8/0xd0)
[   35.049038] [<c0009458>] (omap_intc_handle_irq) from [<c04c25e4>] (__irq_usr+0x44/0x60)
[   35.057428] Exception stack(0xdd40bfb0 to 0xdd40bff8)
[   35.062726] bfa0:                                     000aec48 4f40fc94 0b8c8eab 44da029b
[   35.071302] bfc0: 00000009 b6dc8cb4 b6dc62d4 b6dc6274 b6dc62a4 b6cf837c 00000000 b66e7a50
[   35.079877] bfe0: b6cf8424 bef21538 b6cd4570 4f4fd72c 20000010 ffffffff
[   35.087080] c_can_platform 481cc000.can: obtain a copy of previously claimed pinctrl
[   35.110134] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready

jhofstee pushed a commit to victronenergy/meta-victronenergy that referenced this issue Jul 1, 2016
Note that canbus is still disabled, since enabling it causes kernel locking
errors. See victronenergy/venus#24

Effect on building bpp3 in danny: none, other than generating this warning:
WARNING: No recipes available for:
  /media/venusbuilds/venus-danny/sources/meta-victronenergy/meta-venus/recipes-core/init-ifupdown/init-ifupdown_%.bbappend
@mpvader mpvader changed the title bbb: configure vecan bbb: kernel deadlock when canbus is configured Jul 11, 2016
@mpvader mpvader removed their assignment Jul 11, 2016
@mpvader
Copy link
Contributor Author

mpvader commented Jul 12, 2016

I had a hunch, that since vrmlogger.py crashed above, it might be related to vrmlogger.py actually calling both connman (over D-Bus) as well as executing ifconfig as a subprocess. But that is ruled out now. Disabling vrmlogger entirely still gives a deadlock after boot.

And also rebooting multiple times gives multiple different deadlocks. Like this one, which does not mention vrmlogger.py:

dbus[926]: [system] Activating service name='fi.w1.wpa_supplicant1' (using servicehelper)
dbus[926]: [system] Successfully activated service 'fi.w1.wpa_supplicant1'
[   29.313413] random: nonblocking pool is initialized
[   32.735320] c_can_platform 481cc000.can can0: setting BTR=1c05 BRPE=0000
[   32.742396]
[   32.743957] =================================
[   32.748519] [ INFO: inconsistent lock state ]
[   32.753087] 4.1.15-venus #1 Not tainted
[   32.757103] ---------------------------------
[   32.761667] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[   32.767963] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
[   32.773165]  (pinctrl_list_mutex){+.?...}, at: [<c02586d4>] pinctrl_get+0x2c/0x458
[   32.781142] {SOFTIRQ-ON-W} state was registered at:
[   32.786253]   [<c04be978>] mutex_lock_nested+0x44/0x34c
[   32.791743]   [<c02586d4>] pinctrl_get+0x2c/0x458
[   32.796677]   [<c0258b2c>] devm_pinctrl_get+0x2c/0x68
[   32.801976]   [<c02c1b58>] pinctrl_bind_pins+0x2c/0xf8
[   32.807368]   [<c02a9708>] driver_probe_device+0x60/0x2b8
[   32.813039]   [<c02a9a38>] __driver_attach+0x94/0x98
[   32.818247]   [<c02a7e54>] bus_for_each_dev+0x68/0x9c
[   32.823545]   [<c02a8f90>] bus_add_driver+0x14c/0x1f4
[   32.828844]   [<c02aa1cc>] driver_register+0x78/0xf8
[   32.834051]   [<c06c4a3c>] regulator_dummy_init+0x64/0x88
[   32.839724]   [<c06c477c>] regulator_init+0x90/0xa8
[   32.844840]   [<c0009638>] do_one_initcall+0x8c/0x1d8
[   32.850140]   [<c06a0d30>] kernel_init_freeable+0x120/0x1c0
[   32.855988]   [<c04b98ac>] kernel_init+0x8/0xe8
[   32.860750]   [<c000f238>] ret_from_fork+0x14/0x3c
[   32.865781] irq event stamp: 38572
[   32.869341] hardirqs last  enabled at (38572): [<c0071778>] vprintk_emit+0x220/0x588
[   32.877474] hardirqs last disabled at (38571): [<c00715a8>] vprintk_emit+0x50/0x588
[   32.885507] softirqs last  enabled at (38554): [<c0035d50>] irq_enter+0x68/0x84
[   32.893184] softirqs last disabled at (38555): [<c0035e68>] irq_exit+0xfc/0x130
[   32.900851]
[   32.900851] other info that might help us debug this:
[   32.907693]  Possible unsafe locking scenario:
[   32.907693]
[   32.913897]        CPU0
[   32.916455]        ----
[   32.919012]   lock(pinctrl_list_mutex);
[   32.923037]   <Interrupt>
[   32.925777]     lock(pinctrl_list_mutex);
[   32.929984]
[   32.929984]  *** DEADLOCK ***
[   32.929984]
[   32.936191] 1 lock held by swapper/0:
[   32.940025]  #0:  (((&priv->restart_timer))){+.-...}, at: [<c007c620>] call_timer_fn+0x0/0x194
[   32.949080]
[   32.949080] stack backtrace:
[   32.953650] CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.15-venus #1
[   32.960218] Hardware name: Generic AM33XX (Flattened Device Tree)
[   32.966621] [<c00147c4>] (unwind_backtrace) from [<c0012914>] (show_stack+0x10/0x14)
[   32.974745] [<c0012914>] (show_stack) from [<c04bbd8c>] (print_usage_bug.part.12+0x290/0x29c)
[   32.983688] [<c04bbd8c>] (print_usage_bug.part.12) from [<c0066484>] (mark_lock+0x68c/0x770)
[   32.992537] [<c0066484>] (mark_lock) from [<c0067158>] (__lock_acquire+0x6cc/0x1da0)
[   33.000658] [<c0067158>] (__lock_acquire) from [<c006912c>] (lock_acquire+0xac/0x12c)
[   33.008869] [<c006912c>] (lock_acquire) from [<c04be978>] (mutex_lock_nested+0x44/0x34c)
[   33.017356] [<c04be978>] (mutex_lock_nested) from [<c02586d4>] (pinctrl_get+0x2c/0x458)
[   33.025762] [<c02586d4>] (pinctrl_get) from [<c02d91c8>] (c_can_start+0x200/0x2c8)
[   33.033702] [<c02d91c8>] (c_can_start) from [<c02d92a4>] (c_can_set_mode+0x14/0x68)
[   33.041734] [<c02d92a4>] (c_can_set_mode) from [<c02d7a00>] (can_restart+0x94/0xc8)
[   33.049764] [<c02d7a00>] (can_restart) from [<c007c6b4>] (call_timer_fn+0x94/0x194)
[   33.057794] [<c007c6b4>] (call_timer_fn) from [<c007ca88>] (run_timer_softirq+0x1ec/0x2cc)
[   33.066462] [<c007ca88>] (run_timer_softirq) from [<c00358d4>] (__do_softirq+0x104/0x364)
[   33.075039] [<c00358d4>] (__do_softirq) from [<c0035e68>] (irq_exit+0xfc/0x130)
[   33.082707] [<c0035e68>] (irq_exit) from [<c00729cc>] (__handle_domain_irq+0x58/0xa8)
[   33.090921] [<c00729cc>] (__handle_domain_irq) from [<c0009458>] (omap_intc_handle_irq+0xc8/0xd0)
[   33.100230] [<c0009458>] (omap_intc_handle_irq) from [<c04c2804>] (__irq_svc+0x44/0x5c)
[   33.108621] Exception stack(0xc06e3f50 to 0xc06e3f98)
[   33.113917] 3f40:                                     00000001 00000001 00000000 c06e75f8
[   33.122492] 3f60: c06e2000 c06e4120 00000000 c073112c 00000000 00000001 c07219b8 c06e4128
[   33.131066] 3f80: 00000000 c06e3f98 c006674c c000faf0 200e0013 ffffffff
[   33.138004] [<c04c2804>] (__irq_svc) from [<c000faf0>] (arch_cpu_idle+0x24/0x3c)
[   33.145771] [<c000faf0>] (arch_cpu_idle) from [<c005e8c8>] (cpu_startup_entry+0x250/0x2d0)
[   33.154439] [<c005e8c8>] (cpu_startup_entry) from [<c06a0c04>] (start_kernel+0x338/0x344)
[   33.163146] c_can_platform 481cc000.can: obtain a copy of previously claimed pinctrl
[   33.174538] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready

@mpvader mpvader changed the title bbb: kernel deadlock when canbus is configured kernel deadlock when canbus is configured Jul 13, 2016
@mpvader
Copy link
Contributor Author

mpvader commented Aug 8, 2016

assigned to Denx

@mpvader mpvader self-assigned this Sep 1, 2016
@mpvader
Copy link
Contributor Author

mpvader commented Sep 1, 2016

Reply from Denx:

The reason is clear (there is a race condition at the start-up when pinmux is set), and the small patch below solves the issue. Patch applies to branch bbb_b4.1.15.

It was not solved upstream yet, so will be posted soon.

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 141c2a4..2c582cd 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -21,6 +21,7 @@
 #include <linux/slab.h>
 #include <linux/netdevice.h>
 #include <linux/if_arp.h>
+#include <linux/workqueue.h>
 #include <linux/can.h>
 #include <linux/can/dev.h>
 #include <linux/can/skb.h>
@@ -471,9 +472,8 @@ EXPORT_SYMBOL_GPL(can_free_echo_skb);
 /*
  * CAN device restart for bus-off recovery
  */
-static void can_restart(unsigned long data)
+static void can_restart(struct net_device *dev)
 {
-   struct net_device *dev = (struct net_device *)data;
    struct can_priv *priv = netdev_priv(dev);
    struct net_device_stats *stats = &dev->stats;
    struct sk_buff *skb;
@@ -513,6 +513,14 @@ restart:
        netdev_err(dev, "Error %d during restart", err);
 }

+static void can_restart_work(struct work_struct *work)
+{
+   struct delayed_work *dwork = to_delayed_work(work);
+   struct can_priv *priv = container_of(dwork, struct can_priv, restart_work);
+
+   can_restart(priv->dev);
+}
+
 int can_restart_now(struct net_device *dev)
 {
    struct can_priv *priv = netdev_priv(dev);
@@ -526,8 +534,8 @@ int can_restart_now(struct net_device *dev)
    if (priv->state != CAN_STATE_BUS_OFF)
        return -EBUSY;

-   /* Runs as soon as possible in the timer context */
-   mod_timer(&priv->restart_timer, jiffies);
+   cancel_delayed_work_sync(&priv->restart_work);
+   can_restart(dev);

    return 0;
 }
@@ -548,8 +556,8 @@ void can_bus_off(struct net_device *dev)
    netif_carrier_off(dev);

    if (priv->restart_ms)
-       mod_timer(&priv->restart_timer,
-             jiffies + (priv->restart_ms * HZ) / 1000);
+       schedule_delayed_work(&priv->restart_work,
+                     msecs_to_jiffies(priv->restart_ms));
 }
 EXPORT_SYMBOL_GPL(can_bus_off);

@@ -658,6 +666,7 @@ struct net_device *alloc_candev(int sizeof_priv, unsigned int echo_skb_max)
        return NULL;

    priv = netdev_priv(dev);
+   priv->dev = dev;

    if (echo_skb_max) {
        priv->echo_skb_max = echo_skb_max;
@@ -667,7 +676,7 @@ struct net_device *alloc_candev(int sizeof_priv, unsigned int echo_skb_max)

    priv->state = CAN_STATE_STOPPED;

-   init_timer(&priv->restart_timer);
+   INIT_DELAYED_WORK(&priv->restart_work, can_restart_work);

    return dev;
 }
@@ -742,8 +751,6 @@ int open_candev(struct net_device *dev)
    if (!netif_carrier_ok(dev))
        netif_carrier_on(dev);

-   setup_timer(&priv->restart_timer, can_restart, (unsigned long)dev);
-
    return 0;
 }
 EXPORT_SYMBOL_GPL(open_candev);
@@ -758,7 +765,7 @@ void close_candev(struct net_device *dev)
 {
    struct can_priv *priv = netdev_priv(dev);

-   del_timer_sync(&priv->restart_timer);
+   cancel_delayed_work_sync(&priv->restart_work);
    can_flush_echo_skb(dev);
 }
 EXPORT_SYMBOL_GPL(close_candev);
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index c3a9c8f..4f0590c 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -31,6 +31,7 @@ enum can_mode {
  * CAN common private data
  */
 struct can_priv {
+   struct net_device *dev;
    struct can_device_stats can_stats;

    struct can_bittiming bittiming, data_bittiming;
@@ -43,7 +44,7 @@ struct can_priv {
    u32 ctrlmode_supported;

    int restart_ms;
-   struct timer_list restart_timer;
+   struct delayed_work restart_work;

    int (*do_set_bittiming)(struct net_device *dev);
    int (*do_set_data_bittiming)(struct net_device *dev);

mpvader added a commit to victronenergy/linux that referenced this issue Sep 5, 2016
Race condition cased a kernel deadlock message at bootup when
canbus was enabled.

For details see victronenergy/venus#24

Patch is made by someone at Denx, and will be submitted to upstream
@mpvader
Copy link
Contributor Author

mpvader commented Sep 5, 2016

tested, the patch fixes the issue.

applied
victronenergy/linux@0f6681e

@mpvader mpvader closed this as completed Sep 5, 2016
mpvader added a commit to victronenergy/meta-victronenergy that referenced this issue Sep 12, 2016
This can be done now, since related kernel deadlock issue victronenergy/venus#24
is closed.
fcuzzocrea pushed a commit to fcuzzocrea/android_kernel_nvidia_shield that referenced this issue Feb 25, 2020
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
fcuzzocrea pushed a commit to fcuzzocrea/android_kernel_nvidia_shield that referenced this issue Mar 1, 2020
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
fcuzzocrea pushed a commit to fcuzzocrea/android_kernel_nvidia_shield that referenced this issue Mar 1, 2020
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
rlawoehd187 pushed a commit to rlawoehd187/android_kernel_lge_apq8084 that referenced this issue Mar 14, 2020
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
AndroiableDroid pushed a commit to AndroiableDroid/kernel_LYF_panda01a that referenced this issue Apr 5, 2020
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
AndroiableDroid pushed a commit to AndroiableDroid/kernel_LYF_panda01a that referenced this issue Apr 5, 2020
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
AndroiableDroid pushed a commit to AndroiableDroid/kernel_LYF_panda01a that referenced this issue Apr 6, 2020
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
vinixast pushed a commit to vinixast/kernel_new_apollo that referenced this issue Apr 17, 2020
[ Upstream commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 ]

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
R0rt1z2 pushed a commit to R0rt1z2/android_kernel_huawei_warsaw that referenced this issue Apr 28, 2020
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
goldfish07 pushed a commit to goldfish07/android_kernel_moto_panelli that referenced this issue Jun 11, 2020
[ Upstream commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 ]

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
samueldr pushed a commit to samueldr/linux that referenced this issue Jun 28, 2020
[ Upstream commit 9abefcb ]

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
bphaslett pushed a commit to bphaslett/android_kernel_amazon_karnak that referenced this issue Jul 4, 2020
[ Upstream commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 ]

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Huawei-Dev pushed a commit to Huawei-Dev/android_kernel_huawei_btv that referenced this issue Oct 14, 2020
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Huawei-Dev pushed a commit to Huawei-Dev/android_kernel_huawei_btv that referenced this issue Oct 23, 2020
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thunderoar pushed a commit to Thunderoar/latest_goyave_kernel that referenced this issue Aug 5, 2021
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
sabarop pushed a commit to sabarop/kernel_sony_msm8994 that referenced this issue Sep 8, 2021
commit 9abefcb upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
sabarop pushed a commit to sabarop/kernel_sony_msm8994 that referenced this issue Sep 21, 2021
commit 9abefcb upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
turex pushed a commit to turex/labyrinth_kernel_prague that referenced this issue Nov 28, 2021
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
althafvly pushed a commit to MOTO-M8916/android_kernel_motorola_msm8916 that referenced this issue Dec 14, 2021
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
DeepakChaurasia30 pushed a commit to DeepakChaurasia30/kernel_oppo_msm8916-offical that referenced this issue Jan 10, 2022
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
ggow pushed a commit to lineage16-suez/kernel_amazon_suez that referenced this issue Apr 9, 2022
[ Upstream commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 ]

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit 7651e974ae519bfd2354bfb8ab972112b65c595e)
thenextgod pushed a commit to thenextgod/kernel_msm8976 that referenced this issue Jul 6, 2022
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Coconutat pushed a commit to Coconutat/android_kernel_huawei_victoria that referenced this issue May 1, 2023
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
youheng7185 pushed a commit to youheng7185/j2y18lte-kernel-upstream that referenced this issue May 31, 2023
[ Upstream commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 ]

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
andrew2193 pushed a commit to andrew2193/medusa that referenced this issue Jun 7, 2023
[ Upstream commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 ]

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
prototype74 pushed a commit to prototype74/android_kernel_samsung_j5xlte that referenced this issue Dec 21, 2023
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
bluess57 pushed a commit to bluess57/android_kernel_samsung_universal5433 that referenced this issue Jan 10, 2024
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
bluess57 pushed a commit to bluess57/android_kernel_samsung_universal5433 that referenced this issue Jan 11, 2024
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
metterschlg pushed a commit to metterschlg/android_kernel_samsung_universal5433 that referenced this issue Jan 21, 2024
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Willy Tarreau <w@1wt.eu>
FlorinelulX pushed a commit to FlorinelulX/android_kernel_huawei_hi6250-8 that referenced this issue Feb 12, 2024
commit 9abefcb1aaa58b9d5aa40a8bb12c87d02415e4c8 upstream.

A timer was used to restart after the bus-off state, leading to a
relatively large can_restart() executed in an interrupt context,
which in turn sets up pinctrl. When this happens during system boot,
there is a high probability of grabbing the pinctrl_list_mutex,
which is locked already by the probe() of other device, making the
kernel suspect a deadlock condition [1].

To resolve this issue, the restart_timer is replaced by a delayed
work.

[1] victronenergy/venus#24

Signed-off-by: Sergei Miroshnichenko <sergeimir@emcraft.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant