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: <200809171619.33377.mb@bu3sch.de>
Date:	Wed, 17 Sep 2008 16:19:33 +0200
From:	Michael Buesch <mb@...sch.de>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Larry Finger <Larry.Finger@...inger.net>,
	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

On Tuesday 16 September 2008 23:09:20 Matthew Garrett wrote:
> Oh, hey, I suck. This one might stand a better chance of not falling 
> over.
> 
> diff --git a/drivers/net/wireless/b43/rfkill.c b/drivers/net/wireless/b43/rfkill.c
> index fec5645..991e318 100644
> --- a/drivers/net/wireless/b43/rfkill.c
> +++ b/drivers/net/wireless/b43/rfkill.c
> @@ -49,21 +49,18 @@ static void b43_rfkill_update_state(struct b43_wldev *dev)
>  	struct b43_rfkill *rfk = &(dev->wl->rfkill);
>  
>  	if (!dev->radio_hw_enable) {
> -		rfk->rfkill->state = RFKILL_STATE_HARD_BLOCKED;
> +		rfkill_force_state(rfk->rfkill, RFKILL_STATE_HARD_BLOCKED);
>  		return;
>  	}
>  
>  	if (!dev->phy.radio_on)
> -		rfk->rfkill->state = RFKILL_STATE_SOFT_BLOCKED;
> +		rfkill_force_state(rfk->rfkill, RFKILL_STATE_SOFT_BLOCKED);
>  	else
> -		rfk->rfkill->state = RFKILL_STATE_UNBLOCKED;
> -
> +		rfkill_force_state(rfk->rfkill, RFKILL_STATE_UNBLOCKED);
>  }

I still thing that it is really wrong to check and change the software
rfkill state from within the _hardware_ rfkill state handler.
So let's say this handler sets the state to SOFT_BLOCKED. Who is going
to set it back to unblocked, if the user unblocks the radio?

We can turn the radio on/off from the mac80211 config callback. Possibly
we must tell rfkill about it (I'm not sure. I don't understand the API).
I think this is pretty hard to get right, actually. HW-block and SW-block
are two completely independent states in b43. You can HW-block and SW-block
the device at the same time. So one must make sure that at any time the rfkill
is in a sane state if _either_ HW-block or SW-block changes. Currently I think
we only change rfkill state if HW-block state changes. Which is wrong.

In the end, I do not care about this crap anymore.
Feel free to remove my copyright notice from that file and put yours in
there. So feel free to send any patch to the rfkill code to john, but please
handle any regressions resulting from it. If not, I will handle them by reverting
patches until it starts to work again. ;)

-- 
Greetings Michael.
--
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/