linux-kernel - Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f

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: <20080917023334.GA1187@khazad-dum.debian.net>
Date:	Tue, 16 Sep 2008 23:33:34 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Larry Finger <Larry.Finger@...inger.net>,
	Carlos Corbacho <carlos@...angeworlds.co.uk>,
	Adel Gadllah <adel.gadllah@...il.com>,
	wireless <linux-wireless@...r.kernel.org>,
	bcm43xx-dev@...ts.berlios.de, Michael Buesch <mb@...sch.de>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Regression in 2.6.27-rcX caused by commit
	bc19d6e0b74ef03a3baf035412c95192b54dfc6f

On Wed, 17 Sep 2008, Matthew Garrett wrote:
> that's not a criticism of anyone involved - the documentation's 
> confusing and there weren't any good examples of how it should be 
> implemented).

I sure hope you mean "the documentation WAS confusing"... because if it is
still confusing, I have not got any comments or ideas about how it could be
improved yet... (HINT!).

> The real question is how the LED state is supposed to be being toggled, 
> and what that's got to do with rfkill. I /think/ that the current state 
> of events is:
> 
> 1) User toggles state
> 2) State toggle is used by b43 to generate KEY_WLAN (this is broken)
> 3) rfkill-input toggles the rfkill state, changing the LED state in the 
> process

Actually 2 and 3 will fight each other, and weird things will happen.

> What *should* be happening is:
> 
> 1) User toggles state
> 2) b43 changes rfkill state (by using rfkill_force_state). The LED state 
> should also be changed in the process.

Correct.

However, rfkill_force_state() is NOT updating LED states (I just checked).
I will sleep on the issue, and send in a patch tomorrow.

This probably means a small patch to rfkill + Matthew's fixed patch to use
rfkill_force_state() in b43 will fix the regression in the right way.

I don't care either way which kind of fix goes to 2.6.27, though.

The proper fix for rfkill will be in two stages. A small fix now, and a
complete change on the LED handling to use the blocking notifier chain
instead later on (which will clean up rfkill code somewhat).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/