aboutsummaryrefslogtreecommitdiffstats
path: root/README
diff options
context:
space:
mode:
authorFrancois Romieu <romieu@fr.zoreil.com>2017-03-11 19:41:36 -0500
committerDavid S. Miller <davem@davemloft.net>2017-03-13 15:37:29 -0700
commitc55fa3cccbc2c672e7f118be8f7484e53a8e9e77 (patch)
tree06147d1603162f9c84a5f2970db5884c2090aba8 /README
parentqed*: Utilize Firmware 8.15.3.0 (diff)
downloadlinux-dev-c55fa3cccbc2c672e7f118be8f7484e53a8e9e77.tar.xz
linux-dev-c55fa3cccbc2c672e7f118be8f7484e53a8e9e77.zip
atm: remove an unnecessary loop
Andrey reported this kernel warning: WARNING: CPU: 0 PID: 4114 at kernel/sched/core.c:7737 __might_sleep+0x149/0x1a0 do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff813fcb22>] prepare_to_wait+0x182/0x530 The deeply nested alloc_skb is a problem. Diagnosis: nesting is wrong. It makes zero sense. Fix it and the implicit task state change problem automagically goes away. alloc_skb() does not need to be in the "while" loop. alloc_skb() does not need to be in the {prepare_to_wait/add_wait_queue ... finish_wait/remove_wait_queue} block. I claim that: - alloc_tx() should only perform the "wait_for_decent_tx_drain" part - alloc_skb() ought to be done directly in vcc_sendmsg - alloc_skb() failure can be handled gracefully in vcc_sendmsg - alloc_skb() may use a (m->msg_flags & MSG_DONTWAIT) dependent GFP_{KERNEL / ATOMIC} flag Reported-by: Andrey Konovalov <andreyknvl@google.com> Reviewed-and-Tested-by: Chas Williams <3chas3@gmail.com> Signed-off-by: Chas Williams <3chas3@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'README')
0 files changed, 0 insertions, 0 deletions