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
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
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 EEXIST
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 o
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 insertio
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 suggeste
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 m
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 thi
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,
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 has
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 collisions, so I am going to wor
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 reverting it's use in mac80211.
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 y
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 the
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 mac8
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
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.
Thanks,
Ben
On 03/28/2016 01:29 PM, Ben Greear wrote:
Hello!
I have a use case for mac80211 where I create multiple sta
Hello!
I have a use case for mac80211 where I create multiple stations to
the same remote peer MAC address.
I'm seeing cases where the rhashtable logic is returning -16 (EBUSY)
on insert (see sta_info_hash_add).
This is with the 4.4.6+ (plus local patches) kernel, and it has the patch
mentioned
18 matches
Mail list logo
