Re: [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
- From: David Miller <davem@xxxxxxxxxxxxx>
- Date: Mon, 31 Mar 2008 03:08:48 -0700 (PDT)
From: Ingo Molnar <mingo@xxxxxxx>
Date: Mon, 31 Mar 2008 11:48:23 +0200
* 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.
I don't think it's safe.
Every packet you receive can result in a sent packet, which
in turn can result in a full packet receive path being
taken, and yet again another sent packet.
And so on and so forth.
Some cases like this would be stack bugs, but wouldn't
you like that bug to be a very busy cpu instead of a
crash from overrunning the current stack?
--
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: [RFC,PATCH] loopback: calls netif_receive_skb() instead of netif_rx()
- Next by Date: Re: [PATCH,TRIVIAL] AF_UNIX, accept() and addrlen
- 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
- [PATCH] Part 1 of low level 802.1p priority support
... Here is the first patch to bring in 802.1p Packet Priority to FreeBSD; this
is to support Differentiated Services and Quality-of-Service. ... This first stage enables
FreeBSD to pass packets for 802.1q with VLAN 0 to the main input path in the stack, which is the
IEEE standards-compliant behaviour. ... (freebsd-net) - Re: Packet loss every 30.999 seconds
... Just to confirm the patch did not change the behavior. ... It looks like if
you put the check at the top of the loop and the next node ... to increment if_ipackets
but still lose the packet. ... not trigger the problem, but also be high enough to not
significantly ... (freebsd-net) - Re: Packet loss every 30.999 seconds
... Just to confirm the patch did not change the behavior. ... It looks like if
you put the check at the top of the loop and the next node ... to increment if_ipackets
but still lose the packet. ... not trigger the problem, but also be high enough to not
significantly ... (freebsd-stable) - [PATCH 2/2 - 2.6.11.7] x25: Fast select with no restriction on response
... This patch is a follow up to the 'resend' version of the "Selective Sub Address ...
It allows use of the Fast-Select-Acceptance ... Recomendation 10/96 section 6.16) is that
if in an incoming call packet, ... but before a listen system call is made, the
following ioctl should be used. ... (Linux-Kernel) - [PATCH 2/2-2.6.11.8]x25: Fast select with no restriction on response
... This patch is a follow up to patch 1 regarding "Selective Sub Address ... It
allows use of the Fast-Select-Acceptance ... Recomendation 10/96 section 6.16) is that
if in an incoming call packet, ... but before a listen system call is made, the
following ioctl should be used. ... (Linux-Kernel)
