On Wed, 2016-01-20 at 17:17 +0100, Jacob Siverskog wrote:
> On Wed, Jan 20, 2016 at 4:48 PM, Eric Dumazet wrote:
> > On Wed, 2016-01-20 at 16:06 +0100, Jacob Siverskog wrote:
> >> On Tue, Jan 5, 2016 at 3:39 PM, Eric Dumazet
> >> wrote:
> >> > On Tue, 2016-01-05 at 15:34 +0100, Jacob Siverskog
Hi Jacob,
On 01/05/2016 06:34 AM, Jacob Siverskog wrote:
> On Tue, Jan 5, 2016 at 3:14 PM, Eric Dumazet wrote:
>> On Tue, 2016-01-05 at 12:07 +0100, Jacob Siverskog wrote:
>>> On Mon, Jan 4, 2016 at 4:25 PM, Eric Dumazet wrote:
On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
On Wed, Jan 20, 2016 at 4:48 PM, Eric Dumazet wrote:
> On Wed, 2016-01-20 at 16:06 +0100, Jacob Siverskog wrote:
>> On Tue, Jan 5, 2016 at 3:39 PM, Eric Dumazet wrote:
>> > On Tue, 2016-01-05 at 15:34 +0100, Jacob Siverskog wrote:
>> >> On Tue, Jan 5, 2016 at 3:14 PM, Eric Dumazet
>> >> wrote:
On Wed, 2016-01-20 at 16:06 +0100, Jacob Siverskog wrote:
> On Tue, Jan 5, 2016 at 3:39 PM, Eric Dumazet wrote:
> > On Tue, 2016-01-05 at 15:34 +0100, Jacob Siverskog wrote:
> >> On Tue, Jan 5, 2016 at 3:14 PM, Eric Dumazet
> >> wrote:
> >
> >> >
> >> > You might build a kernel with KASAN
On Tue, Jan 5, 2016 at 3:39 PM, Eric Dumazet wrote:
> On Tue, 2016-01-05 at 15:34 +0100, Jacob Siverskog wrote:
>> On Tue, Jan 5, 2016 at 3:14 PM, Eric Dumazet wrote:
>
>> >
>> > You might build a kernel with KASAN support to get maybe more chances to
>> > trigger the bug.
>> >
>> > (
On Tue, Jan 5, 2016 at 3:39 PM, Eric Dumazet wrote:
> On Tue, 2016-01-05 at 15:34 +0100, Jacob Siverskog wrote:
>> On Tue, Jan 5, 2016 at 3:14 PM, Eric Dumazet wrote:
>
>> >
>> > You might build a kernel with KASAN support to get maybe more chances
On Wed, 2016-01-20 at 16:06 +0100, Jacob Siverskog wrote:
> On Tue, Jan 5, 2016 at 3:39 PM, Eric Dumazet wrote:
> > On Tue, 2016-01-05 at 15:34 +0100, Jacob Siverskog wrote:
> >> On Tue, Jan 5, 2016 at 3:14 PM, Eric Dumazet
> >> wrote:
> >
> >> >
On Wed, 2016-01-20 at 17:17 +0100, Jacob Siverskog wrote:
> On Wed, Jan 20, 2016 at 4:48 PM, Eric Dumazet wrote:
> > On Wed, 2016-01-20 at 16:06 +0100, Jacob Siverskog wrote:
> >> On Tue, Jan 5, 2016 at 3:39 PM, Eric Dumazet
> >> wrote:
> >> > On
Hi Jacob,
On 01/05/2016 06:34 AM, Jacob Siverskog wrote:
> On Tue, Jan 5, 2016 at 3:14 PM, Eric Dumazet wrote:
>> On Tue, 2016-01-05 at 12:07 +0100, Jacob Siverskog wrote:
>>> On Mon, Jan 4, 2016 at 4:25 PM, Eric Dumazet wrote:
On Mon,
On Wed, Jan 20, 2016 at 4:48 PM, Eric Dumazet wrote:
> On Wed, 2016-01-20 at 16:06 +0100, Jacob Siverskog wrote:
>> On Tue, Jan 5, 2016 at 3:39 PM, Eric Dumazet wrote:
>> > On Tue, 2016-01-05 at 15:34 +0100, Jacob Siverskog wrote:
>> >> On Tue, Jan
On Tue, 2016-01-05 at 15:34 +0100, Jacob Siverskog wrote:
> On Tue, Jan 5, 2016 at 3:14 PM, Eric Dumazet wrote:
> >
> > You might build a kernel with KASAN support to get maybe more chances to
> > trigger the bug.
> >
> > ( https://www.kernel.org/doc/Documentation/kasan.txt )
> >
>
> Ah.
On Tue, Jan 5, 2016 at 3:14 PM, Eric Dumazet wrote:
> On Tue, 2016-01-05 at 12:07 +0100, Jacob Siverskog wrote:
>> On Mon, Jan 4, 2016 at 4:25 PM, Eric Dumazet wrote:
>> > On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
>> >> On Wed, Dec 30, 2015 at 11:30 PM, Cong Wang
>> >> wrote:
On Tue, 2016-01-05 at 12:07 +0100, Jacob Siverskog wrote:
> On Mon, Jan 4, 2016 at 4:25 PM, Eric Dumazet wrote:
> > On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
> >> On Wed, Dec 30, 2015 at 11:30 PM, Cong Wang
> >> wrote:
> >> > On Wed, Dec 30, 2015 at 6:30 AM, Jacob Siverskog
> >>
On Mon, Jan 4, 2016 at 4:25 PM, Eric Dumazet wrote:
> On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
>> On Wed, Dec 30, 2015 at 11:30 PM, Cong Wang wrote:
>> > On Wed, Dec 30, 2015 at 6:30 AM, Jacob Siverskog
>> > wrote:
>> >> On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet wrote:
>>
On Tue, Jan 5, 2016 at 3:14 PM, Eric Dumazet wrote:
> On Tue, 2016-01-05 at 12:07 +0100, Jacob Siverskog wrote:
>> On Mon, Jan 4, 2016 at 4:25 PM, Eric Dumazet wrote:
>> > On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
>> >> On Wed, Dec
On Tue, 2016-01-05 at 15:34 +0100, Jacob Siverskog wrote:
> On Tue, Jan 5, 2016 at 3:14 PM, Eric Dumazet wrote:
> >
> > You might build a kernel with KASAN support to get maybe more chances to
> > trigger the bug.
> >
> > (
On Tue, 2016-01-05 at 12:07 +0100, Jacob Siverskog wrote:
> On Mon, Jan 4, 2016 at 4:25 PM, Eric Dumazet wrote:
> > On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
> >> On Wed, Dec 30, 2015 at 11:30 PM, Cong Wang
> >> wrote:
> >> > On
On Mon, Jan 4, 2016 at 4:25 PM, Eric Dumazet wrote:
> On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
>> On Wed, Dec 30, 2015 at 11:30 PM, Cong Wang wrote:
>> > On Wed, Dec 30, 2015 at 6:30 AM, Jacob Siverskog
>> >
On Mon, 2016-01-04 at 16:14 +, Rainer Weikusat wrote:
> Eric Dumazet writes:
> > On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
>
> [...]
>
> >> I believe the crash occurred between these two actions. I just saw
> >> that there are some interesting events in the log prior to the
Eric Dumazet writes:
> On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
[...]
>> I believe the crash occurred between these two actions. I just saw
>> that there are some interesting events in the log prior to the crash:
>> kernel: Bluetooth: Unable to push skb to HCI core(-6)
>>
On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
> On Wed, Dec 30, 2015 at 11:30 PM, Cong Wang wrote:
> > On Wed, Dec 30, 2015 at 6:30 AM, Jacob Siverskog
> > wrote:
> >> On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet wrote:
> >>> How often can you trigger this bug ?
> >>
> >> Ok. I
On Wed, Dec 30, 2015 at 11:30 PM, Cong Wang wrote:
> On Wed, Dec 30, 2015 at 6:30 AM, Jacob Siverskog
> wrote:
>> On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet wrote:
>>> How often can you trigger this bug ?
>>
>> Ok. I don't have a good repro to trigger it unfortunately, I've seen it just
>>
On Wed, Dec 30, 2015 at 11:30 PM, Cong Wang wrote:
> On Wed, Dec 30, 2015 at 6:30 AM, Jacob Siverskog
> wrote:
>> On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet wrote:
>>> How often can you trigger this bug ?
>>
>> Ok. I
On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
> On Wed, Dec 30, 2015 at 11:30 PM, Cong Wang wrote:
> > On Wed, Dec 30, 2015 at 6:30 AM, Jacob Siverskog
> > wrote:
> >> On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet
On Mon, 2016-01-04 at 16:14 +, Rainer Weikusat wrote:
> Eric Dumazet writes:
> > On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
>
> [...]
>
> >> I believe the crash occurred between these two actions. I just saw
> >> that there are some interesting events
Eric Dumazet writes:
> On Mon, 2016-01-04 at 10:10 +0100, Jacob Siverskog wrote:
[...]
>> I believe the crash occurred between these two actions. I just saw
>> that there are some interesting events in the log prior to the crash:
>> kernel: Bluetooth: Unable to push skb
On Wed, Dec 30, 2015 at 6:30 AM, Jacob Siverskog
wrote:
> On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet wrote:
>> How often can you trigger this bug ?
>
> Ok. I don't have a good repro to trigger it unfortunately, I've seen it just a
> few times when bringing up/down network interfaces. Does the
Jacob Siverskog writes:
> On Tue, Dec 29, 2015 at 9:08 PM, David Miller wrote:
>> From: Rainer Weikusat
>> Date: Tue, 29 Dec 2015 19:42:36 +
>>
>>> Jacob Siverskog writes:
This should fix a NULL pointer dereference I encountered (dump
below). Since __skb_unlink is called while
On Wed, Dec 30, 2015 at 9:30 AM, Jacob Siverskog
wrote:
> On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet wrote:
>> At this point corruption already happened.
>> We can not possibly detect every possible corruption caused by bugs
>> elsewhere in the kernel and just 'recover' at this point.
>> We
On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet wrote:
> On Wed, Dec 30, 2015 at 6:14 AM, Jacob Siverskog
> wrote:
>
>> Ok. Thanks for your feedback. How do you believe the issue could be
>> solved? Investigating it gives:
>>
>> static inline void __skb_unlink(struct sk_buff *skb, struct
On Wed, Dec 30, 2015 at 6:14 AM, Jacob Siverskog
wrote:
> Ok. Thanks for your feedback. How do you believe the issue could be
> solved? Investigating it gives:
>
> static inline void __skb_unlink(struct sk_buff *skb, struct sk_buff_head
> *list)
> {
> struct sk_buff *next, *prev;
>
>
On Tue, Dec 29, 2015 at 9:08 PM, David Miller wrote:
> From: Rainer Weikusat
> Date: Tue, 29 Dec 2015 19:42:36 +
>
>> Jacob Siverskog writes:
>>> This should fix a NULL pointer dereference I encountered (dump
>>> below). Since __skb_unlink is called while walking,
>>> skb_queue_walk_safe
On Wed, Dec 30, 2015 at 6:30 AM, Jacob Siverskog
wrote:
> On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet wrote:
>> How often can you trigger this bug ?
>
> Ok. I don't have a good repro to trigger it unfortunately, I've seen it just a
> few times
On Tue, Dec 29, 2015 at 9:08 PM, David Miller wrote:
> From: Rainer Weikusat
> Date: Tue, 29 Dec 2015 19:42:36 +
>
>> Jacob Siverskog writes:
>>> This should fix a NULL pointer dereference I encountered (dump
On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet wrote:
> On Wed, Dec 30, 2015 at 6:14 AM, Jacob Siverskog
> wrote:
>
>> Ok. Thanks for your feedback. How do you believe the issue could be
>> solved? Investigating it gives:
>>
>> static inline void
On Wed, Dec 30, 2015 at 6:14 AM, Jacob Siverskog
wrote:
> Ok. Thanks for your feedback. How do you believe the issue could be
> solved? Investigating it gives:
>
> static inline void __skb_unlink(struct sk_buff *skb, struct sk_buff_head
> *list)
> {
> struct sk_buff
On Wed, Dec 30, 2015 at 9:30 AM, Jacob Siverskog
wrote:
> On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet wrote:
>> At this point corruption already happened.
>> We can not possibly detect every possible corruption caused by bugs
>> elsewhere in the
Jacob Siverskog writes:
> On Tue, Dec 29, 2015 at 9:08 PM, David Miller wrote:
>> From: Rainer Weikusat
>> Date: Tue, 29 Dec 2015 19:42:36 +
>>
>>> Jacob Siverskog writes:
From: Rainer Weikusat
Date: Tue, 29 Dec 2015 19:42:36 +
> Jacob Siverskog writes:
>> This should fix a NULL pointer dereference I encountered (dump
>> below). Since __skb_unlink is called while walking,
>> skb_queue_walk_safe should be used.
>
> The code in question is:
...
> __skb_unlink
Jacob Siverskog writes:
> This should fix a NULL pointer dereference I encountered (dump
> below). Since __skb_unlink is called while walking,
> skb_queue_walk_safe should be used.
The code in question is:
skb_queue_walk(queue, skb) {
*last = skb;
*peeked = skb->peeked;
This should fix a NULL pointer dereference I encountered (dump
below). Since __skb_unlink is called while walking,
skb_queue_walk_safe should be used.
I investigated the oops and it seems like skb->next was NULL.
Oops:
Unable to handle kernel NULL pointer dereference at virtual address 0004
This should fix a NULL pointer dereference I encountered (dump
below). Since __skb_unlink is called while walking,
skb_queue_walk_safe should be used.
I investigated the oops and it seems like skb->next was NULL.
Oops:
Unable to handle kernel NULL pointer dereference at virtual address 0004
From: Rainer Weikusat
Date: Tue, 29 Dec 2015 19:42:36 +
> Jacob Siverskog writes:
>> This should fix a NULL pointer dereference I encountered (dump
>> below). Since __skb_unlink is called while walking,
>> skb_queue_walk_safe
Jacob Siverskog writes:
> This should fix a NULL pointer dereference I encountered (dump
> below). Since __skb_unlink is called while walking,
> skb_queue_walk_safe should be used.
The code in question is:
skb_queue_walk(queue, skb) {
*last = skb;
44 matches
Mail list logo