diff options
author | Francois Romieu <romieu@fr.zoreil.com> | 2017-03-11 19:41:36 -0500 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2017-03-13 15:37:29 -0700 |
commit | c55fa3cccbc2c672e7f118be8f7484e53a8e9e77 (patch) | |
tree | 06147d1603162f9c84a5f2970db5884c2090aba8 /scripts/sign-file.c | |
parent | be086e7c53f1fac51eed14523b28f2214b548dd2 (diff) | |
download | talos-obmc-linux-c55fa3cccbc2c672e7f118be8f7484e53a8e9e77.tar.gz talos-obmc-linux-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 'scripts/sign-file.c')
0 files changed, 0 insertions, 0 deletions