Hello!
> For example, net/ipv6/reassembly.c: fq_free() is sometimes called under
> ip6_frag_lock so it must use del_timer_async(). But fq_free() frees
> resources which the handler references, and so it must use
> del_timer_sync(). And fq_free() can be called from process context, so
> we don't get out of it that way. Fun.
It is _common_ case, unfortunately. The same thing occurs in TCP, by the way.
I used reference counting in such places.
The alternative as formulated by you is not quite correct.
It could be formulated as: del_timer_sync() is used, when we know apriori,
that this timer can be deleted only by _this_ thread, added only by _this_
thread or by timer handler and synchronization will not cause deadlocks.
Does it look complicated? OK, there are two simplifications covering
almost all the cases:
1. The statement about deadlock is trivial, when del_timer_sync() is called
from context free of any spinning locks (it is common case)
and it requires proof in all other cases.
2. The statement "only by this thread" is trivial, when timer is controlled
only from process context and they are serialized with kernel lock
(common over all not-networking) or with a semaphore
(device driver's open/close are called under semaphore).
In all other cases del_timer_async() is used and we have no choice
but to use an external reference count.
Seems, I still hoped to invent some simpler scheme when updated reassembly.c.
and forgot about this. :-(
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:19 EST