linux-kernel - Re: mac80211 suspend corner case (was: Asus eeepc 1008HA suspend issue and mac80211 suspend corner) case

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: <1261570081.25008.1.camel@johannes.local>
Date:	Wed, 23 Dec 2009 13:08:01 +0100
From:	Johannes Berg <johannes@...solutions.net>
To:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
Cc:	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org,
	Alan Jenkins <alan-jenkins@...fmail.co.uk>
Subject: Re: mac80211 suspend corner case (was: Asus eeepc 1008HA suspend
 issue and mac80211 suspend corner) case

On Tue, 2009-12-22 at 14:30 -0500, Luis R. Rodriguez wrote:

> Johannes, any preferences how to handle this? The patch below avoids
> the Interrupt being turned off but its not enough given that we still
> could be associated according to userspace. If the hardware is
> unresponsive maybe it is best to just let the IRQ go disabled, not
> sure, but its likely not what happens in all cases.
> 
> Trimming out the irrelevant parts below.

> http://bombadil.infradead.org/~mcgrof/logs/2.6.31-with-2.6.32-wireless
> /irq-disabled.txt
> > 
> > This can be fixed by something like the following:
> > 
> > diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> > index e6c08da..63d42fa 100644
> > --- a/net/mac80211/util.c
> > +++ b/net/mac80211/util.c
> > @@ -1031,7 +1031,14 @@ int ieee80211_reconfig(struct ieee80211_local
> *local)
> >  
> >  	/* restart hardware */
> >  	if (local->open_count) {
> > +		/*
> > +		 * Upon resume hardware can sometimes be goofy due to
> > +		 * various platform issues, so restarting the device may
> > +		 * at times not work immediately. Propagate the error.
> > +		 */
> >  		res = drv_start(local);
> > +		if (res)
> > +			return res;
> >  
> >  		ieee80211_led_radio(local, true);
> >  	}
> > 
> > But this isn't enough. And since we cannot exactly talk to hardware
> > we can't try to send a deassoc as harware would be unresponsive. I
> > also don't see us handling such cases before either on cfg80211 or
> > mac80211, so curious what we should do.

Well it seems to me that if the driver determines that the hardware is
unreachable or not responding, it would unregister it from mac80211,
which would clean up all user-visible state, obviously.

The patch above seems ok to me, but basically papers over the problem.
If the start there fails, the driver will have to unregister the hw
since any subsequent start will fail as well.

The way I see it, it's like a USB unplug while suspended/hibernated ...
the driver notices that and remo

johannes 

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)