Hello,
>>>>> "kuznet" == kuznet <kuznet@xxxxxxxxxxxxx> writes:
kuznet> Sorry? This thing is called O_NONBLOCK. sndtimeo is
kuznet> additional baroque detail, which is not used provided you
kuznet> do not touch it. Do not touch it.
Well, I was aware of that. The sndtimeo trick was just a very dirty hack
not intended for final version (and not future-proof;). The reason why
I used it was that by setting sndtimeo to 0, it would make all
sock_alloc_snd_skb() non-blocking, while O_NONBLOCK has to passed as a
parameter and thus might require to consider all sock_alloc_send_skb()
calls in a protocol stack.
kuznet> What's about calling from interrupts (not the case with
kuznet> nbd),
If ndb does not call sendmsg from interrupt, sleeping inside sndmsg()
is probably not a problem per se. Is it only the sleep while waiting
for GFP_KERNEL memory allocation which causes the deadlock problems?
kuznet> no tricks will help. It is simply impossible to use
kuznet> top level syscall from interrupt.
Yes -- and for my tunneling scenario, I do not do top level syscalls
from bh context anyway. The sock_alloc_send_skb() which needed to be rendered
non-blocking was used for a fragemt allocation. For this, the sk->allocation
trick was sufficient.
Henner
|