[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20170531.143738.91013741875059886.davem@davemloft.net>
Date: Wed, 31 May 2017 14:37:38 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: baijiaju1990@....com
Cc: benve@...co.com, _govind@....com, neepatel@...co.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] enic: Fix a sleep-in-atomic bug
From: Jia-Ju Bai <baijiaju1990@....com>
Date: Wed, 31 May 2017 10:34:49 +0800
> The driver may sleep under a spin lock in some function call paths.
> The 1st function call path is:
> enic_reset (acquire the lock by spin_lock)
> enic_stop
> enic_synchronize_irqs
> synchronize_irq --> may sleep
> The 2nd function call path is:
> enic_reset (acquire the lock by spin_lock)
> enic_dev_soft_reset
> enic_dev_wait
> schedule_timeout_uninterruptible --> may sleep
> The 3rd function call path is:
> enic_reset (acquire the lock by spin_lock)
> enic_open
> enic_request_intr
> enic_set_rx_cpu_rmap
> enic_free_rx_cpu_rmap
> free_irq_cpu_rmap --> may sleep
>
> To fix it, the "spin_lock" and "spin_unlock" are removed in enic_reset.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@....com>
That's not necessarily safe at all, the lock is probably needed for
synchronization.
Powered by blists - more mailing lists