Hello!
> I wish Alexey were around to comment,
Well, Andrew, you are not the first who is bothered with this problem.
This bug existed in the same form in 2.1, it exists in 2.2 as well.
Actually, in 2.1 for some time del_timer() contained synchronize_bh()
exactly to avoid fixing these 250 places. I even do not know, when
it disappeared (apparently that solution was inclined to deadlocks),
it was surprise for me. Well, it was wrong in any case.
In 2.2 moral equivalent of del_timer_sync() is:
start_bh_atomic();
del_timer();
end_bh_atomic();
rather than:
del_timer();
synchronize_bh();
And wait_on_timers() is meaningless exactly by the same reason:
periodic timer can be restarted after del_timer().
What's about solution with waiting inside del_timer()...
Synchronous del_timer() is inclined to deadlocks, so that
you will not avoid auditing all these 256 places. 8)
About your analysis: _ALL_ the del_timer()'s in
net/{core,ipv4,ipv6,packet,netlink,sched,unix} are "asynchronous"
on your language and should be replaced with del_timer_async().
I not quite understood the problems, which you found there.
Please, explain.
Alexey
-
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.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:16 EST