All of lore.kernel.org
 help / color / mirror / Atom feed
From: "John W. Linville" <linville@tuxdriver.com>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Herton Ronaldo Krzesinski <herton@mandriva.com.br>,
	Hin-Tak Leung <htl10@users.sourceforge.net>,
	sidhayn@gmail.com, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] rtl8187: Fix kernel oops when device is removed when LEDS enabled (Bugzilla #14539)
Date: Wed, 4 Nov 2009 10:11:33 -0500	[thread overview]
Message-ID: <20091104151132.GD12965@tuxdriver.com> (raw)
In-Reply-To: <4af11879./IumKJ+RAbw7Zkq6%Larry.Finger@lwfinger.net>

On Wed, Nov 04, 2009 at 12:00:25AM -0600, Larry Finger wrote:
> As reported by Rick Farina (sidhayn@gmail.com), removing the RTL8187 USB
> stick, or unloading the driver rtl8187 using rmmod will cause a kernel oops.
> There are at least two forms of the failure, (1) BUG: Scheduling while atomic,
> and (2) a fatal kernel page fault. This problem is reported in Bugzilla #14539.
> 
> This problem does not occur for kernel 2.6.31, but does for 2.6.32-rc2, thus
> it is technically a regression; however, bisection did not locate any faulty
> patch. The fix was found by comparing the faulty code in rtl8187 with p54usb.
> My interpretation is that the handling of work queues in mac80211 changed
> enough to the LEDs to be unregistered before tasks on the work queues are
> cancelled. Previously, these actions could be done in either order.
> 
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Reported-and-tested by: Rick Farina <sidhayn@gmail.com>
> ---
> 
> John,
> 
> This is 2.6.32 material. Sorry to take so long to get a patch, but it was
> difficult for me to locate the problem. Fortunately, I had the postings of the
> two flame wars to amuse me while all the kernel compilations were happening.
> 
> Larry
> ---
> 
> Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
> ===================================================================
> --- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_leds.c
> +++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
> @@ -210,10 +210,10 @@ void rtl8187_leds_exit(struct ieee80211_
>  
>  	/* turn the LED off before exiting */
>  	ieee80211_queue_delayed_work(dev, &priv->led_off, 0);
> -	cancel_delayed_work_sync(&priv->led_off);
> -	cancel_delayed_work_sync(&priv->led_on);
>  	rtl8187_unregister_led(&priv->led_rx);
>  	rtl8187_unregister_led(&priv->led_tx);
> +	cancel_delayed_work_sync(&priv->led_off);
> +	cancel_delayed_work_sync(&priv->led_on);
>  }
>  #endif /* def CONFIG_RTL8187_LED */
>  

This seems like a band-aid.  If anything, the original order would
seem to make more sense.

Do you have a link to the original backtrace?  I don't see one in
the bugzilla entry.

Thanks,

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

  reply	other threads:[~2009-11-04 15:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-04  6:00 [PATCH] rtl8187: Fix kernel oops when device is removed when LEDS enabled (Bugzilla #14539) Larry Finger
2009-11-04 15:11 ` John W. Linville [this message]
2009-11-04 15:30   ` Christian Lamparter
2009-11-04 16:49     ` John W. Linville
2009-11-05  0:14       ` Herton Ronaldo Krzesinski
2009-11-05  2:34         ` Larry Finger
2009-11-05  4:55           ` Richard Farina
2009-11-05  5:16             ` Larry Finger
2009-11-04 15:54   ` Larry Finger
2009-11-04 16:54     ` John W. Linville
2009-11-04 18:13       ` Larry Finger
2009-11-04 18:47         ` John W. Linville
2009-11-05  4:57           ` Richard Farina
2009-11-05  6:00           ` Larry Finger

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=20091104151132.GD12965@tuxdriver.com \
    --to=linville@tuxdriver.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=herton@mandriva.com.br \
    --cc=htl10@users.sourceforge.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=sidhayn@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.