padata: Use a timer to handle remaining objects in the reorder queues
authorSteffen Klassert <steffen.klassert@secunet.com>
Wed, 19 May 2010 03:43:14 +0000 (13:43 +1000)
committerHerbert Xu <herbert@gondor.apana.org.au>
Wed, 19 May 2010 03:43:14 +0000 (13:43 +1000)
commitd46a5ac7a7e2045e33c6ad6ffb8cf18a7e86a15a
tree2ccfba3ee24ed28e80ae3e3be330a7b44f77dbcf
parent18eb8ea6ee4cc9ed39b45f95b734f523bcfb586b
padata: Use a timer to handle remaining objects in the reorder queues

padata_get_next needs to check whether the next object that
need serialization must be parallel processed by the local cpu.
This check was wrong implemented and returned always true,
so the try_again loop in padata_reorder was never taken. This
can lead to object leaks in some rare cases due to a race that
appears with the trylock in padata_reorder. The try_again loop
was not a good idea after all, because a cpu could take that
loop frequently, so we handle this with a timer instead.

This patch adds a timer to handle the race that appears with
the trylock. If cpu1 queues an object to the reorder queue while
cpu2 holds the pd->lock but left the while loop in padata_reorder
already, cpu2 can't care for this object and cpu1 exits because
it can't get the lock. Usually the next cpu that takes the lock
cares for this object too. We need the timer just if this object
was the last one that arrives to the reorder queues. The timer
function sends it out in this case.

Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
include/linux/padata.h
kernel/padata.c