linux-kernel - Re: [PATCH] staging: rtl8723au: Fix sparse warnings

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: <wrfjoar4vsa3.fsf@redhat.com>
Date:	Mon, 15 Dec 2014 10:36:52 -0500
From:	Jes Sorensen <Jes.Sorensen@...hat.com>
To:	Krzysztof Konopko <kris@...agma.com>
Cc:	Larry Finger <Larry.Finger@...inger.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-wireless@...r.kernel.org, devel@...verdev.osuosl.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: rtl8723au: Fix sparse warnings

Krzysztof Konopko <kris@...agma.com> writes:
> On 12/12/14 19:52, Jes Sorensen wrote:
>> Larry Finger <Larry.Finger@...inger.net> writes:
>>> On 12/12/2014 05:35 AM, Krzysztof Konopko wrote:
>>>> I was hunting particularly for inconsistencies with `sparse` and came
>>>> across this one.  But I dug a bit further and I wonder why the driver is
>>>> not using standard stuff like the one in `include/linux/ieee80211.h`
>>>> where any data wider than one byte is clearly declared as __le<nn>?
>>>
>>> That is a good question. One possibility is that those definitions do
>>> not exist on some of the older kernels that Realtek supports. They
>>> generally work with 2.6.18 and newer.
>> 
>> The reason the 8723au driver doesn't use the defines from there is that
>> in ieee80211.h they are part of struct ieee80211_mgmt, while the 8723au
>> driver access the addba etc. elements without the full struct in place.
>> 
>
> And why is that the case?
> (I'm trying to understand, not debunk)
>
> Looks to me that this driver has been kept out of the tree for quite a
> while (by Realtek) and now suffers from locally invented stuff.  I
> understand this is a lot of work to unify the codebase with ieee80211.h,
> but are there any technical hurdles?  I'm just curious.

The main issue is that the RTL driver maintains a partial copy of the
management frame, ie. without the front block containing the MAC
addresses. Switching this over to carry a full copy of the frame is
extremely intrusive as it's mixed in pretty much everywhere in the
driver.

The driver is derived from Realtek's multi-OS vendor driver, which
included code for pretty much every OS on the planet. If you want to see
how it looked initially, check out Larry's github tree and go back to
the initial checkins .... Realtek seem to copy it into a new tree and
devel from there whenever they do a new chip, so the legacy in this
codebase is huge.

Cheers,
Jes
--
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/