Re: Deadlock in 2.2 sock_alloc_send_skb?

2001-05-11 Thread Andi Kleen
On Thu, May 10, 2001 at 11:32:25PM +0200, Andrea Arcangeli wrote: > you said interrupt won't call that function so I don't see the > GFP_ATOMIC issue. I said interrupts should not call it, but apparently somebody tries to call it with GFP_ATOMIC and I'm suspecting that caller is broken (whatever

Re: Deadlock in 2.2 sock_alloc_send_skb?

2001-05-10 Thread Andrea Arcangeli
On Thu, May 10, 2001 at 11:17:17PM +0200, Andi Kleen wrote: > On Thu, May 10, 2001 at 11:13:00PM +0200, Andrea Arcangeli wrote: > > On Thu, May 10, 2001 at 07:30:47PM +0200, Andi Kleen wrote: > > > On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote: > > > > > If that happens, and the socket

Re: Deadlock in 2.2 sock_alloc_send_skb?

2001-05-10 Thread Andi Kleen
On Thu, May 10, 2001 at 11:13:00PM +0200, Andrea Arcangeli wrote: > On Thu, May 10, 2001 at 07:30:47PM +0200, Andi Kleen wrote: > > On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote: > > > > If that happens, and the socket uses GFP_ATOMIC allocation, the while (1) > > > > loop in sock_alloc

Re: Deadlock in 2.2 sock_alloc_send_skb?

2001-05-10 Thread Andrea Arcangeli
On Thu, May 10, 2001 at 07:30:47PM +0200, Andi Kleen wrote: > On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote: > > > If that happens, and the socket uses GFP_ATOMIC allocation, the while (1) > > > loop in sock_alloc_send_skb() will endlessly spin, without ever calling > > > schedule(), an

Re: Deadlock in 2.2 sock_alloc_send_skb?

2001-05-10 Thread Andi Kleen
On Thu, May 10, 2001 at 01:57:49PM +0100, Alan Cox wrote: > > If that happens, and the socket uses GFP_ATOMIC allocation, the while (1) > > loop in sock_alloc_send_skb() will endlessly spin, without ever calling > > schedule(), and all the time holding the kernel lock ... > > If the socket is usi

Re: Deadlock in 2.2 sock_alloc_send_skb?

2001-05-10 Thread Alan Cox
> If that happens, and the socket uses GFP_ATOMIC allocation, the while (1) > loop in sock_alloc_send_skb() will endlessly spin, without ever calling > schedule(), and all the time holding the kernel lock ... If the socket is using GFP_ATOMIC allocation it should never loop. That is -not-allowed-

Deadlock in 2.2 sock_alloc_send_skb?

2001-05-10 Thread Ulrich . Weigand
Hi Alan, we've experienced deadlocks that appear to be caused by the loop in sock_alloc_send_skb(). To trigger this, you need to combine heavy network load with memory pressure. In this situation, sock_wmalloc() can fail because it really can't allocate any more memory, even though the send b