summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-postgresql.py
diff options
context:
space:
mode:
authorDmitry Bogdanov <dmitry.bogdanov@aquantia.com>2019-08-30 15:08:38 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2019-09-21 08:17:10 +0300
commit83360eb798cadc85de08db3f2219dfc656ff2a49 (patch)
tree7cd11e794523d88ef82c5949fdffc3c306b55b57 /tools/perf/scripts/python/export-to-postgresql.py
parent30c345bd786abe5db70711dbd3f5fceb5ca4d36c (diff)
downloadlinux-83360eb798cadc85de08db3f2219dfc656ff2a49.tar.xz
net: aquantia: fix out of memory condition on rx side
[ Upstream commit be6cef69ba570ebb327eba1ef6438f7af49aaf86 ] On embedded environments with hard memory limits it is a normal although rare case when skb can't be allocated on rx part under high traffic. In such OOM cases napi_complete_done() was not called. So the napi object became in an invalid state like it is "scheduled". Kernel do not re-schedules the poll of that napi object. Consequently, kernel can not remove that object the system hangs on `ifconfig down` waiting for a poll. We are fixing this by gracefully closing napi poll routine with correct invocation of napi_complete_done. This was reproduced with artificially failing the allocation of skb to simulate an "out of memory" error case and check that traffic does not get stuck. Fixes: 970a2e9864b0 ("net: ethernet: aquantia: Vector operations") Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com> Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions