diff options
author | Andrea Merello <andrea.merello@gmail.com> | 2017-07-08 10:11:11 +0200 |
---|---|---|
committer | Mathias Kresin <dev@kresin.me> | 2017-07-20 19:10:29 +0200 |
commit | b81c04382b5ddea0164993c2af0df7270bb95ee4 (patch) | |
tree | 0d277e90337a8c8ef304da6e6c93ef0c376510aa /target/linux/ramips/base-files | |
parent | 34c01e68b5d6b06ce3794ef0e2b06e81ec3ce8ca (diff) | |
download | upstream-b81c04382b5ddea0164993c2af0df7270bb95ee4.tar.gz upstream-b81c04382b5ddea0164993c2af0df7270bb95ee4.tar.bz2 upstream-b81c04382b5ddea0164993c2af0df7270bb95ee4.zip |
lantiq: fix sleep with spinlock held in xrx200 network driver
In the xrx200_close() function we call napi_disable(), that could
sleep, with priv->hw->chan[i].lock held. This could lead to deadlock
and causes the kernel to complain.
Look at the code I couldn't convince myself about why we
need to protect that specific code part with the lock. IMHO there
seems no reason to protect the refcount variables, because AFAIK
ndo_close() and ndo_open() callbacks are already called with a
semaphore held. Neither I could figure out why napi_disable() have to
be called with that lock held. The only remaining code part for
which I could guess the lock is useful for is ltq_dma_close()
function call.
This patch reduces the lock to the said function call, avoiding the
sleep-with-spinlock-held situation
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
[fold into 0025-NET-MIPS-lantiq-adds-xrx200-net.patch, backport to
kernel 4.4]
Signed-off-by: Mathias Kresin <dev@kresin.me>
Diffstat (limited to 'target/linux/ramips/base-files')
0 files changed, 0 insertions, 0 deletions