mbox series

[v3,0/4] mac80211: Fix incorrect usage of rhashtable walk API

Message ID 20190214140236.omt74prxhkfaasue@gondor.apana.org.au (mailing list archive)
Headers show
Series mac80211: Fix incorrect usage of rhashtable walk API | expand

Message

Herbert Xu Feb. 14, 2019, 2:02 p.m. UTC
Hi:

v3 fixes a bug in patch two where we would return a NULL pointer
when we should return an existing path.

The first two patches in this series are bug fixes and should be
backported to stable.

They fixes a number of issues with the use of the rhashtable API
in mac80211.  First of all it converts the use of rashtable walks over
to a simple linked list.  This is because an rhashtable walk is
inherently unstable and not meant for uses that require stability,
e.g., when you're trying to lookup an object to delete.

It also fixes a potential memory leak when the rhashtable insertion
fails (which can occur due to OOM).

The third patch is a code-cleanup to mac80211 while the last patch
removes an obsolete rhashtable API.

Thanks,

Comments

Johannes Berg Feb. 15, 2019, 12:21 p.m. UTC | #1
> The first two patches in this series are bug fixes and should be
> backported to stable.
> 
> They fixes a number of issues with the use of the rhashtable API
> in mac80211.  First of all it converts the use of rashtable walks over
> to a simple linked list.  This is because an rhashtable walk is
> inherently unstable and not meant for uses that require stability,
> e.g., when you're trying to lookup an object to delete.

Thanks a lot, Herbert.

Applied those now, I'll send a pull request to Dave with them. Once that
trickles back into net-next I'll apply the third patch (it doesn't apply
without the others), and then Dave you can take the rhashtable one.

Let me know if you'd prefer I take the rhashtable one through my tree,
which really would be only so you don't have to track the dependency.

NB: it'd be easier in patchwork if you tagged all the patches with v3 in
their own PATCH tag, or put the "v3" tag into the actual subject (not
the "[PATCH 0/4]" tag because evidently patchwork drops the tags and
doesn't track them for the *series* just each *patch* ... so with what
you did nothing is visible in patchwork, even just appending "(v3)" to
the subject of the cover letter would've fixed that...

johannes
Herbert Xu Feb. 18, 2019, 10:25 a.m. UTC | #2
On Fri, Feb 15, 2019 at 01:21:55PM +0100, Johannes Berg wrote:
> 
> Applied those now, I'll send a pull request to Dave with them. Once that
> trickles back into net-next I'll apply the third patch (it doesn't apply
> without the others), and then Dave you can take the rhashtable one.

Thanks Johannes.

> Let me know if you'd prefer I take the rhashtable one through my tree,
> which really would be only so you don't have to track the dependency.

I don't mind.

> NB: it'd be easier in patchwork if you tagged all the patches with v3 in
> their own PATCH tag, or put the "v3" tag into the actual subject (not
> the "[PATCH 0/4]" tag because evidently patchwork drops the tags and
> doesn't track them for the *series* just each *patch* ... so with what
> you did nothing is visible in patchwork, even just appending "(v3)" to
> the subject of the cover letter would've fixed that...

Noted.

Cheers,