On my Gentoo system using kernel.org kernel sources, 3.6.5 and 3.6.6, I
receive a "general protection fault" (GPF) when a program tries to
access my Keyspan 4-port serial to usb adapter using the
USB_SERIAL_KEYSPAN_USA49W driver moddule. This GPF does not occur when
using kernel versions less than 3.6.5.
The GPF occurs when running C or Python based programs as well as
running minicom.
Below is part of /var/log/messages that shows the GPF when I tried to
run whozzcalling.py -- a script I wrote that communicates with a serial
device. It has worked through years of kernel upgrades.
If I can provide any more information, please ask.
Please CC my e-mail address with any replies, I do not subscribe to the
linux kernel list: [email protected]
Richard
Nov 7 18:57:43 runner kernel: general protection fault: 0000 [#1] SMP
Nov 7 18:57:43 runner kernel: Modules linked in: xt_recent xt_tcpudp
xt_LOG xt_limit xt_state ipt_MASQUERADE iptable_nat iptable_filter
nf_nat_ftp nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack_ftp
nf_conntrack ip_tables x_tables ipv6 snd_pcm_oss snd_mixer_oss
hid_generic usbhid hid usblp keyspan usbserial snd_hda_codec_hdmi sr_mod
cdrom sg uhci_hcd coretemp crc32c_intel ghash_clmulni_intel aesni_intel
snd_hda_codec_realtek xhci_hcd ehci_hcd ablk_helper cryptd aes_x86_64
usbcore sky2 usb_common aes_generic snd_hda_intel snd_hda_codec i2c_i801
snd_pcm snd_timer snd soundcore snd_page_alloc pcspkr hwmon [last
unloaded: asus_atk0110]
Nov 7 18:57:43 runner kernel: CPU 2
Nov 7 18:57:43 runner kernel: Pid: 4150, comm: whozzcalling-ge Not
tainted 3.6.6-rr01 #1 System manufacturer System Product Name/P6X58D PREMIUM
Nov 7 18:57:43 runner kernel: RIP: 0010:[<ffffffffa0176a4c>]
[<ffffffffa0176a4c>] keyspan_open+0x11c/0x190 [keyspan]
Nov 7 18:57:43 runner kernel: RSP: 0018:ffff880625619a68 EFLAGS: 00010246
Nov 7 18:57:43 runner kernel: RAX: 0000000000000000 RBX:
ffff8806256b9a00 RCX: 0000000000000000
Nov 7 18:57:43 runner kernel: RDX: 0000000000000000 RSI:
0000000022e95810 RDI: 0000000000002580
Nov 7 18:57:43 runner kernel: RBP: ffff880625619ab8 R08:
0000000000000000 R09: 0000000000000000
Nov 7 18:57:43 runner kernel: R10: ffff880622fb49c0 R11:
0000000000000000 R12: 0000000000000cbd
Nov 7 18:57:45 runner kernel: R13: ffff880623d4b000 R14:
0000000000002580 R15: ffff880620c06000
Nov 7 18:57:45 runner kernel: FS: 00007f047f6c3700(0000)
GS:ffff88063fc40000(0000) knlGS:0000000000000000
Nov 7 18:57:45 runner kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
Nov 7 18:57:45 runner kernel: CR2: 00007f047f6f5000 CR3:
000000061fe58000 CR4: 00000000000007e0
Nov 7 18:57:45 runner kernel: DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Nov 7 18:57:45 runner kernel: DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Nov 7 18:57:45 runner kernel: Process whozzcalling-ge (pid: 4150,
threadinfo ffff880625618000, task ffff880625711990)
Nov 7 18:57:45 runner kernel: Stack:
Nov 7 18:57:45 runner kernel: ffff880625680a00 ffff880620c06000
0000880620c064a8 ffff880622fb49c0
Nov 7 18:57:45 runner kernel: ffff880625680a00 ffff8806218671e8
ffff880623d4b008 ffff880620c06000
Nov 7 18:57:45 runner kernel: ffff880621867180 ffff880623d4b000
ffff880625619b08 ffffffffa0158645
Nov 7 18:57:45 runner kernel: Call Trace:
Nov 7 18:57:45 runner kernel: [<ffffffffa0158645>]
serial_activate+0x75/0xa0 [usbserial]
Nov 7 18:57:45 runner kernel: [<ffffffff8129b027>] tty_port_open+0x87/0xd0
Nov 7 18:57:45 runner kernel: [<ffffffffa0158c2a>]
serial_open+0x3a/0x70 [usbserial]
Nov 7 18:57:45 runner kernel: [<ffffffff8129315c>] tty_open+0x29c/0x600
Nov 7 18:57:45 runner kernel: [<ffffffff812d51a4>] ?
kobj_lookup+0x104/0x160
Nov 7 18:57:45 runner kernel: [<ffffffff810dfbd0>] chrdev_open+0xa0/0x180
Nov 7 18:57:45 runner kernel: [<ffffffff810dfb30>] ? cdev_put+0x30/0x30
Nov 7 18:57:45 runner kernel: [<ffffffff810da106>]
do_dentry_open.clone.18+0x206/0x280
Nov 7 18:57:45 runner kernel: [<ffffffff810da19d>] finish_open+0x1d/0x30
Nov 7 18:57:45 runner kernel: [<ffffffff810ea44e>] do_last+0x76e/0xe30
Nov 7 18:57:45 runner kernel: [<ffffffff810e723c>] ?
link_path_walk+0x8c/0x9a0
Nov 7 18:57:45 runner kernel: [<ffffffff810a5adf>] ?
release_pages+0x1bf/0x210
Nov 7 18:57:45 runner kernel: [<ffffffff810eabbe>] path_openat+0xae/0x4e0
Nov 7 18:57:45 runner kernel: [<ffffffff810b750f>] ?
tlb_flush_mmu+0x5f/0xa0
Nov 7 18:57:45 runner kernel: [<ffffffff810eb344>] do_filp_open+0x44/0xa0
Nov 7 18:57:45 runner kernel: [<ffffffff810f6ea7>] ? alloc_fd+0x47/0x130
Nov 7 18:57:45 runner kernel: [<ffffffff810dafb5>] do_sys_open+0x105/0x1f0
Nov 7 18:57:45 runner kernel: [<ffffffff810db0bc>] sys_open+0x1c/0x20
Nov 7 18:57:45 runner kernel: [<ffffffff813ce562>]
system_call_fastpath+0x16/0x1b
Nov 7 18:57:45 runner kernel: Code: 08 e8 b9 16 12 e1 41 89 c6 85 c0 78
2d 44 0f b6 4d c7 0f b6 45 c6 4c 8b 55 c8 41 29 c1 45 31 c0 31 c9 31 d2
41 8b 72 68 44 89 f7 <41> ff 52 60 85 c0 75 07 44 89 b3 88 01 00 00 44
89 e0 c1 e8 1f
Nov 7 18:57:45 runner kernel: RIP [<ffffffffa0176a4c>]
keyspan_open+0x11c/0x190 [keyspan]
Nov 7 18:57:45 runner kernel: RSP <ffff880625619a68>
Nov 7 18:57:45 runner kernel: ---[ end trace e474011534926a5c ]---
Commit f79b2d0f (USB: keyspan: fix NULL-pointer dereferences and
memory leaks) had a small typo which made the driver use wrong
offsets when mapping serial port private data. This results in
in a GPF when the port is opened.
Reported-by: Richard <[email protected]>
Cc: <[email protected]>
Cc: Johan Hovold <[email protected]>
Signed-off-by: Bjørn Mork <[email protected]>
---
Hello Richard,
I wonder if you are able to test and verify this? I do not guarantee
that there aren't other issues around, but this small typo looked like
an obvious killer...
Bjørn
drivers/usb/serial/keyspan.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index 7179b0c..cff8dd5 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -2430,7 +2430,7 @@ static void keyspan_release(struct usb_serial *serial)
static int keyspan_port_probe(struct usb_serial_port *port)
{
struct usb_serial *serial = port->serial;
- struct keyspan_port_private *s_priv;
+ struct keyspan_serial_private *s_priv;
struct keyspan_port_private *p_priv;
const struct keyspan_device_details *d_details;
struct callbacks *cback;
@@ -2445,7 +2445,6 @@ static int keyspan_port_probe(struct usb_serial_port *port)
if (!p_priv)
return -ENOMEM;
- s_priv = usb_get_serial_data(port->serial);
p_priv->device_details = d_details;
/* Setup values for the various callback routines */
--
1.7.10.4
On Sat, Nov 10, 2012 at 10:13 AM, Bj?rn Mork <[email protected]> wrote:
> Commit f79b2d0f (USB: keyspan: fix NULL-pointer dereferences and
> memory leaks) had a small typo which made the driver use wrong
> offsets when mapping serial port private data. This results in
> in a GPF when the port is opened.
>
> Reported-by: Richard <[email protected]>
> Cc: <[email protected]>
> Cc: Johan Hovold <[email protected]>
> Signed-off-by: Bj?rn Mork <[email protected]>
Acked-by: Johan Hovold <[email protected]>
> ---
> Hello Richard,
>
> I wonder if you are able to test and verify this? I do not guarantee
> that there aren't other issues around, but this small typo looked like
> an obvious killer...
Good catch, Bj?rn.
Greg, this one needs to be backported to v3.6.x.
Note that the usb_get_serial_data call below was simply redundant,
so that part is really a clean up rather than part of the fix.
Thanks,
Johan
> Bj?rn
>
> drivers/usb/serial/keyspan.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
> index 7179b0c..cff8dd5 100644
> --- a/drivers/usb/serial/keyspan.c
> +++ b/drivers/usb/serial/keyspan.c
> @@ -2430,7 +2430,7 @@ static void keyspan_release(struct usb_serial *serial)
> static int keyspan_port_probe(struct usb_serial_port *port)
> {
> struct usb_serial *serial = port->serial;
> - struct keyspan_port_private *s_priv;
> + struct keyspan_serial_private *s_priv;
> struct keyspan_port_private *p_priv;
> const struct keyspan_device_details *d_details;
> struct callbacks *cback;
> @@ -2445,7 +2445,6 @@ static int keyspan_port_probe(struct usb_serial_port *port)
> if (!p_priv)
> return -ENOMEM;
>
> - s_priv = usb_get_serial_data(port->serial);
> p_priv->device_details = d_details;
>
> /* Setup values for the various callback routines */
> --
> 1.7.10.4
>
Bjørn:
I patched keyspan.c using your below supplied diff in 3.6.6 (I'm not
using git.) The patch WORKS for me. (I tested using minicom and the
two programs that usually access the Keyspan serial device.)
Thank you for the quick fix.
Will this show up in 3.6.7?
Richard
[email protected]
On 11/10/2012 01:13 AM, Bjørn Mork wrote:
> Commit f79b2d0f (USB: keyspan: fix NULL-pointer dereferences and
> memory leaks) had a small typo which made the driver use wrong
> offsets when mapping serial port private data. This results in
> in a GPF when the port is opened.
>
> Reported-by: Richard <[email protected]>
> Cc: <[email protected]>
> Cc: Johan Hovold <[email protected]>
> Signed-off-by: Bjørn Mork <[email protected]>
> ---
> Hello Richard,
>
> I wonder if you are able to test and verify this? I do not guarantee
> that there aren't other issues around, but this small typo looked like
> an obvious killer...
>
> Bjørn
>
> drivers/usb/serial/keyspan.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
> index 7179b0c..cff8dd5 100644
> --- a/drivers/usb/serial/keyspan.c
> +++ b/drivers/usb/serial/keyspan.c
> @@ -2430,7 +2430,7 @@ static void keyspan_release(struct usb_serial *serial)
> static int keyspan_port_probe(struct usb_serial_port *port)
> {
> struct usb_serial *serial = port->serial;
> - struct keyspan_port_private *s_priv;
> + struct keyspan_serial_private *s_priv;
> struct keyspan_port_private *p_priv;
> const struct keyspan_device_details *d_details;
> struct callbacks *cback;
> @@ -2445,7 +2445,6 @@ static int keyspan_port_probe(struct usb_serial_port *port)
> if (!p_priv)
> return -ENOMEM;
>
> - s_priv = usb_get_serial_data(port->serial);
> p_priv->device_details = d_details;
>
> /* Setup values for the various callback routines */
>
Richard <[email protected]> writes:
> Bjørn:
>
> I patched keyspan.c using your below supplied diff in 3.6.6 (I'm not
> using git.) The patch WORKS for me. (I tested using minicom and the
> two programs that usually access the Keyspan serial device.)
Thanks for testing. Good to know that this really was the problem you
were facing.
As you might have guessed, neither Johan nor I have the hardware to test
this driver. So your bug report and testing is extremely valuable.
> Thank you for the quick fix.
And thank you for an excellent bug report and quick testing. The fact
that you could describe exactly which stable releases this appeared in
narrowed it down to just a single commit. And describing exactly what
happened narrowed it down to just a few possible places within that
commit. This was the main reason the bug could be fixed this fast.
> Will this show up in 3.6.7?
That's for Greg to answer. But don't be surprised if this came in too
late for 3.6.7. All fixes for stable has to go through mainline first.
Bjørn