Re: [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
- From: Eric Dumazet <dada1@xxxxxxxxxxxxx>
- Date: Mon, 31 Mar 2008 12:01:16 +0200
Ingo Molnar a écrit :
* Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote:Yes, this error was corrected by Andi already :)
I noticed some paths in kernel are very stack aggressive, and on i386 with CONFIG_4KSTACKS we were really in a dangerous land, even without my patch.
What we call 4K stacks is in fact 4K - sizeof(struct task_struct), so a litle bit more than 2K. [...]
that's just wrong - 4K stacks on x86 are 4K-sizeof(thread_info) - the task struct is allocated elsewhere. The patch below runs just fine on 4K-stack x86.
Thank you Ingo but this patch was already suggested by me previously ( http://marc.info/?l=linux-netdev&m=120361996713007&w=2 ) and was rejected, since we can very easily consume all stack space, especially with 4K stacks.
(try with NFS mounts and XFS for example)
Only safe way is to check available free stack space, since we can nest loopback_xmit() several time.
In case of protocol errors (like in TCP, if we answer to an ACK by another ACK, or ICMP loops), we would exhaust stack instead of delaying packets for next softirq run.
Problem is to check available space :
It depends on stack growing UP or DOWN, and depends on caller running on process stack, or softirq stack, or even hardirq stack.
Ingo
------------->
Subject: net: loopback speedup
From: Ingo Molnar <mingo@xxxxxxx>
Date: Mon Mar 31 11:23:21 CEST 2008
Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
---
drivers/net/loopback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/drivers/net/loopback.c
===================================================================
--- linux.orig/drivers/net/loopback.c
+++ linux/drivers/net/loopback.c
@@ -158,7 +158,7 @@ static int loopback_xmit(struct sk_buff lb_stats->bytes += skb->len;
lb_stats->packets++;
- netif_rx(skb);
+ netif_receive_skb(skb);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- References:
- Prev by Date: Re: [PATCH] x86: create array based interface to change page attribute
- Next by Date: Re: [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
- Previous by thread: Re: [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
- Next by thread: Re: [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
- Index(es):
Relevant Pages
- Re: Wine and mmap
... Apply the attached patch for vm_mmap to ... > compile and install wine.
... This seems to just work around a side effect of the kernel mmap patch. ... *
top of the main stack. ... (freebsd-current) - Re: RFC: TSO patch for current
... > This is a patch for the stack and the em driver to enable TSO
... (freebsd-current) - Re: RFC: TSO patch for current
... > This is a patch for the stack and the em driver to enable TSO
... (freebsd-net) - Re: [PATCH] i386: Fix softirq accounting with 4K stacks
... since the "is a softirq executing" bit is on the stack, ... Mike's patch
removed the #ifdef CONFIG_SMP ... doesn't that mean that mean that hardirq accounting
is still broken? ... APIC irq comes in, increases hardirq count, then the timer irq fires,
... (Linux-Kernel) - Re: About 4k kernel stack size....
... >> they have) will not be able to use their wireless cards when this patch ...
Why would they want to use ndiswrapper (= binary ... The attached patch will poison
the user-to-kernel stack with the letters ... (Linux-Kernel)