2006-01-15 19:48:56

by Vitaly V. Bursov

[permalink] [raw]
Subject: linux 2.6.15.1 ppp_async panic on x86-64.

Hello,

PPP doesn't work for me on a x86-64 kernel. Kernel panics with a message

================cut: dmesg
Jan 15 20:24:12 vb skb_over_panic: text:ffffffff886700d9 len:1 put:1
head:ffff81002b7ed000 data:ffff81012b7ed000 tail:ffff81012b7ed001
end:ffff81002b7ed600 dev:<NULL>
Jan 15 20:24:12 vb ----------- [cut here ] --------- [please bite here ] ---------
Jan 15 20:24:12 vb Kernel BUG at net/core/skbuff.c:94
================cut
note the "tail" and "end" difference:
0xffff81012b7ed001-0xffff81002b7ed600 = 0xfffffa01


It looks like that problem is caused by this peace of code.
At least it works better after commenting out "skb_reserve" line.

================cut: ppp_async.c
err:
/* frame had an error, remember that, reset SC_TOSS & SC_ESCAPE */
ap->state = SC_PREV_ERROR;
if (skb) {
/* make skb appear as freshly allocated */
skb_trim(skb, 0);
skb_reserve(skb, - skb_headroom(skb));
}
================cut

skb_headroom returns 32bit "int", skb_reserve takes 32bit "unsigned int" and
adds it to a 64bit pointer, which is bad.

I'm not at the list.
--
Thank you,
Vitaly DON'T PANIC
GPG Key ID: F95A23B9


Attachments:
(No filename) (1.23 kB)
(No filename) (189.00 B)
Download all attachments

2006-01-15 20:10:10

by Diego Calleja

[permalink] [raw]
Subject: Re: linux 2.6.15.1 ppp_async panic on x86-64.

El Sun, 15 Jan 2006 21:48:38 +0200,
"Vitaly V. Bursov" <[email protected]> escribi?:

> Hello,
>
> PPP doesn't work for me on a x86-64 kernel. Kernel panics with a message
>
> ================cut: dmesg
> Jan 15 20:24:12 vb skb_over_panic: text:ffffffff886700d9 len:1 put:1
> head:ffff81002b7ed000 data:ffff81012b7ed000 tail:ffff81012b7ed001
> end:ffff81002b7ed600 dev:<NULL>
> Jan 15 20:24:12 vb ----------- [cut here ] --------- [please bite here ] ---------
> Jan 15 20:24:12 vb Kernel BUG at net/core/skbuff.c:94
> ================cut


Just for the record, there're more people hitting this
http://bugzilla.kernel.org/show_bug.cgi?id=5857

2006-01-15 20:41:50

by Serge Belyshev

[permalink] [raw]
Subject: Re: linux 2.6.15.1 ppp_async panic on x86-64.

Diego Calleja <[email protected]> writes:

> El Sun, 15 Jan 2006 21:48:38 +0200,
> "Vitaly V. Bursov" <[email protected]> escribió:
...
>> PPP doesn't work for me on a x86-64 kernel. Kernel panics with a message
...
>> Jan 15 20:24:12 vb skb_over_panic: text:ffffffff886700d9 len:1 put:1
>> head:ffff81002b7ed000 data:ffff81012b7ed000 tail:ffff81012b7ed001
>> end:ffff81002b7ed600 dev:<NULL>
...
> Just for the record, there're more people hitting this
> http://bugzilla.kernel.org/show_bug.cgi?id=5857

I can confirm this with a similar oops:

[ 273.950666] skb_over_panic: text:ffffffff882d8c19 len:54 put:54 head:ffff81001cfecd60 data:ffff81011cfecd63 tail:ffff81011cfecd99 end:ffff81001cfed360 dev:<NULL>
[ 273.950681] ----------- [cut here ] --------- [please bite here ] ---------
[ 273.950684] Kernel BUG at net/core/skbuff.c:94
[ 273.950686] invalid operand: 0000 [1] PREEMPT
[ 273.950689] CPU 0
[ 273.950691] Modules linked in: ppp_deflate bsd_comp ppp_async ppp_generic slhc pl2303 usbserial radeon drm af_packet ipv6 pcmcia firmware_class bridge deflate zlib_deflate zlib_inflate twofish serpent aes blowfish des sha256 sha1 af_key binfmt_misc dm_mod asus_acpi button thermal processor battery evdev eth1394 snd_intel8x0 snd_intel8x0m snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm irtty_sir snd_timer ohci1394 snd sir_dev irda 8250_pci ide_cd yenta_socket rsrc_nonstatic pcmcia_core amd64_agp ehci_hcd psmouse pcspkr parport_pc parport 8250 serial_core ieee1394 cdrom ohci_hcd usbcore crc_ccitt i2c_nforce2 i2c_core soundcore snd_page_alloc rtc agpgart unix
[ 273.950728] Pid: 4, comm: events/0 Not tainted 2.6.15-ssb1dbg #3
[ 273.950731] RIP: 0010:[skb_over_panic+96/112] <ffffffff8027c160>{skb_over_panic+96}
[ 273.950739] RSP: 0018:ffff81001fe19d78 EFLAGS: 00010096
[ 273.950742] RAX: 00000000000000ab RBX: 0000000000000036 RCX: ffffffff803b5d58
[ 273.950745] RDX: ffff81001ff38080 RSI: 0000000000000082 RDI: 0000000000000001
[ 273.950749] RBP: ffff81001fe19d98 R08: 0000000000000005 R09: 0000000000000000
[ 273.950752] R10: 0000000000000000 R11: 0000000000000000 R12: ffff81000c4c18e8
[ 273.950755] R13: 000000000000003f R14: ffff8100164a8801 R15: ffff81011cfecd63
[ 273.950759] FS: 00002aaaab3a96d0(0000) GS:ffffffff80575800(0000) knlGS:0000000000000000
[ 273.950763] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[ 273.950766] CR2: 0000000000c55000 CR3: 0000000019e81000 CR4: 00000000000006e0
[ 273.950770] Process events/0 (pid: 4, threadinfo ffff81001fe18000, task ffff81001ff38080)
[ 273.950772] Stack: ffff81011cfecd99 ffff81001cfed360 ffffffff80323edb ffff81000c4c18e8
[ 273.950779] ffff81001fe19df8 ffffffff882d8c23 ffff81000c4c19a0 ffff81000c4c1918
[ 273.950785] ffff8100164a8401 ffff8100164a8000
[ 273.950789] Call Trace:<ffffffff882d8c23>{:ppp_async:ppp_asynctty_receive+579}
[ 273.950800] <ffffffff80238593>{flush_to_ldisc+291} <ffffffff80142e40>{worker_thread+512}
[ 273.950816] <ffffffff80238470>{flush_to_ldisc+0} <ffffffff8012d9c0>{default_wake_function+0}
[ 273.950827] <ffffffff802fb3a1>{thread_return+191} <ffffffff80142c40>{worker_thread+0}
[ 273.950839] <ffffffff801477d9>{kthread+217} <ffffffff802fc7b4>{_spin_unlock_irq+20}
[ 273.950848] <ffffffff8012de39>{schedule_tail+73} <ffffffff8010f7d6>{child_rip+8}
[ 273.950858] <ffffffff80147700>{kthread+0} <ffffffff8010f7ce>{child_rip+0}
[ 273.950871]
[ 273.950874]
[ 273.950875] Code: 0f 0b 68 fe fe 32 80 c2 5e 00 c9 c3 66 66 66 90 55 49 89 d2
[ 273.950885] RIP <ffffffff8027c160>{skb_over_panic+96} RSP <ffff81001fe19d78>
[ 273.950891] <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43
[ 273.950895] in_atomic():1, irqs_disabled():1
[ 273.950897]
[ 273.950898] Call Trace:<ffffffff8012c9eb>{__might_sleep+187} <ffffffff801328ed>{profile_task_exit+29}
[ 273.950907] <ffffffff801339e5>{do_exit+37} <ffffffff802fc7fd>{_spin_unlock_irqrestore+29}
[ 273.950917] <ffffffff80110654>{die+84} <ffffffff802fce4d>{do_trap+269}
[ 273.950929] <ffffffff80110e6d>{do_invalid_op+157} <ffffffff8027c160>{skb_over_panic+96}
[ 273.950941] <ffffffff8010f621>{error_exit+0} <ffffffff8027c160>{skb_over_panic+96}
[ 273.950962] <ffffffff8027c160>{skb_over_panic+96} <ffffffff882d8c23>{:ppp_async:ppp_asynctty_receive+579}
[ 273.950975] <ffffffff80238593>{flush_to_ldisc+291} <ffffffff80142e40>{worker_thread+512}
[ 273.950990] <ffffffff80238470>{flush_to_ldisc+0} <ffffffff8012d9c0>{default_wake_function+0}
[ 273.950999] <ffffffff802fb3a1>{thread_return+191} <ffffffff80142c40>{worker_thread+0}
[ 273.951011] <ffffffff801477d9>{kthread+217} <ffffffff802fc7b4>{_spin_unlock_irq+20}
[ 273.951020] <ffffffff8012de39>{schedule_tail+73} <ffffffff8010f7d6>{child_rip+8}
[ 273.951029] <ffffffff80147700>{kthread+0} <ffffffff8010f7ce>{child_rip+0}
[ 273.951042]
[ 273.951046] note: events/0[4] exited with preempt_count 1

(this is 2.6.15-ck2 + few local hacks with debugging config)

2006-01-16 03:03:25

by Diego Calleja

[permalink] [raw]
Subject: Re: linux 2.6.15.1 ppp_async panic on x86-64.

This should have been forwaded to netdev I think (forwading there)

El Sun, 15 Jan 2006 23:41:48 +0300,
Serge Belyshev <[email protected]> escribi?:

Diego Calleja <[email protected]> writes:

> > El Sun, 15 Jan 2006 21:48:38 +0200,
> > "Vitaly V. Bursov" <[email protected]> escribi?:
> ...
> >> PPP doesn't work for me on a x86-64 kernel. Kernel panics with a message
> ...
> >> Jan 15 20:24:12 vb skb_over_panic: text:ffffffff886700d9 len:1 put:1
> >> head:ffff81002b7ed000 data:ffff81012b7ed000 tail:ffff81012b7ed001
> >> end:ffff81002b7ed600 dev:<NULL>
> ...
> > Just for the record, there're more people hitting this
> > http://bugzilla.kernel.org/show_bug.cgi?id=5857
>
> I can confirm this with a similar oops:
>
> [ 273.950666] skb_over_panic: text:ffffffff882d8c19 len:54 put:54 head:ffff81001cfecd60 data:ffff81011cfecd63 tail:ffff81011cfecd99 end:ffff81001cfed360 dev:<NULL>
> [ 273.950681] ----------- [cut here ] --------- [please bite here ] ---------
> [ 273.950684] Kernel BUG at net/core/skbuff.c:94
> [ 273.950686] invalid operand: 0000 [1] PREEMPT
> [ 273.950689] CPU 0
> [ 273.950691] Modules linked in: ppp_deflate bsd_comp ppp_async ppp_generic slhc pl2303 usbserial radeon drm af_packet ipv6 pcmcia firmware_class bridge deflate zlib_deflate zlib_inflate twofish serpent aes blowfish des sha256 sha1 af_key binfmt_misc dm_mod asus_acpi button thermal processor battery evdev eth1394 snd_intel8x0 snd_intel8x0m snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm irtty_sir snd_timer ohci1394 snd sir_dev irda 8250_pci ide_cd yenta_socket rsrc_nonstatic pcmcia_core amd64_agp ehci_hcd psmouse pcspkr parport_pc parport 8250 serial_core ieee1394 cdrom ohci_hcd usbcore crc_ccitt i2c_nforce2 i2c_core soundcore snd_page_alloc rtc agpgart unix
> [ 273.950728] Pid: 4, comm: events/0 Not tainted 2.6.15-ssb1dbg #3
> [ 273.950731] RIP: 0010:[skb_over_panic+96/112] <ffffffff8027c160>{skb_over_panic+96}
> [ 273.950739] RSP: 0018:ffff81001fe19d78 EFLAGS: 00010096
> [ 273.950742] RAX: 00000000000000ab RBX: 0000000000000036 RCX: ffffffff803b5d58
> [ 273.950745] RDX: ffff81001ff38080 RSI: 0000000000000082 RDI: 0000000000000001
> [ 273.950749] RBP: ffff81001fe19d98 R08: 0000000000000005 R09: 0000000000000000
> [ 273.950752] R10: 0000000000000000 R11: 0000000000000000 R12: ffff81000c4c18e8
> [ 273.950755] R13: 000000000000003f R14: ffff8100164a8801 R15: ffff81011cfecd63
> [ 273.950759] FS: 00002aaaab3a96d0(0000) GS:ffffffff80575800(0000) knlGS:0000000000000000
> [ 273.950763] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> [ 273.950766] CR2: 0000000000c55000 CR3: 0000000019e81000 CR4: 00000000000006e0
> [ 273.950770] Process events/0 (pid: 4, threadinfo ffff81001fe18000, task ffff81001ff38080)
> [ 273.950772] Stack: ffff81011cfecd99 ffff81001cfed360 ffffffff80323edb ffff81000c4c18e8
> [ 273.950779] ffff81001fe19df8 ffffffff882d8c23 ffff81000c4c19a0 ffff81000c4c1918
> [ 273.950785] ffff8100164a8401 ffff8100164a8000
> [ 273.950789] Call Trace:<ffffffff882d8c23>{:ppp_async:ppp_asynctty_receive+579}
> [ 273.950800] <ffffffff80238593>{flush_to_ldisc+291} <ffffffff80142e40>{worker_thread+512}
> [ 273.950816] <ffffffff80238470>{flush_to_ldisc+0} <ffffffff8012d9c0>{default_wake_function+0}
> [ 273.950827] <ffffffff802fb3a1>{thread_return+191} <ffffffff80142c40>{worker_thread+0}
> [ 273.950839] <ffffffff801477d9>{kthread+217} <ffffffff802fc7b4>{_spin_unlock_irq+20}
> [ 273.950848] <ffffffff8012de39>{schedule_tail+73} <ffffffff8010f7d6>{child_rip+8}
> [ 273.950858] <ffffffff80147700>{kthread+0} <ffffffff8010f7ce>{child_rip+0}
> [ 273.950871]
> [ 273.950874]
> [ 273.950875] Code: 0f 0b 68 fe fe 32 80 c2 5e 00 c9 c3 66 66 66 90 55 49 89 d2
> [ 273.950885] RIP <ffffffff8027c160>{skb_over_panic+96} RSP <ffff81001fe19d78>
> [ 273.950891] <3>Debug: sleeping function called from invalid context at include/linux/rwsem.h:43
> [ 273.950895] in_atomic():1, irqs_disabled():1
> [ 273.950897]
> [ 273.950898] Call Trace:<ffffffff8012c9eb>{__might_sleep+187} <ffffffff801328ed>{profile_task_exit+29}
> [ 273.950907] <ffffffff801339e5>{do_exit+37} <ffffffff802fc7fd>{_spin_unlock_irqrestore+29}
> [ 273.950917] <ffffffff80110654>{die+84} <ffffffff802fce4d>{do_trap+269}
> [ 273.950929] <ffffffff80110e6d>{do_invalid_op+157} <ffffffff8027c160>{skb_over_panic+96}
> [ 273.950941] <ffffffff8010f621>{error_exit+0} <ffffffff8027c160>{skb_over_panic+96}
> [ 273.950962] <ffffffff8027c160>{skb_over_panic+96} <ffffffff882d8c23>{:ppp_async:ppp_asynctty_receive+579}
> [ 273.950975] <ffffffff80238593>{flush_to_ldisc+291} <ffffffff80142e40>{worker_thread+512}
> [ 273.950990] <ffffffff80238470>{flush_to_ldisc+0} <ffffffff8012d9c0>{default_wake_function+0}
> [ 273.950999] <ffffffff802fb3a1>{thread_return+191} <ffffffff80142c40>{worker_thread+0}
> [ 273.951011] <ffffffff801477d9>{kthread+217} <ffffffff802fc7b4>{_spin_unlock_irq+20}
> [ 273.951020] <ffffffff8012de39>{schedule_tail+73} <ffffffff8010f7d6>{child_rip+8}
> [ 273.951029] <ffffffff80147700>{kthread+0} <ffffffff8010f7ce>{child_rip+0}
> [ 273.951042]
> [ 273.951046] note: events/0[4] exited with preempt_count 1
>
> (this is 2.6.15-ck2 + few local hacks with debugging config)

2006-01-20 12:31:00

by Andrew Morton

[permalink] [raw]
Subject: Re: linux 2.6.15.1 ppp_async panic on x86-64.

"Vitaly V. Bursov" <[email protected]> wrote:
>
> PPP doesn't work for me on a x86-64 kernel.
>

The below was merged a couple of days ago, which should fix it. Can you
please confirm that?




Begin forwarded message:

Date: Tue, 17 Jan 2006 18:03:32 -0800
From: Linux Kernel Mailing List <[email protected]>
To: [email protected]
Subject: [NET]: Make second arg to skb_reserved() signed.


tree 39750d44770efcdac150f041f71b7272c8da20f9
parent f09484ff87f677056ce631aa3d8e486861501b51
author David S. Miller <[email protected]> Tue, 17 Jan 2006 18:54:21 -0800
committer David S. Miller <[email protected]> Tue, 17 Jan 2006 18:54:21 -0800

[NET]: Make second arg to skb_reserved() signed.

Some subsystems, such as PPP, can send negative values
here. It just happened to work correctly on 32-bit with
an unsigned value, but on 64-bit this explodes.

Figured out by Paul Mackerras based upon several PPP crash
reports.

Signed-off-by: David S. Miller <[email protected]>

include/linux/skbuff.h | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index e5fd66c..ad7cc22 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -926,7 +926,7 @@ static inline int skb_tailroom(const str
* Increase the headroom of an empty &sk_buff by reducing the tail
* room. This is only allowed for an empty buffer.
*/
-static inline void skb_reserve(struct sk_buff *skb, unsigned int len)
+static inline void skb_reserve(struct sk_buff *skb, int len)
{
skb->data += len;
skb->tail += len;

2006-01-20 21:25:52

by Vitaly V. Bursov

[permalink] [raw]
Subject: Re: linux 2.6.15.1 ppp_async panic on x86-64.

On Fri, 20 Jan 2006 04:30:38 -0800
Andrew Morton <[email protected]> wrote:

> "Vitaly V. Bursov" <[email protected]> wrote:
> >
> > PPP doesn't work for me on a x86-64 kernel.
> >
>
> The below was merged a couple of days ago, which should fix it. Can you
> please confirm that?
Yes, this patch resolves the problem.

Thanks.

> Begin forwarded message:
>
> Date: Tue, 17 Jan 2006 18:03:32 -0800
> From: Linux Kernel Mailing List <[email protected]>
> To: [email protected]
> Subject: [NET]: Make second arg to skb_reserved() signed.
>
>
> tree 39750d44770efcdac150f041f71b7272c8da20f9
> parent f09484ff87f677056ce631aa3d8e486861501b51
> author David S. Miller <[email protected]> Tue, 17 Jan 2006 18:54:21 -0800
> committer David S. Miller <[email protected]> Tue, 17 Jan 2006 18:54:21 -0800
>
> [NET]: Make second arg to skb_reserved() signed.
>
> Some subsystems, such as PPP, can send negative values
> here. It just happened to work correctly on 32-bit with
> an unsigned value, but on 64-bit this explodes.
>
> Figured out by Paul Mackerras based upon several PPP crash
> reports.
>
> Signed-off-by: David S. Miller <[email protected]>
>
> include/linux/skbuff.h | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index e5fd66c..ad7cc22 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
> @@ -926,7 +926,7 @@ static inline int skb_tailroom(const str
> * Increase the headroom of an empty &sk_buff by reducing the tail
> * room. This is only allowed for an empty buffer.
> */
> -static inline void skb_reserve(struct sk_buff *skb, unsigned int len)
> +static inline void skb_reserve(struct sk_buff *skb, int len)
> {
> skb->data += len;
> skb->tail += len;


--
Vitaly DON'T PANIC
GPG Key ID: F95A23B9


Attachments:
(No filename) (1.89 kB)
(No filename) (189.00 B)
Download all attachments