Re: Question on rhashtable in worst-case scenario.

On Sat, 2016-04-02 at 09:46 +0800, Herbert Xu wrote: > On Fri, Apr 01, 2016 at 11:34:10PM +0200, Johannes Berg wrote: > > > > > > I was thinking about that one - it's not obvious to me from the > > code > > how this "explicitly checking for dups" would be done or let's say > > how > > rhashtable

Re: Question on rhashtable in worst-case scenario.

On Fri, Apr 01, 2016 at 11:34:10PM +0200, Johannes Berg wrote: > > I was thinking about that one - it's not obvious to me from the code > how this "explicitly checking for dups" would be done or let's say how > rhashtable differentiates. But since it seems to work for Ben until > hitting a certain

Re: Question on rhashtable in worst-case scenario.

On Fri, 2016-04-01 at 08:46 +0800, Herbert Xu wrote: > On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote: > > > > > > Does removing this completely disable the "-EEXIST" error? I can't > > say > > I fully understand the elasticity stuff in > > __rhashtable_insert_fast(). > What

Re: Question on rhashtable in worst-case scenario.

On 03/31/2016 05:46 PM, Herbert Xu wrote: On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote: Does removing this completely disable the "-EEXIST" error? I can't say I fully understand the elasticity stuff in __rhashtable_insert_fast(). What EEXIST error are you talking about? The

Re: Question on rhashtable in worst-case scenario.

On Thu, Mar 31, 2016 at 05:29:59PM +0200, Johannes Berg wrote: > > Does removing this completely disable the "-EEXIST" error? I can't say > I fully understand the elasticity stuff in __rhashtable_insert_fast(). What EEXIST error are you talking about? The only one that can be returned on

Re: Question on rhashtable in worst-case scenario.

On Thu, 2016-03-31 at 15:50 +0800, Herbert Xu wrote: > On Thu, Mar 31, 2016 at 09:46:45AM +0200, Johannes Berg wrote: > > > > > > In this case, I think perhaps you can just patch your local system > > with > > the many interfaces connecting to the same AP to add the parameter > > Herbert

Re: Question on rhashtable in worst-case scenario.

On Thu, 2016-03-31 at 08:13 -0700, Ben Greear wrote: >  > I see insertion failure, and then later, if of course fails to delete > as well since it was never inserted to begin with.  There is no good > way to deal with insertion error, so just need to fix the hashtable. Oh, that's an oversight in

Re: Question on rhashtable in worst-case scenario.

On 03/31/2016 12:46 AM, Johannes Berg wrote: On Wed, 2016-03-30 at 09:52 -0700, Ben Greear wrote: If someone can fix rhashtable, then great. I read some earlier comments [1] back when someone else reported similar problems, and the comments seemed to indicate that rhashtable was broken in

Re: Question on rhashtable in worst-case scenario.

On Thu, Mar 31, 2016 at 09:46:45AM +0200, Johannes Berg wrote: > > In this case, I think perhaps you can just patch your local system with > the many interfaces connecting to the same AP to add the parameter > Herbert suggested (.insecure_elasticity = true in sta_rht_params). This > is, after all,

Re: Question on rhashtable in worst-case scenario.

On Wed, 2016-03-30 at 09:52 -0700, Ben Greear wrote: > If someone can fix rhashtable, then great. > I read some earlier comments [1] back when someone else reported > similar problems, and the comments seemed to indicate that rhashtable > was broken in this manner on purpose to protect against

Re: Question on rhashtable in worst-case scenario.

On 03/30/2016 09:38 AM, David Miller wrote: From: Johannes Berg Date: Wed, 30 Mar 2016 11:14:12 +0200 On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote: Looks like rhashtable has too much policy in it to properly deal with cases where there are too many hash

Re: Question on rhashtable in worst-case scenario.

From: Johannes Berg Date: Wed, 30 Mar 2016 11:14:12 +0200 > On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote: >> Looks like rhashtable has too much policy in it to properly deal with >> cases where there are too many hash collisions, so I am going to work >> on

Re: Question on rhashtable in worst-case scenario.

On Wed, Mar 30, 2016 at 04:03:08PM +0200, Johannes Berg wrote: > > But we really don't want that either - in the normal case where you > don't create all these virtual interfaces for testing, you have a > certain number of peers that can vary a lot (zero to hundreds, in > theory thousands) where

Re: Question on rhashtable in worst-case scenario.

On Wed, 2016-03-30 at 21:55 +0800, Herbert Xu wrote: > Well to start with you should assess whether you really want to > hash multiple objects with the same key.  In particular, can an > adversary generate a large number of such objects? No, the only reason this happens is local - if you take

Re: Question on rhashtable in worst-case scenario.

On Wed, Mar 30, 2016 at 11:14:12AM +0200, Johannes Berg wrote: > On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote: > > Looks like rhashtable has too much policy in it to properly deal with > > cases where there are too many hash collisions, so I am going to work > > on reverting it's use in

Re: Question on rhashtable in worst-case scenario.

On Tue, 2016-03-29 at 09:16 -0700, Ben Greear wrote: > Looks like rhashtable has too much policy in it to properly deal with > cases where there are too many hash collisions, so I am going to work > on reverting it's use in mac80211. I'm not really all that happy with that approach - can't we fix