On Mon, 2016-09-19 at 18:48 +0800, Herbert Xu wrote:
> On Mon, Sep 19, 2016 at 12:10:27PM +0200, Johannes Berg wrote:
> >
> > Btw, for debug I put
> >
> > BUG_ON(atomic_read(&ht->nelems) < 0);
> >
> > after the atomic_dec() in __rhashtable_remove_fast_one(). That
> > makes
> > the kernel crash i
On Mon, Sep 19, 2016 at 12:10:27PM +0200, Johannes Berg wrote:
> Btw, for debug I put
>
> BUG_ON(atomic_read(&ht->nelems) < 0);
>
> after the atomic_dec() in __rhashtable_remove_fast_one(). That makes
> the kernel crash instantly on the buggy code, and I just have to run a
> single test ("wpas_ct
Btw, for debug I put
BUG_ON(atomic_read(&ht->nelems) < 0);
after the atomic_dec() in __rhashtable_remove_fast_one(). That makes
the kernel crash instantly on the buggy code, and I just have to run a
single test ("wpas_ctrl_interface_add_many") to get there.
johannes
On Mon, 2016-09-19 at 12:02 +0200, Johannes Berg wrote:
> On Mon, 2016-09-19 at 11:54 +0200, Johannes Berg wrote:
> >
> > >
> > >
> > > The stack trace is useless, but my other annotation showed that
> > > the
> > > table's nelems *underflowed* to -1, so now the worker will
> > > continue
> > >
On Mon, 2016-09-19 at 11:54 +0200, Johannes Berg wrote:
> >
> > The stack trace is useless, but my other annotation showed that the
> > table's nelems *underflowed* to -1, so now the worker will continue
> > to try to grow it forever.
> >
>
> And this *was* actually a case of duplication, afaict
> The stack trace is useless, but my other annotation showed that the
> table's nelems *underflowed* to -1, so now the worker will continue
> to try to grow it forever.
>
And this *was* actually a case of duplication, afaict, since it was
multiple virtual interfaces on the same device all connec
On Mon, 2016-09-19 at 17:34 +0800, Herbert Xu wrote:
> On Mon, Sep 19, 2016 at 11:27:24AM +0200, Johannes Berg wrote:
> >
> >
> > I have a feeling there's a bug with ht->nelems, since the crash is
> > always in the grow worker, but I haven't quite put my finger on it
> > yet.
>
> Can you show me
On Mon, 2016-09-19 at 17:34 +0800, Herbert Xu wrote:
> On Mon, Sep 19, 2016 at 11:27:24AM +0200, Johannes Berg wrote:
> >
> >
> > I have a feeling there's a bug with ht->nelems, since the crash is
> > always in the grow worker, but I haven't quite put my finger on it
> > yet.
>
> Can you show me
On Mon, Sep 19, 2016 at 11:27:24AM +0200, Johannes Berg wrote:
>
> I have a feeling there's a bug with ht->nelems, since the crash is
> always in the grow worker, but I haven't quite put my finger on it yet.
Can you show me a stack trace?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.a
On Mon, 2016-09-19 at 11:27 +0200, Johannes Berg wrote:
> >
> I have a feeling there's a bug with ht->nelems, since the crash is
> always in the grow worker, but I haven't quite put my finger on it
> yet.
>
Btw, I should not actually get into the duplicate case here.
johannes
> What does your test suite actually do? Is it something that I
> can run without special hardware?
Yes, it's pretty simple - it spins up a number of VMs with hwsim and
just runs a lot of tests:
https://w1.fi/cgit/hostap/tree/tests/hwsim
I've attached a kernel .config you can use for it.
I'm r
On Mon, Sep 19, 2016 at 11:15:30AM +0200, Johannes Berg wrote:
> On Mon, 2016-09-19 at 16:40 +0800, Herbert Xu wrote:
>
> > I've tested the rhlist code with test_rhashtable but I haven't
> > tested the mac80211 conversion. So please give it a go and see
> > if it still works.
>
> This is still r
On Mon, 2016-09-19 at 16:40 +0800, Herbert Xu wrote:
> I've tested the rhlist code with test_rhashtable but I haven't
> tested the mac80211 conversion. So please give it a go and see
> if it still works.
This is still running out of memory on my test suite.
Somehow I don't see kmemleak kicking
13 matches
Mail list logo