No, I think the fix is fine.
> We cannot leave atomic_read(&sk->wmem_alloc) >= sk->sndbuf here
Why? The "sndbuf" should be considered to be purely advisory.
> (it can occur, if sk->wmem_alloc was increased by another process while sleep),
> because it would block subsequent sock_alloc_send_skb forever.
No, it should block only until the packet has been sent. The bug is
something else - like the write allocation never going away or something.
It looks like sock_kmalloc() is just completely broken as designed, and
should just be removed: there is one user of it, but it should probably
use sock_wmalloc() instead which fixes up the counts correctly by having a
correct skb->destroy function.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu