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: <48D0183E.9010301@lwfinger.net>
Date:	Tue, 16 Sep 2008 15:34:06 -0500
From:	Larry Finger <Larry.Finger@...inger.net>
To:	Matthew Garrett <mjg59@...f.ucam.org>
CC:	Michael Buesch <mb@...sch.de>,
	Adel Gadllah <adel.gadllah@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	wireless <linux-wireless@...r.kernel.org>,
	bcm43xx-dev@...ts.berlios.de
Subject: Re: Regression in 2.6.27-rcX caused by commit bc19d6e0b74ef03a3baf035412c95192b54dfc6f

Matthew Garrett wrote:
> On Tue, Sep 16, 2008 at 12:08:48PM -0500, Larry Finger wrote:
> 
>> I agree with Michael. From what I know, the only possible reason for
>> having this state would be if user space could somehow affect the
>> state of the hardware switch. As the user's finger is the only such
>> thing, then there is no use for the RFKILL_STATE_HARD_BLOCKED state,
>> particularly when it breaks LED operations.
> 
> RFKILL_STATE_HARD_BLOCKED indicates that the hardware is disabled in a 
> way that userspace can't influence, so sounds like exactly the right 
> state to have here. I still have absolutely no idea what b43 rfkill is 
> supposed to be doing - why on earth is it requesting rfkill-input, and 
> why does it generate keypress events? I /think/ it should e something 
> like the following (untested, I'm not near any of my b43 hardware at the 
> moment). This basically does the following:
> 
> 1) Split the update function in two, so it can be called by either 
> polling or an interrupt driven event on newer hardware (not implemented 
> yet)
> 2) Remove all the input handling
> 3) Change the state updates to use rfkill_force_state, which will 
> generate an event that gets sent up to userland
> 4) Retains the RFKILL_STATE_HARD_BLOCKED code
> 
> When the user flicks a switch or presses a button that physically 
> disables the radio, the state will now automatically change to 
> RFKILL_STATE_HARD_BLOCKED. If they have a key that generates KEY_WLAN 
> but doesn't change the radio state, rfkill-input will trigger a change 
> to RFKILL_STATE_SOFT_BLOCKED.
> 
> Like I said, this is only build-tested - I won't be back at a b43 until 
> next week. If someone could give this a go, that would be great.

It locks up tight with a kernel panic when booting. I have a screen
picture that I will send separately to Matthew.

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