[Top] [All Lists]

Re: BUG in tcp.c ?

To: davem@xxxxxxxxxx (David S. Miller)
Subject: Re: BUG in tcp.c ?
From: kuznet@xxxxxxxxxxxxx
Date: Wed, 11 Oct 2000 20:11:57 +0400 (MSK DST)
Cc: eis@xxxxxxxxxxxxx, riel@xxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <> from "David S. Miller" at Oct 10, 0 04:30:37 pm
Sender: owner-netdev@xxxxxxxxxxx

>    Is it only the sleep while waiting for GFP_KERNEL memory allocation
>    which causes the deadlock problems?
> To the best of my understanding, yes, this was nbd's problem
> precisely.

I would add that Andi and Marcelo explained me that problem was not
in sleep, but that GFP_KERNEL tries to shrink vm, which results
in additional writes of cached pages, which in turn...
Actually, it is big relief because trick with sk->allocation really helps.

sendmsg, like any syscall, _sleeps_ and it is impossible to override
with either sk->allocation and O_NONBLOCK. And even if it does
not sleep in fact (f.e. in 2.2 or when socket is used exclusively
by single thread in 2.4) it cannot be called with any spinning lock
hold, from bh etc. Only from thread context free of any locks.

BTW this does not apply to sock_alloc_send_skb, it can be called
from any context provided you take precautions about nonblock,
sk->allocation and do not use fallback.

Only... one question:

#define GFP_BUFFER      (__GFP_HIGH | __GFP_WAIT)

Old days GFP_BUFFER did not sleep.
All the sense of fallback allocation was that it grabs large
buffer provided it can make this without stressing memory.
Should GFP_BUFFER be replaced with 0 now?


<Prev in Thread] Current Thread [Next in Thread>