linux-kernel - Re: regression IWl3945 - doesn't work with recent 2.6.30-rcX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1240959723.1207.104.camel@rc-desk>
Date:	Tue, 28 Apr 2009 16:02:03 -0700
From:	reinette chatre <reinette.chatre@...el.com>
To:	Zdenek Kabelac <zdenek.kabelac@...il.com>
Cc:	"John W. Linville" <linville@...driver.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>
Subject: Re: regression IWl3945 - doesn't work with recent 2.6.30-rcX

On Mon, 2009-04-27 at 00:59 -0700, Zdenek Kabelac wrote:
> 2009/4/24 Zdenek Kabelac <zdenek.kabelac@...il.com>:
> > 2009/4/22 John W. Linville <linville@...driver.com>:
> >> On Wed, Apr 22, 2009 at 12:33:03PM +0200, Zdenek Kabelac wrote:
> >>> Hi
> >>>
> >>> I'm checking whether -rcX kernel could be usable on my
> >>> T61/4GB/C2D/x86_64 - but wireless seems to be still out of
> >>> functionality:
> >>> I'm getting lots of weird trace-back messages and it looks like
> >>> iwl3945 is not working at all.
> >>> (attached messages from fresh build of -rc3 - but it never worked even in -rc1)
> >>
> >> Looks like this one did _not_ make -rc3:
> >>
> >> commit df833b1d73680f9f9dc72cbc3215edbbc6ab740d
> >> Author: Reinette Chatre <reinette.chatre@...el.com>
> >> Date:   Tue Apr 21 10:55:48 2009 -0700
> >>
> >>    iwlwifi: DMA fixes
> >>
> >>    A few issues wrt DMA were uncovered when using the driver with swiotlb.
> >> ...
> >>
> >> It is in wireless-2.6 and should be in net-2.6 -- please try one of those kernels.
> >
> >
> > I can confirm that current upstream linux commit
> > 9f5a691253924fd033a58c6b1fed57bb0a4eccf4 works again with iwlwifi.
> > and it already contains the patch you suggested to check.
> >
> 
> 
> While Wifi seems to be working well - I've noticed once attached long
> INFO message during suspend.
> 
> Zdenek
> 
> -----------
> 
> Linux version 2.6.30-rc3-00324-g8087eae (gcc version 4.4.0 20090414
> (Red Hat 4.4.0-0.34) (GCC) ) #55 SMP Fri Apr 24 20:22:26 CEST 2009
> Command line: ro root=/dev/sda5 selinux=0 no_console_suspend
> ...
> ADDRCONF(NETDEV_UP): wlan0: link is not ready
> virbr0: no IPv6 routers present
> wlan0: authenticate with AP 00:11:d8:da:65:40
> wlan0: authenticated
> wlan0: associate with AP 00:11:d8:da:65:40
> wlan0: RX AssocResp from 00:11:d8:da:65:40 (capab=0x401 status=0 aid=4)
> wlan0: associated
> ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> wlan0: disassociating by local choice (reason=3)
> audit(1240599276.009:18266): audit_enabled=0 old=1 auid=4294967295
> ses=4294967295 res=1
> wlan0: no IPv6 routers present
> fuse init (API version 7.11)
> wlan0: authenticate with AP 00:11:d8:da:65:40
> wlan0: authenticated
> wlan0: associate with AP 00:11:d8:da:65:40
> wlan0: RX AssocResp from 00:11:d8:da:65:40 (capab=0x401 status=0 aid=4)
> wlan0: associated
> wlan0: no probe response from AP 00:11:d8:da:65:40 - disassociating
> wlan0: deauthenticated (Reason: 7)
> wlan0: authenticate with AP 00:11:d8:da:65:40
> wlan0: authenticate with AP 00:11:d8:da:65:40
> wlan0: authenticate with AP 00:11:d8:da:65:40
> wlan0: authenticated
> wlan0: associate with AP 00:11:d8:da:65:40
> wlan0: RX ReassocResp from 00:11:d8:da:65:40 (capab=0x401 status=0 aid=4)
> wlan0: associated
> 
> ..........
> 
> =========================================================
> [ INFO: possible irq lock inversion dependency detected ]
> 2.6.30-rc3-00324-g8087eae #55
> ---------------------------------------------------------
> swapper/0 just changed the state of lock:
>  (&(&priv->scan_check)->timer){+.-...}, at: [<ffffffff80250d90>]
> run_timer_softirq+0x120/0x2e0
> but this lock was taken by another, HARDIRQ-safe lock in the past:
>  (&priv->lock){-.-...}
> 
> and interrupts could create inverse lock ordering between them.
> 
> 

The locking used to protect scan_check is not consistent and is so
because we overusing the priv->lock spinlock. scan_check is used in
three places (iwl_rx_scan_complete_notif, iwl3945_bg_request_scan, and
iwl3945_set_mode). In iwl_rx_scan_complete_notif the access is protected
with priv->lock, while the other two use priv->mutex. The protection in
iwl_rx_scan_complete_notif with priv->lock is not necessary ... but a
significant effort is required to change this. We are starting to move
in this direction. A workaround will be to acquire priv->lock in
iwl3945_bg_request_scan and iwl3945_set_mode, but that will be ugly. 

We can leave this code as is in 2.6.30 because inverse lock ordering is
not possible here as priv->mutex cannot be obtained in
iwl_rx_scan_complete_notif path as it (the mutex) sleeps and this code
path doesn't (it is run in a tasklet).

Reinette


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/