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]

Date:	Wed, 23 Dec 2009 11:08:40 -0800
From:	"Luis R. Rodriguez" <lrodriguez@...eros.com>
To:	Johannes Berg <johannes@...solutions.net>
CC:	Luis Rodriguez <Luis.Rodriguez@...eros.com>,
	"linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...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 Wed, Dec 23, 2009 at 08:47:08AM -0800, Johannes Berg wrote:
> On Wed, 2009-12-23 at 08:28 -0800, Luis R. Rodriguez wrote:
> 
> > > 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 drivers would not know this until it fails on the first call
> > from mac80211 which would be start().
> 
> Which is why this patch may be a good way to solve that particular
> problem.

Sure but as you and I noted this is not the only thing required.

> > > 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.
> > 
> > How about just having mac80211 do that for drivers where the start()
> > fails and we are resuming? I can give that a shot.
> 
> No way, the driver will invariably assume things are still going and
> might later unregister etc. Too much magic.

So you want drivers to handle start() failures (even if its not for resume)
with an unregistration to mac80211?

  Luis
--
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/