Re: [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()

Ingo Molnar a écrit :
* Eric Dumazet <dada1@xxxxxxxxxxxxx> wrote:

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.

Yes, this error was corrected by Andi already :)

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/

Relevant Pages

  • Re: [PATCH] tracing/function-return-tracer: dont trace kfree while it frees the return stack
    ... Ingo Molnar a écrit: ... Even if the noret code path will not be traced, we are loosing some traces. ... That should be fixed with the patch below. ... Subject: tracing/function-return-tracer: Free the return stack on free_task ...
    (Linux-Kernel)
  • 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] m68knommu: add pretty back strace
    ... The backtrace shows resolved function names and their numeric ... This is really not my area, but this patch reminds me of all the dwarf2 unwinder on x86 that caused so many problems in the beginning... ... The old method printed every value from stack which was in the text ... find a pattern without frame pointers but I had no luck. ...
    (Linux-Kernel)