Re: Buggy rhashtable walking
On Fri, Aug 05, 2016 at 04:46:43AM -0700, Ben Greear wrote: > > It would not be fun to have to revert to the old way of hashing > stations in mac80211... > > I'll be happy to test the patches when you have them ready. Thanks for the offer. Unfortunately it'll be a few days before I'm ready because I need to work through some crypto patches first. Cheers, -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Buggy rhashtable walking
On 08/05/2016 03:50 AM, Johannes Berg wrote: On Fri, 2016-08-05 at 18:48 +0800, Herbert Xu wrote: On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote: Hm. Would you rather allocate a separate head entry for the hashtable, or chain the entries? My plan is to build support for this directly into rhashtable. So I'm adding a struct rhlist_head that would be used in place of rhash_head for these cases and it'll carry an extra pointer for the list of identical entries. I will then add an additional layer of insert/lookup interfaces for rhlist_head. Herbert, thank you for fixing this! It would not be fun to have to revert to the old way of hashing stations in mac80211... I'll be happy to test the patches when you have them ready. Ben -- Ben GreearCandela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Buggy rhashtable walking
On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote: > > Hm. Would you rather allocate a separate head entry for the hashtable, > or chain the entries? My plan is to build support for this directly into rhashtable. So I'm adding a struct rhlist_head that would be used in place of rhash_head for these cases and it'll carry an extra pointer for the list of identical entries. I will then add an additional layer of insert/lookup interfaces for rhlist_head. So bottom-line is that if you have no identical entries that you only incur an extra 8 bytes per-object. Cheers, -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Buggy rhashtable walking
On Fri, 2016-08-05 at 18:48 +0800, Herbert Xu wrote: > On Fri, Aug 05, 2016 at 08:16:53AM +0200, Johannes Berg wrote: > > > > Hm. Would you rather allocate a separate head entry for the > > hashtable, > > or chain the entries? > > My plan is to build support for this directly into rhashtable. > So I'm adding a struct rhlist_head that would be used in place > of rhash_head for these cases and it'll carry an extra pointer > for the list of identical entries. > > I will then add an additional layer of insert/lookup interfaces > for rhlist_head. Oh, ok. > So bottom-line is that if you have no identical entries that you > only incur an extra 8 bytes per-object. > Right. Thanks! johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Buggy rhashtable walking
> So I'm going to fix this by consolidating identical objects into > a single rhashtable entry which also lets us get rid of the > insecure_elasticity setting. Hm. Would you rather allocate a separate head entry for the hashtable, or chain the entries? (Luckily) the colliding key case practically never happens, and some drivers don't even allow it, so that's perhaps something to keep in mind for this. Perhaps we should just generally disallow it - but a few people (hi Ben) would be really unhappy about that I guess. I think this might affect more than one use of rhashtable in mac80211 now, since the mesh paths also use it. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Buggy rhashtable walking
On Thu, Aug 04, 2016 at 03:18:46PM +0800, Herbert Xu wrote: > > So the question is can wireless handle seeing an entry multiple > times? In particular, __ieee80211_rx_handle_packet would appear > to process the same packet multiple times if this were to happen. It's worse than I thought. In fact it's not walking the table at all, rather it's doing a hash lookup by hand! This cannot possibly work given that rhashtable makes use of multiple hash tables. In fact this also demonstrates why putting multiple identical objects into the same table is crap. Because there is no sane way of returning all objects corresponding to a single key, given that they may be spread over multiple tables. So I'm going to fix this by consolidating identical objects into a single rhashtable entry which also lets us get rid of the insecure_elasticity setting. So the next time someone comes along and wants to add multiple objects with the same key to one table, please just say no. Thanks, -- Email: Herbert XuHome Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html