diff options
author | Frank Pavlic <fpavlic@de.ibm.com> | 2006-09-15 16:26:19 +0200 |
---|---|---|
committer | Jeff Garzik <jeff@garzik.org> | 2006-09-17 01:03:07 -0400 |
commit | f7b65d70a3e6f1c97eb614964270816992d0d4b4 (patch) | |
tree | fae68b2d6c215abacd3074b81bc320f5b3e3a0e0 /arch/um | |
parent | 1fda1a120b7dcddf382ad105b4783a69e81c7a2b (diff) | |
download | kernel_samsung_crespo-f7b65d70a3e6f1c97eb614964270816992d0d4b4.zip kernel_samsung_crespo-f7b65d70a3e6f1c97eb614964270816992d0d4b4.tar.gz kernel_samsung_crespo-f7b65d70a3e6f1c97eb614964270816992d0d4b4.tar.bz2 |
[PATCH] s390: qeth driver fixes [3/6]
[PATCH 6/9] s390: qeth driver fixes [3/6]
From: Frank Pavlic <fpavlic@de.ibm.com>
fixed kernel panic caused by qeth driver:
Using a bonding device qeth driver will realloc
headroom for every skb coming from the bond device.
Once this happens qeth frees the original skb and
set the skb pointer to the new realloced skb.
Under heavy transmit workload (e.g.UDP streams) through bond
network device the qdio output queue might get full.
In this case we return with EBUSY from qeth_send_packet.
Returning to qeth_hard_start_xmit routine
the skb address on the stack still points to the old address,
which has been freed before.
Returning from qeth_hard_start_xmit with EBUSY results in
requeuing the skb. In this case it corrupts the qdisc queue
and results in kernel panic.
Signed-off-by: Frank Pavlic <fpavlic@de.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Diffstat (limited to 'arch/um')
0 files changed, 0 insertions, 0 deletions