Hi,
>>>>> "kuznet" == kuznet <kuznet@ms2.inr.ac.ru> writes:
kuznet> Hello!
>> atomic_inc(&sk->protinfo.x25->kick_it);
>> if((atomic_read(&sk->protinfo.x25->kick_it)) != 1) return;
>>
>> do { __x25_kick(sk); } while
>> (!atomic_dec_and_test(&sk->protinfo.x25->kick_it));
kuznet> This looks strange.
kuznet> Why not to use normal socket lock? Look at tcp. After this
kuznet> you will be able to get rid of BKL and old_ones lock at
kuznet> least.
Well, I first tried to wrap the __x25_kick() inside bh_lock_sock(sk),
but that did not work -- it could not because on non-SMP, bh_lock_sock()
is a noop (on SMP, as bh_lock_sock() only sets a spinlock but does not
disable local bh/soft_irq, this naive approach could even dead lock itself).
I guess IŽd also need to call lock_sock() from sendmsg(). And before
calling x25_kick from socket input path, IŽd need to verify that
sk->lock.users is zero. If sk->lock.users was !=0, IŽd need some atomic
variable anyway in order to defer the kick. But once I provide such
atomic variable, I wonŽt need the [bh_]lock_sock any longer for
serializing the kick. Well, maybe my solution could still be simplified
(maybe some test_and_set/clear_bit() magic could achieve the same).
Anyway, while it will still be worth to apply socket lock for making
AF_X25 more SMP friendly, my impression was that the kick serialization
was independent of the sock locking. But as we are already speaking about
lock_sock(): How does one migrate a protocol stack to use sock lock
instead of BKL? Is the following right?
- introduce a protocol-global spinlock and protect protocol-global
critical section by spin_lock_bh() instead of cli()
- protect all sock proto_ops methods by lock_sock()
- when bh functions need to be protected from sk state change, they
need to aquire bh_lock_sock()
- before bh (timer) function change sk state, they need to aquire
bh_lock_sock and verify, that sk->lock.users!=0
- remove the SOCKOPS_WRAPPED() macro from the proto_ops
Can NET_TX_SOFTIRQ be prempted by NET_RX_SOFTIRQ or timer?
Henner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:11 EST