On Tue, Apr 15, 2014 at 8:14 AM, Eric Dumazet wrote:
>
> Zhan, could you try following patch, thanks !
>
> drivers/net/vxlan.c |4 ++--
> include/net/dst.h | 14 +++---
> include/net/inet6_connection_sock.h |2 +-
> include/net/inet_connection_s
On Mon, 2014-04-14 at 18:51 -0400, David Miller wrote:
> From: Eric Dumazet
> Date: Mon, 14 Apr 2014 14:23:24 -0700
>
> > I was trying to cook a not too invasive patch.
> >
> > Changing ip_local_out() means changing dst_output() / nf_hook() and
> > hundred of call sites.
> >
> > Unless I misun
From: Eric Dumazet
Date: Mon, 14 Apr 2014 14:23:24 -0700
> I was trying to cook a not too invasive patch.
>
> Changing ip_local_out() means changing dst_output() / nf_hook() and
> hundred of call sites.
>
> Unless I misunderstood you ?
You could make ip_local_out(skb) be __ip_local_out(skb, s
On Mon, 2014-04-14 at 15:22 -0400, David Miller wrote:
>
> You still need to make similar transformation to ip_local_out() as mentioned
> above.
I was trying to cook a not too invasive patch.
Changing ip_local_out() means changing dst_output() / nf_hook() and
hundred of call sites.
Unless I
From: Eric Dumazet
Date: Mon, 14 Apr 2014 12:06:36 -0700
> On Mon, 2014-04-14 at 14:48 -0400, David Miller wrote:
>> From: Eric Dumazet
>> Date: Mon, 14 Apr 2014 11:19:26 -0700
>>
>> > ip_local_out() doesn't use skb->sk
>>
>> It does Eric.
>>
>
> Hmmm, right...
>
>> We had just such a repor
On Mon, 2014-04-14 at 14:48 -0400, David Miller wrote:
> From: Eric Dumazet
> Date: Mon, 14 Apr 2014 11:19:26 -0700
>
> > ip_local_out() doesn't use skb->sk
>
> It does Eric.
>
Hmmm, right...
> We had just such a report with this in the backtrace, when AF_PACKET
> sends over vxlan devices.
>
From: Eric Dumazet
Date: Mon, 14 Apr 2014 11:19:26 -0700
> ip_local_out() doesn't use skb->sk
It does Eric.
We had just such a report with this in the backtrace, when AF_PACKET
sends over vxlan devices.
The problem is ip_mc_output().
--
To unsubscribe from this list: send the line "unsubscribe
On Mon, 2014-04-14 at 14:02 -0400, David Miller wrote:
> BTW, it occurs to me that there may be some other spots in the output path
> that expect that if SKB is ETH_P_IP then skb->sk is IP socket. For example
> somewhere in netfilter or packet classifier paths.
>
> Just FYI... that was one of th
From: Eric Dumazet
Date: Mon, 14 Apr 2014 10:54:42 -0700
> On Mon, 2014-04-14 at 13:49 -0400, David Miller wrote:
>
>> Yep that would handle the l2tp cases, but vxlan needs something different
>> since it goes through iptunnel_xmit().
>>
>> So perhaps as a quick fix we can add an 'sk' arg to bo
On Mon, 2014-04-14 at 13:49 -0400, David Miller wrote:
> Yep that would handle the l2tp cases, but vxlan needs something different
> since it goes through iptunnel_xmit().
>
> So perhaps as a quick fix we can add an 'sk' arg to both
> ip_queue_xmit() and ip_local_out().
Right, I am working on th
From: Eric Dumazet
Date: Mon, 14 Apr 2014 10:40:04 -0700
> On Mon, 2014-04-14 at 13:34 -0400, David Miller wrote:
>> From: Eric Dumazet
>> Date: Mon, 14 Apr 2014 10:12:29 -0700
>>
>> > Hmm, it seems commit 31c70d5956fc l2tp: keep original skb ownership
>> > is the problem.
>> >
>> > ip_queue_x
On Mon, 2014-04-14 at 13:34 -0400, David Miller wrote:
> From: Eric Dumazet
> Date: Mon, 14 Apr 2014 10:12:29 -0700
>
> > Hmm, it seems commit 31c70d5956fc l2tp: keep original skb ownership
> > is the problem.
> >
> > ip_queue_xmit() assumes the socket attached to skb is an inet socket.
>
> Thi
From: Eric Dumazet
Date: Mon, 14 Apr 2014 10:12:29 -0700
> Hmm, it seems commit 31c70d5956fc l2tp: keep original skb ownership
> is the problem.
>
> ip_queue_xmit() assumes the socket attached to skb is an inet socket.
This is similar to the "send over AF_PACKET" issue we were discussing
the ot
On Tue, 2014-04-15 at 01:01 +0800, Zhan Jianyu wrote:
> On Mon, Apr 14, 2014 at 11:19 PM, James Chapman wrote:
> > Please send the complete oops message.
>
> Hi, complete oops message is :
>
>
> [ 100.243737] BUG: unable to handle kernel NULL pointer dereference
> at 02c0
> [ 100.
On Mon, Apr 14, 2014 at 11:19 PM, James Chapman wrote:
> Please send the complete oops message.
Hi, complete oops message is :
[ 100.243737] BUG: unable to handle kernel NULL pointer dereference
at 02c0
[ 100.244985] IP: [] ip_queue_xmit+0x20/0x3e0
[ 100.262266] PGD 0
[ 100.2883
Please send the complete oops message.
Is this a regression? If so, do you know what the last kernel version
was that worked?
Thanks
James
On 14/04/14 14:33, Zhan Jianyu wrote:
> When I tried to connect my VPN, I got a panic, saying
> a NULL poiter dereference at 0x02c0
>
> I came a
16 matches
Mail list logo