It isn't. I've looked at it a lot more, and the synchronize_bh() thing was
definitely a mistake.
The reason for synchronize_bh() existing is that while del_timer() is safe
in itself, the problem is that there are callers that expect that once
del_timer() has been called it can no longer be running. Without the
synchronize_bh() that is certainly not true, because the timer might be
running on another CPU as we tried to delete it.
However, it turns out that the synchronization has to be done at a higher
level anyway (and in most cases I've looked at it _is_ done at a higher
level already, the other cases I've seen were unaffected by a timer being
run concurrently). So removing it is correct.
> I tried to make add_timer/del_timer/mod_timer callable from any context,
> including the timer handler for the timer itself. Wouldn't del_timer
> deadlock if it was called from a timer handler with the synchronize_bh in?
> (I may have misread the synchronize_bh function).
No, synchronize_bh() will make sure that it doesn't deadlock on itself.
However, it _can_ certainly deadlock if there are other locks involved,
and that, I suspect, is the reason for this one. There are entities
holding various spinlocks while calling del_timer(), and they really don't
want to synchronize with bh's.
In short, it's been removed since yesterday in my tree, and I've also been
able to come up with reasons why it reall yhas to be removed. It had a
good reason for being there, but certainly not nearly good enough.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html