summaryrefslogtreecommitdiff
path: root/mm
diff options
context:
space:
mode:
authorSantiago Leon <santil@us.ibm.com>2006-10-03 17:24:45 (GMT)
committerJeff Garzik <jeff@garzik.org>2006-10-05 10:43:24 (GMT)
commit751ae21c6cd1493e3d0a4935b08fb298b9d89773 (patch)
treef0cd58c2c357101b6f6cf610221cceca3f6eef9c /mm
parent03a85d0907b2455c772b8fb179b0c07a66b00ddb (diff)
downloadlinux-751ae21c6cd1493e3d0a4935b08fb298b9d89773.tar.xz
[PATCH] ibmveth: fix int rollover panic
This patch fixes a nasty bug that has been sitting there since the very first versions of the driver, but is generating a panic because we changed the number of 2K buffers for 2.6.16. The consumer_index and producer_index are u32's that get incremented on every buffer emptied and replenished respectively. We use the {producer,consumer}_index mod'ed with the size of the pool to pick out an entry in the free_map. The problem happens when the u32 rolls over and the number of the buffers in the pool is not a perfect divisor of 2^32. i.e. if the number of 2K buffers is 0x300, before the consumer_index rolls over, our index to the free map = 0xffffffff mod 0x300 = 0xff. The next time a buffer is emptied, we want the index to the free map to be 0x100, but 0x0 mod 0x300 is 0x0. This patch assigns the mod'ed result back to the consumer and producer indexes so that they never roll over. The second chunk of the patch covers the unlikely case where the consumer_index has just been reset to 0x0 and the hypervisor is not able to accept that buffer. Signed-off-by: Santiago Leon <santil@us.ibm.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions