public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Fulghum <paulkf@microgate.com>
To: Lee Revell <rlrevell@joe-job.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Laurent Riffard <laurent.riffard@free.fr>,
	USB development list <linux-usb-devel@lists.sourceforge.net>,
	Kernel development list <linux-kernel@vger.kernel.org>,
	Greg KH <greg@kroah.com>, Ingo Molnar <mingo@elte.hu>
Subject: Re: 2.6.9-rc4-mm1 : oops when rmmod uhci_hcd  [was: 2.6.9-rc3-mm2 : oops...]
Date: Fri, 15 Oct 2004 16:14:00 -0500	[thread overview]
Message-ID: <1097874840.2915.18.camel@deimos.microgate.com> (raw)
In-Reply-To: <1097872927.5119.5.camel@krustophenia.net>

On Fri, 2004-10-15 at 15:42, Lee Revell wrote:
> > Either way, the generic IRQ code should deal with
> > duplicates without generating an oops.
> 
> Agreed, this bug should be fixed either way.


I just finished some more testing,
and the problem is just as I described.

I was able to reproduce the problem using the
synclink driver by modifying it to use a constant
string for request_irq() devname on multiple
devices sharing the same irq number.

Bug trigger summary:
* multiple devices sharing same irq number
* devices have same devname (as passed to request_irq())
* devices are removed in same order as added

I added some printk statements as shown below:

Oct 15 15:41:22 deimos kernel: SyncLink serial driver $Revision: 4.32 $
...
Oct 15 15:41:22 deimos kernel: register_handler_proc:action=e27ad7e0 action->dir=e95b2800 name=synclink irq=9
Oct 15 15:41:22 deimos kernel: SyncLink PCI v1 ttySL0: IO=ECE8 IRQ=9 Mem=FBF80000,FEBFF000 MaxFrameSize=4096
...
Oct 15 15:41:22 deimos kernel: register_handler_proc:action=e27ad6a0 action->dir=e8b35e60 name=synclink irq=9
Oct 15 15:41:22 deimos kernel: SyncLink PCI v1 ttySL1: IO=ECF0 IRQ=9 Mem=FBF40000,FEBFF000 MaxFrameSize=4096
...
Oct 15 15:41:30 deimos kernel: Unloading SyncLink serial driver: $Revision: 4.32 $
...
Oct 15 15:41:30 deimos kernel: unregister_handler_proc:action=e27ad7e0 action->dir=e95b2800 irq=9
Oct 15 15:41:30 deimos kernel: remove_proc_entry:de=e8b35e60 name=synclink
Oct 15 15:41:30 deimos kernel: unregister_handler_proc:action=e27ad6a0 action->dir=e8b35e60 irq=9
Oct 15 15:41:30 deimos kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Oct 15 15:41:30 deimos kernel:  printing eip:
Oct 15 15:41:30 deimos kernel: c0186535
Oct 15 15:41:30 deimos kernel: *pde = 00000000
Oct 15 15:41:30 deimos kernel: Oops: 0000 [#1]
Oct 15 15:41:30 deimos kernel: PREEMPT 
Oct 15 15:41:30 deimos kernel: Modules linked in: synclink n_hdlc e100 aic7xxx
Oct 15 15:41:30 deimos kernel: CPU:    0
Oct 15 15:41:30 deimos kernel: EIP:    0060:[<c0186535>]    Not tainted VLI
Oct 15 15:41:30 deimos kernel: EFLAGS: 00210246   (2.6.9-rc4-mm1) 
Oct 15 15:41:30 deimos kernel: EIP is at remove_proc_entry+0x25/0x170
Oct 15 15:41:30 deimos kernel: eax: 00000000   ebx: e27ad6a0   ecx: ffffffff   edx: ebfe8e00
Oct 15 15:41:30 deimos kernel: esi: e1700000   edi: 00000000   ebp: c0470b20   esp: e17c3ee8
Oct 15 15:41:30 deimos kernel: ds: 007b   es: 007b   ss: 0068
Oct 15 15:41:30 deimos kernel: Process rmmod (pid: 3385, threadinfo=e17c2000 task=e6f700c0)
Oct 15 15:41:31 deimos kernel: Stack: e17c3ef4 c01323be c03998e0 e27ad6a0 00000000 e27ad6a0 e1700000 00000009 
Oct 15 15:41:31 deimos kernel:        c0131f86 00000000 ebfe8e00 e17c2000 00200212 e1700000 ec92ca60 c03eb1c0 
Oct 15 15:41:31 deimos kernel:        00000000 ec9232a2 00000009 e1700000 ec9283c7 ea8e19b0 e1700000 ec923940 
Oct 15 15:41:31 deimos kernel: Call Trace:
Oct 15 15:41:31 deimos kernel:  [<c01323be>] unregister_handler_proc+0x3e/0x70
Oct 15 15:41:31 deimos kernel:  [<c0131f86>] free_irq+0xb6/0x130
Oct 15 15:41:31 deimos kernel:  [<ec9232a2>] mgsl_release_resources+0x1c2/0x200 [synclink]
Oct 15 15:41:31 deimos kernel:  [<ec9283c7>] hdlcdev_exit+0x27/0x40 [synclink]
Oct 15 15:41:31 deimos kernel:  [<ec923940>] synclink_cleanup+0x50/0xe0 [synclink]

A cleaned up version:
---------------------
register_handler_proc:action=e27ad7e0 action->dir=e95b2800 name=synclink irq=9
register_handler_proc:action=e27ad6a0 action->dir=e8b35e60 name=synclink irq=9
unregister_handler_proc:action=e27ad7e0 action->dir=e95b2800 irq=9
remove_proc_entry:de=e8b35e60 name=synclink
unregister_handler_proc:action=e27ad6a0 action->dir=e8b35e60 irq=9
*Earth Shattering Kaboom*

You can see that:
1. proc entry e95b2800 is allocated for IRQ action e27ad7e0
2. proc entry e8b35e60 is allocated for IRQ action e27ad6a0
3. proc entry e8b35e60 is freed when IRQ action e27ad7e0 is freed (Wrong!)
4. when IRQ action e27ad6a0 is freed the kernel touches e8b35e60 (already gone!)

After allocation synclink shows up twice in /proc/irq/9
I'm unsure of the best way to correct this.
Disallow duplicate entries? Refine the proc entry search
on removal to use more than just the name to match?
I bet Ingo knows best :-)

-- 
Paul Fulghum
paulkf@microgate.com


  reply	other threads:[~2004-10-15 21:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-12 19:40 2.6.9-rc4-mm1 : oops when rmmod uhci_hcd [was: 2.6.9-rc3-mm2 : oops...] Laurent Riffard
2004-10-13 15:41 ` Alan Stern
2004-10-14 20:23   ` Laurent Riffard
2004-10-14 21:03     ` Alan Stern
2004-10-14 23:21       ` Laurent Riffard
2004-10-15 15:22         ` Paul Fulghum
2004-10-15 16:18           ` Alan Stern
2004-10-15 16:48             ` Paul Fulghum
2004-10-15 17:21               ` Alan Stern
2004-10-15 17:36                 ` Paul Fulghum
2004-10-15 20:42                   ` Lee Revell
2004-10-15 21:14                     ` Paul Fulghum [this message]
2004-10-16 16:07                       ` [patch, 2.6.9-rc4-mm1] fix rmmod uhci_hcd oops Ingo Molnar
2004-10-17 19:47                         ` Laurent Riffard
2004-10-15 17:22               ` [linux-usb-devel] Re: 2.6.9-rc4-mm1 : oops when rmmod uhci_hcd [was: 2.6.9-rc3-mm2 : oops...] David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1097874840.2915.18.camel@deimos.microgate.com \
    --to=paulkf@microgate.com \
    --cc=greg@kroah.com \
    --cc=laurent.riffard@free.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=mingo@elte.hu \
    --cc=rlrevell@joe-job.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox