Simon, can you test this patch? I think it's the most straightforward
2.6.24 fix.
diff -r c60016ba6237 net/core/netpoll.c
--- a/net/core/netpoll.cTue Nov 13 09:09:36 2007 -0800
+++ b/net/core/netpoll.cFri Nov 23 13:10:28 2007 -0600
@@ -203,6 +203,12 @@ static void
Simon, can you test this patch? I think it's the most straightforward
2.6.24 fix.
diff -r c60016ba6237 net/core/netpoll.c
--- a/net/core/netpoll.cTue Nov 13 09:09:36 2007 -0800
+++ b/net/core/netpoll.cFri Nov 23 13:10:28 2007 -0600
@@ -203,6 +203,12 @@ static void
On Fri, Nov 23, 2007 at 10:54:11PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 01:41:39PM -0600, Matt Mackall ([EMAIL PROTECTED])
> wrote:
> > Here's another thought: move all this logic into the networking core,
> > unify it with current softirq zapper, then allow it to be called
On Fri, Nov 23, 2007 at 10:54:10PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> On Fri, Nov 23, 2007 at 01:41:39PM -0600, Matt Mackall ([EMAIL PROTECTED])
> wrote:
> > Here's another thought: move all this logic into the networking core,
> > unify it with current softirq zapper, then
On Fri, Nov 23, 2007 at 01:41:39PM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
> Here's another thought: move all this logic into the networking core,
> unify it with current softirq zapper, then allow it to be called from
> various other places (like atomic allocators). Then it'll all be in
>
On Fri, Nov 23, 2007 at 10:32:22PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 01:11:20PM -0600, Matt Mackall ([EMAIL PROTECTED])
> wrote:
> > On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote:
> > > On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL
>
On Fri, Nov 23, 2007 at 01:11:20PM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
> On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote:
> > On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL
> > PROTECTED]) wrote:
> > > On Fri, Nov 23, 2007 at 09:48:51PM +0300,
On Fri, Nov 23, 2007 at 10:15:24PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 12:59:43PM -0600, Matt Mackall ([EMAIL PROTECTED])
> wrote:
> > So I'd be surprised if that was a problem. But I can imagine having
> > problems for skbs without destructors which run into one of these in
On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
> > On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL
> > PROTECTED]) wrote:
> > > Stop, we are trying to free skb without
On Fri, Nov 23, 2007 at 12:59:43PM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
> So I'd be surprised if that was a problem. But I can imagine having
> problems for skbs without destructors which run into one of these in
> __kfree_skb:
>
> dst_release
> secpath_put
> nf_conntrack_put
>
On Fri, Nov 23, 2007 at 08:57:57PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 11:07:56AM -0600, Matt Mackall ([EMAIL PROTECTED])
> wrote:
> > On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote:
> > > On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL
> >
On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL
> PROTECTED]) wrote:
> > Stop, we are trying to free skb without destructor and catch connection
> > tracking, so it is not a solution. To
On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> Stop, we are trying to free skb without destructor and catch connection
> tracking, so it is not a solution. To fix the problem we need to check
> if it is not netfilter related, kind of this (not tested),
On Fri, Nov 23, 2007 at 08:57:57PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> > My memory here is hazy, but I think this exists to rescue netconsole
> > in low-memory situations. This bit originated with Ingo, so maybe he
> > can recall.
> >
> > Netpoll can process an arbitrary number
On Fri, Nov 23, 2007 at 11:07:56AM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
> On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote:
> > On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL PROTECTED])
> > wrote:
> > > > [2059664.615816] __iptables__: init4 IN=ppp0
On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote:
> On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL PROTECTED])
> wrote:
> > > [2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at
> > > kernel/softirq.c:139 local_bh_enable()
> > > [2059664.620535]
On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL PROTECTED])
wrote:
> > [2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at
> > kernel/softirq.c:139 local_bh_enable()
> > [2059664.620535] [<80120364>] local_bh_enable+0x3c/0x97
> > [2059664.620657] [<8011c205>]
On Thu, 22 Nov 2007 19:47:35 + Simon Arlott <[EMAIL PROTECTED]> wrote:
> WARN during log message being output to ttyS0 and netconsole:
>
> [2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at
> kernel/softirq.c:139 local_bh_enable()
> [2059664.620535] [<80120364>]
On Thu, 22 Nov 2007 19:47:35 + Simon Arlott [EMAIL PROTECTED] wrote:
WARN during log message being output to ttyS0 and netconsole:
[2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at
kernel/softirq.c:139 local_bh_enable()
[2059664.620535] [80120364]
On Fri, Nov 23, 2007 at 01:11:20PM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote:
On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL
PROTECTED]) wrote:
On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy
On Fri, Nov 23, 2007 at 10:15:24PM +0300, Evgeniy Polyakov wrote:
On Fri, Nov 23, 2007 at 12:59:43PM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
So I'd be surprised if that was a problem. But I can imagine having
problems for skbs without destructors which run into one of these in
On Fri, Nov 23, 2007 at 10:54:11PM +0300, Evgeniy Polyakov wrote:
On Fri, Nov 23, 2007 at 01:41:39PM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
Here's another thought: move all this logic into the networking core,
unify it with current softirq zapper, then allow it to be called from
On Fri, Nov 23, 2007 at 01:41:39PM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
Here's another thought: move all this logic into the networking core,
unify it with current softirq zapper, then allow it to be called from
various other places (like atomic allocators). Then it'll all be in
On Fri, Nov 23, 2007 at 10:32:22PM +0300, Evgeniy Polyakov wrote:
On Fri, Nov 23, 2007 at 01:11:20PM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote:
On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL
On Fri, Nov 23, 2007 at 08:57:57PM +0300, Evgeniy Polyakov wrote:
On Fri, Nov 23, 2007 at 11:07:56AM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote:
On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL
On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL PROTECTED])
wrote:
[2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at
kernel/softirq.c:139 local_bh_enable()
[2059664.620535] [80120364] local_bh_enable+0x3c/0x97
[2059664.620657] [8011c205]
On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote:
On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL PROTECTED])
wrote:
[2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at
kernel/softirq.c:139 local_bh_enable()
[2059664.620535] [80120364]
On Fri, Nov 23, 2007 at 11:07:56AM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
On Fri, Nov 23, 2007 at 01:55:19PM +0300, Evgeniy Polyakov wrote:
On Fri, Nov 23, 2007 at 12:21:57AM -0800, Andrew Morton ([EMAIL PROTECTED])
wrote:
[2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0
On Fri, Nov 23, 2007 at 08:57:57PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
My memory here is hazy, but I think this exists to rescue netconsole
in low-memory situations. This bit originated with Ingo, so maybe he
can recall.
Netpoll can process an arbitrary number of skbs
On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
Stop, we are trying to free skb without destructor and catch connection
tracking, so it is not a solution. To fix the problem we need to check
if it is not netfilter related, kind of this (not tested), Simon
On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL
PROTECTED]) wrote:
Stop, we are trying to free skb without destructor and catch connection
tracking, so it is not a solution. To fix the
On Fri, Nov 23, 2007 at 12:59:43PM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
So I'd be surprised if that was a problem. But I can imagine having
problems for skbs without destructors which run into one of these in
__kfree_skb:
dst_release
secpath_put
nf_conntrack_put
On Fri, Nov 23, 2007 at 09:59:06PM +0300, Evgeniy Polyakov wrote:
On Fri, Nov 23, 2007 at 09:51:01PM +0300, Evgeniy Polyakov ([EMAIL
PROTECTED]) wrote:
On Fri, Nov 23, 2007 at 09:48:51PM +0300, Evgeniy Polyakov ([EMAIL
PROTECTED]) wrote:
Stop, we are trying to free skb without
On Fri, Nov 23, 2007 at 10:54:10PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
On Fri, Nov 23, 2007 at 01:41:39PM -0600, Matt Mackall ([EMAIL PROTECTED])
wrote:
Here's another thought: move all this logic into the networking core,
unify it with current softirq zapper, then allow it
WARN during log message being output to ttyS0 and netconsole:
[2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at
kernel/softirq.c:139 local_bh_enable()
[2059664.620535] [<80120364>] local_bh_enable+0x3c/0x97
[2059664.620553] [<802e3356>] __nf_ct_ext_destroy+0x35/0x5b
WARN during log message being output to ttyS0 and netconsole:
[2059664.615816] __iptables__: init4 IN=ppp0 OUT=ppp0 WARNING: at
kernel/softirq.c:139 local_bh_enable()
[2059664.620535] [80120364] local_bh_enable+0x3c/0x97
[2059664.620553] [802e3356] __nf_ct_ext_destroy+0x35/0x5b
36 matches
Mail list logo