From: Ying Xue <ying.xue@windriver.com>
To: Thomas Graf <tgraf@suug.ch>
Cc: <davem@davemloft.net>, <netdev@vger.kernel.org>
Subject: Re: [PATCH 0/6 net-next] rhashtable fixes
Date: Fri, 30 Jan 2015 17:56:51 +0800 [thread overview]
Message-ID: <54CB5563.9080000@windriver.com> (raw)
In-Reply-To: <20150130092911.GA2313@casper.infradead.org>
On 01/30/2015 05:29 PM, Thomas Graf wrote:
> On 01/30/15 at 05:10pm, Ying Xue wrote:
>> Hi Thomas,
>>
>> I make sure that my local net-next tree is synchronized to the latest
>> version in which the commit fe6a043c535acfec8f8e554536c87923dcb45097
>> ("rhashtable: rhashtable_remove() must unlink in both tbl and
>> future_tbl") is already contained, and then I manually applied the whole
>> series patches. But when I repeatedly run the test case I originally
>> posted, soft lockup happens. Please see its relevant log:
>
> Right, I see the same soft lockup. Interestingly I cannot trigger it
> with the rht test code. I can only trigger it with your Netlink socket
> creation stress test. It is definitely related to the deferred worker,
> when I disable growing, then the bug disappears.
Yes, when I disable expansion, the soft lockup also disappears too.
I think that the
> expansion leaves a race open in which remove cannot find certain entries
> (I verified this by adding a BUG_ON() when rhashtable_remove() could not
> find a match). This then keeps an entry on the list which has already
> been freed.
>
> However, I think this was present before these fixes but hidden as the
> lockup requires a lot more iterations of your stress test on my
> machine.
>
If you need to some verification for your new patches or do some
experiments, please let me know, and I can help to do them.
Regards,
Ying
next prev parent reply other threads:[~2015-01-30 9:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-30 0:20 [PATCH 0/6 net-next] rhashtable fixes Thomas Graf
2015-01-30 0:20 ` [PATCH 1/6] rhashtable: key_hashfn() must return full hash value Thomas Graf
2015-01-30 0:20 ` [PATCH 2/6] rhashtable: Use a single bucket lock for sibling buckets Thomas Graf
2015-01-31 4:34 ` Herbert Xu
2015-01-31 8:41 ` Thomas Graf
2015-01-31 9:38 ` Herbert Xu
2015-01-31 12:50 ` Thomas Graf
2015-01-30 0:20 ` [PATCH 3/6] rhashtable: Wait for RCU readers after final unzip work Thomas Graf
2015-01-30 0:20 ` [PATCH 4/6] rhashtable: Dump bucket tables on locking violation under PROVE_LOCKING Thomas Graf
2015-01-30 0:20 ` [PATCH 5/6] rhashtable: Add more lock verification Thomas Graf
2015-01-30 0:20 ` [PATCH 6/6] rhashtable: Avoid bucket cross reference after removal Thomas Graf
2015-01-30 9:10 ` [PATCH 0/6 net-next] rhashtable fixes Ying Xue
2015-01-30 9:29 ` Thomas Graf
2015-01-30 9:56 ` Ying Xue [this message]
2015-02-03 17:21 ` Thomas Graf
2015-02-04 2:32 ` Ying Xue
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54CB5563.9080000@windriver.com \
--to=ying.xue@windriver.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=tgraf@suug.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.