Bug 508952 - Oopsed yanked remote receiver
Oopsed yanked remote receiver
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Jarod Wilson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-30 12:02 EDT by Bastien Nocera
Modified: 2009-08-12 10:02 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-12 10:02:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bastien Nocera 2009-06-30 12:02:53 EDT
kernel-2.6.29.5-191.fc11.x86_64
lirc-0.8.5-2.fc11.x86_64

Using the lirc_streamzap module.

I yanked out the USB receiver from my Streamzap remote after I finished testing with it, and the kernel oopsed a couple of seconds later.

general protection fault: 0000 [#1] SMP 
last sysfs file: /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/irq
CPU 0 
Modules linked in: lirc_streamzap lirc_dev tun nls_utf8 udf crc_itu_t vfat fat hidp fuse rfcomm bridge stp llc bnep sco l2cap sunrpc ipv6 dm_multipath uinput btusb bluetooth ppdev snd_intel8x0 snd_ac97_codec dcdbas snd_usb_audio pcspkr uvcvideo videodev snd_usb_lib serio_raw snd_rawmidi i2c_i801 iTCO_wdt parport_pc v4l1_compat ac97_bus v4l2_compat_ioctl32 parport snd_seq_device snd_hwdep usb_storage iTCO_vendor_support tg3 snd_pcm joydev snd_timer snd soundcore snd_page_alloc ata_generic pata_acpi i915 drm i2c_algo_bit i2c_core video output [last unloaded: freq_table]
Pid: 16402, comm: lircd Not tainted 2.6.29.5-191.fc11.x86_64 #1 OptiPlex GX620               
RIP: 0010:[<ffffffffa02f3a0d>]  [<ffffffffa02f3a0d>] lirc_dev_fop_open+0xc6/0x1d8 [lirc_dev]
RSP: 0018:ffff880045a77d28  EFLAGS: 00010282
RAX: ffff88003f0044f8 RBX: ffff880075d54c00 RCX: ffff880045a77d38
RDX: 0000000000000000 RSI: 000000000000012d RDI: ffffffff814d4f2d
RBP: ffff880045a77d38 R08: ffff880045a77c98 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: f5319f100a080204
R13: 0000000000000000 R14: ffff88006d008a18 R15: ffff88002d8a29c0
FS:  00007fa1632806f0(0000) GS:ffffffff817b7000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f55fd7b1cb6 CR3: 000000000f4c2000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process lircd (pid: 16402, threadinfo ffff880045a76000, task ffff88000440c500)
Stack:
 0000000000000000 ffff880075d54cd0 ffff880045a77d88 ffffffff810d7c6b
 ffff880045a77d78 ffffffff811869cc ffff88007b861b00 ffff88007b861b00
 ffff88002d441780 ffff88002d8a29c0 ffffffff810d7b19 ffff88006d008a18
Call Trace:
 [<ffffffff810d7c6b>] chrdev_open+0x152/0x171
 [<ffffffff811869cc>] ? selinux_dentry_open+0xe7/0xf0
 [<ffffffff810d7b19>] ? chrdev_open+0x0/0x171
 [<ffffffff810d37ea>] __dentry_open+0x143/0x273
 [<ffffffff810d39ea>] nameidata_to_filp+0x42/0x53
 [<ffffffff810df085>] do_filp_open+0x3fd/0x7b8
 [<ffffffff810e9e5c>] ? mntput_no_expire+0x36/0x150
 [<ffffffff811b9602>] ? might_fault+0x1f/0x21
 [<ffffffff811b9701>] ? __strncpy_from_user+0x1e/0x49
 [<ffffffff810e8464>] ? alloc_fd+0x11b/0x12d
 [<ffffffff810d35da>] do_sys_open+0x59/0xda
 [<ffffffff810d368e>] sys_open+0x20/0x22
 [<ffffffff8101133a>] system_call_fastpath+0x16/0x1b
Code: 28 ff 0f 84 24 01 00 00 83 bb 94 00 00 00 00 41 bc f0 ff ff ff 0f 85 17 01 00 00 48 8b 83 b0 00 00 00 4c 8b 60 28 4d 85 e4 74 2b <49> 8b 7c 24 18 e8 4b 85 0b e1 49 8b 7c 24 18 41 c7 44 24 10 00 
RIP  [<ffffffffa02f3a0d>] lirc_dev_fop_open+0xc6/0x1d8 [lirc_dev]
 RSP <ffff880045a77d28>
---[ end trace df882a9e6cc7b241 ]---
Comment 1 Chuck Ebbert 2009-06-30 15:42:43 EDT
In lirc_dev.c line 466:

                        lirc_buffer_clear(ir->buf);

lirc_dev.h:

static void lirc_buffer_clear(struct lirc_buffer *buf)
{
        if (buf->fifo)
                kfifo_reset(buf->fifo);

buf->fifo is not null but it doesn't contain a valid address.
Comment 2 Jarod Wilson 2009-07-06 17:59:50 EDT
Ugh. lirc_streamzap is... not the best code around. I might have a fix, but while working on the fix, I went nuts killing a bunch of insanity in lirc_streamzap. I really should get some hardware to test on, but meh. I'll throw the modified code into rawhide, and it can get tested there, then backported as needed...
Comment 3 Jarod Wilson 2009-07-07 23:39:14 EDT
kernel-2.6.31-0.48.rc2.git2.fc12 and later carry a patch to lirc_streamzap that in theory addresses this problem, but it also changes a LOT of other stuff, so there's a decent chance it completely breaks it. Most of the changes make the driver a lot more like lirc_imon and lirc_mceusb though...

diffstat:
 drivers/input/lirc/lirc_streamzap.c |  207 +++++++++++++++++++----------------
 1 files changed, 112 insertions(+), 95 deletions(-)

I'd appreciate testing feedback, even if its "omg, now its completely and totally unusable".
Comment 4 Jarod Wilson 2009-08-12 10:02:35 EDT
I just got a streamzap receiver off eBay myself. The patch does indeed seem to remedy this particular problem. I still have an issue if I pull the receiver while the ir device is open, but that's a more general issue that needs dealing with for all receivers, not just this one. This patch appears to be good to go, and does fix the oops when the receiver is pulled w/o the ir device open.

Note You need to log in before you can comment on or make changes to this bug.