aboutsummaryrefslogtreecommitdiffstats
path: root/block/elevator.c
diff options
context:
space:
mode:
authorNeil Horman <nhorman@tuxdriver.com>2007-04-26 13:47:36 -0400
committerJeff Garzik <jeff@garzik.org>2007-04-27 20:16:41 -0400
commitdc5a144991ba803bc8afded105c9db1dea0e57ab (patch)
tree81366a449cc3236446f7d84523e35eb260cfb524 /block/elevator.c
parent1764f15016fea54db723a96234a82646dac9a036 (diff)
downloadmrst-s0i3-test-dc5a144991ba803bc8afded105c9db1dea0e57ab.tar.gz
mrst-s0i3-test-dc5a144991ba803bc8afded105c9db1dea0e57ab.tar.xz
mrst-s0i3-test-dc5a144991ba803bc8afded105c9db1dea0e57ab.zip
sis900: Allocate rx replacement buffer before rx operation
Just found a hole in my last patch. It was reported to me that shortly after we integrated this patch. The report was of an oops that took place inside of netif_rx when using the sis900 driver. Looking at my origional patch I noted that there was a spot between the new skb_alloc and the refill_rx_ring label where skb got reassigned to the pointer currently held in the rx_ring for the purposes of receiveing the frame. The result of this is however that the buffer that gets passed to netif_rx (if it is called), then gets placed right back into the rx_ring. So if you receive frames fast enough the skb being processed by the network stack can get corrupted. The reporter is testing out the fix I've written for this below (I'm not near my hardware at the moment to test myself), but I wanted to post it for review ASAP. I'll post test results when I hear them, but I think this is a pretty straightforward fix. It just uses a separate pointer to do the rx operation, so that we don't improperly reassign the pointer that we use to refill the rx ring. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
Diffstat (limited to 'block/elevator.c')
0 files changed, 0 insertions, 0 deletions