Messages in this thread | | | Date | Thu, 29 Apr 2010 16:06:44 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 6/8] padata: Use a timer to handle the reorder queues |
| |
On Thu, 29 Apr 2010 14:43:37 +0200 Steffen Klassert <steffen.klassert@secunet.com> wrote:
> padata_get_next had a bogus check that returned always true, > so the try_again loop in padata_reorder was never taken.
A better changelog would have told us what this "bogus check" _is_.
> This can lead to object leaks in some rare cases.
And a better changelog would describe those leaks!
> This patch > implements a timer that processes the reorder queues if noone > else does it in appropriate time.
Under what circumstances would "noone else do it in appropriate time"? Would that be a bug, or what?
> @@ -273,13 +274,22 @@ try_again: > > spin_unlock_bh(&pd->lock); > > - if (atomic_read(&pd->reorder_objects)) > - goto try_again; > + if (atomic_read(&pd->reorder_objects) > + && !(pinst->flags & PADATA_RESET)) > + mod_timer(&pd->timer, jiffies + HZ); > + else > + del_timer(&pd->timer); > > -out: > return; > }
I'd feel more comfortable if the above was in the locked region. Is there a race whereby another CPU can set pd->reorder_objects, but we forgot to arm the timer?
| |