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]

Date:	Tue, 16 Sep 2008 21:52:12 -0500
From:	Larry Finger <Larry.Finger@...inger.net>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
CC:	Matthew Garrett <mjg59@...f.ucam.org>,
	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

Henrique de Moraes Holschuh wrote:
> 
> 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).
> 

I do not dispute that rfkill-handling in b43 is broken; however, prior
to the commit in question, it worked.

I also think we can agree that we need to get it working before 2.6.27
is released. If the small fix now is the reversion of bc19d6e, then I
think this is the correct path. We will then have a couple of weeks to
get the code working correctly before the 2.6.28 merge starts.

I admit that I never tested any of the RFKILL patches as they went in.
One of the reasons is that the development process seemed rather
untidy to an outsider, and I wasn't sure that any of the code would
ever be in the kernel. As such, it snuck up on me. I'll not let that
happen again. After the reversion, I will again test any suggested
code changes, but do not expect me to work out any of the changes. I
have enough to do.

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/