From: Ying Xue <ying.xue@windriver.com>
To: Thomas Graf <tgraf@suug.ch>
Cc: <davem@davemloft.net>, <netdev@vger.kernel.org>,
<herbert@gondor.apana.org.au>
Subject: Re: [PATCH 0/6 v2 net-next] rhashtable fixes
Date: Fri, 6 Feb 2015 10:36:02 +0800 [thread overview]
Message-ID: <54D42892.3030808@windriver.com> (raw)
In-Reply-To: <20150205101954.GA24388@casper.infradead.org>
On 02/05/2015 06:19 PM, Thomas Graf wrote:
> On 02/05/15 at 05:14pm, Ying Xue wrote:
>> On 02/05/2015 04:47 PM, Thomas Graf wrote:
>>> On 02/05/15 at 10:32am, Ying Xue wrote:
>>>> After I applied the sires, it sounds like panic doesn't occur any more. But soft
>>>> lockup still happens although the frequency of its reproduction is much lower
>>>> than before. Please take a look at its relevant log:
>>>
>>> Thanks for testing and the report. I had run your bind_netlink test
>>> overnight on a 4 CPU VM. Anything particular that might help trigger it?
>
> Thanks. I will keep trying to reproduce. Can you try the following
> patch in the meantime?
>
After I applied the below change on the latest net-next tree with the series
patches, panic happens during kernel boot stage as follows:
[ 0.720502] smpboot: Total of 8 processors activated (54278.37 BogoMIPS)
[ 0.728325] devtmpfs: initialized
[ 0.729961] evm: security.selinux
[ 0.730308] evm: security.SMACK64
[ 0.730600] evm: security.capability
[ 0.732507] RTC time: 2:26:37, date: 02/06/15
[ 0.733240] NET: Registered protocol family 16
[ 0.733729] BUG: unable to handle kernel paging request at ffff880042724fb0
[ 0.734371] IP: [<ffffffff8139dd82>] __rhashtable_insert+0x22/0xb0
[ 0.734936] PGD 2c50067 PUD 0
[ 0.735254] Oops: 0000 [#1] SMP
[ 0.735578] Modules linked in:
[ 0.735870] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc6+ #186
[ 0.736000] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 0.736000] task: ffff880016db8000 ti: ffff880016db4000 task.ti: ffff880016db4000
[ 0.736000] RIP: 0010:[<ffffffff8139dd82>] [<ffffffff8139dd82>]
__rhashtable_insert+0x22/0xb0
[ 0.736000] RSP: 0000:ffff880016db7b78 EFLAGS: 00010286
[ 0.736000] RAX: 0000000000000000 RBX: ffff880016500000 RCX: 000000000574ff73
[ 0.736000] RDX: ffff880016ca5400 RSI: ffff88001651be08 RDI: ffff880016500000
[ 0.736000] RBP: ffff880016db7bb8 R08: 0000000000000000 R09: 0000000000000001
[ 0.736000] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880016ca5400
[ 0.736000] R13: ffff880016ca5400 R14: 000000000574ff73 R15: ffff880016ca5400
[ 0.736000] FS: 0000000000000000(0000) GS:ffff880017c00000(0000)
knlGS:0000000000000000
[ 0.736000] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 0.736000] CR2: ffff880042724fb0 CR3: 0000000001c11000 CR4: 00000000000006f0
[ 0.736000] Stack:
[ 0.736000] 0574ff7300000000 ffff880016ca5400 ffff880016db7bb8 ffff880016500000
[ 0.736000] ffff88001651be08 ffff880016ca5400 000000000574ff73 ffff880016ca5400
[ 0.736000] ffff880016db7c18 ffffffff8139e841 ffffffff8139e775 ffff88001651b800
[ 0.736000] Call Trace:
[ 0.736000] [<ffffffff8139e841>] rhashtable_lookup_compare_insert+0x101/0x110
[ 0.736000] [<ffffffff8139e775>] ? rhashtable_lookup_compare_insert+0x35/0x110
[ 0.736000] [<ffffffff8165d800>] ? jhash+0xe0/0x160
[ 0.736000] [<ffffffff8165e1b3>] ? netlink_insert+0x43/0xf0
[ 0.736000] [<ffffffff8165e201>] netlink_insert+0x91/0xf0
[ 0.736000] [<ffffffff81660a31>] __netlink_kernel_create+0x121/0x260
[ 0.736000] [<ffffffff816288cf>] ? register_pernet_subsys+0x1f/0x50
[ 0.736000] [<ffffffff8164136d>] rtnetlink_net_init+0x4d/0x70
[ 0.736000] [<ffffffff81641fe0>] ? rtnl_unlock+0x10/0x10
[ 0.736000] [<ffffffff8162848e>] ops_init+0x4e/0x150
[ 0.736000] [<ffffffff810a6afd>] ? trace_hardirqs_on+0xd/0x10
[ 0.736000] [<ffffffff81628793>] register_pernet_operations+0xf3/0x190
[ 0.736000] [<ffffffff810a6afd>] ? trace_hardirqs_on+0xd/0x10
[ 0.736000] [<ffffffff816288de>] register_pernet_subsys+0x2e/0x50
[ 0.736000] [<ffffffff81d89e03>] rtnetlink_init+0x10/0x16b
[ 0.736000] [<ffffffff81d8b0bf>] netlink_proto_init+0x194/0x1af
[ 0.736000] [<ffffffff8165d720>] ? __tcf_em_tree_match+0x160/0x160
[ 0.736000] [<ffffffff8139d380>] ? percpu_ida_alloc+0x3c0/0x3c0
[ 0.736000] [<ffffffff8139d3b0>] ? rht_grow_above_75+0x30/0x30
[ 0.736000] [<ffffffff81d8af2b>] ? tc_action_init+0x55/0x55
[ 0.736000] [<ffffffff810002d9>] do_one_initcall+0x89/0x1c0
[ 0.736000] [<ffffffff81d361a1>] kernel_init_freeable+0x1a3/0x23d
[ 0.736000] [<ffffffff81d358f2>] ? do_early_param+0x86/0x86
[ 0.736000] [<ffffffff8174fa10>] ? rest_init+0xd0/0xd0
[ 0.736000] [<ffffffff8174fa1e>] kernel_init+0xe/0xf0
[ 0.736000] [<ffffffff81766eec>] ret_from_fork+0x7c/0xb0
[ 0.736000] [<ffffffff8174fa10>] ? rest_init+0xd0/0xd0
[ 0.736000] Code: 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 ec 40 4c 89 75
f0 41 89 ce 48 89 5d d8 4c 89 65 e0 4c 89 6d e8 49 89 d4 4c 89 7d f8 <4a> 8b 54
f2 18 48 89 fb 49 89 f5 4c 89 e7 89 ce 41 89 cf 48 89
[ 0.736000] RIP [<ffffffff8139dd82>] __rhashtable_insert+0x22/0xb0
[ 0.736000] RSP <ffff880016db7b78>
[ 0.736000] CR2: ffff880042724fb0
[ 0.736000] ---[ end trace 0747bcdb7a563e55 ]---
[ 0.736000] Kernel panic - not syncing: Fatal exception in interrupt
[ 0.736000] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
Regards,
Ying
> diff --git a/lib/rhashtable.c b/lib/rhashtable.c
> index 5919d63..1c65be2 100644
> --- a/lib/rhashtable.c
> +++ b/lib/rhashtable.c
> @@ -593,7 +593,7 @@ void rhashtable_insert(struct rhashtable *ht, struct rhash_head *obj)
>
> tbl = rht_dereference_rcu(ht->future_tbl, ht);
> old_tbl = rht_dereference_rcu(ht->tbl, ht);
> - hash = head_hashfn(ht, tbl, obj);
> + hash = obj_raw_hashfn(ht, rht_obj(ht, obj));
>
> lock_buckets(tbl, old_tbl, hash);
> __rhashtable_insert(ht, obj, tbl, hash);
> @@ -835,7 +835,7 @@ bool rhashtable_lookup_compare_insert(struct rhashtable *ht,
> rcu_read_lock();
> old_tbl = rht_dereference_rcu(ht->tbl, ht);
> new_tbl = rht_dereference_rcu(ht->future_tbl, ht);
> - new_hash = head_hashfn(ht, new_tbl, obj);
> + new_hash = obj_raw_hashfn(ht, rht_obj(ht, obj));
>
> lock_buckets(new_tbl, old_tbl, new_hash);
>
>
>
>
next prev parent reply other threads:[~2015-02-06 2:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-05 1:03 [PATCH 0/6 v2 net-next] rhashtable fixes Thomas Graf
2015-02-05 1:03 ` [PATCH 1/6] rhashtable: key_hashfn() must return full hash value Thomas Graf
2015-02-05 1:03 ` [PATCH 2/6] rhashtable: Use a single bucket lock for sibling buckets Thomas Graf
2015-02-26 14:38 ` David Laight
2015-02-05 1:03 ` [PATCH 3/6] rhashtable: Wait for RCU readers after final unzip work Thomas Graf
2015-02-05 1:03 ` [PATCH 4/6] rhashtable: Dump bucket tables on locking violation under PROVE_LOCKING Thomas Graf
2015-02-05 1:03 ` [PATCH 5/6] rhashtable: Add more lock verification Thomas Graf
2015-02-05 1:03 ` [PATCH 6/6] rhashtable: Avoid bucket cross reference after removal Thomas Graf
2015-02-05 2:32 ` [PATCH 0/6 v2 net-next] rhashtable fixes Ying Xue
2015-02-05 8:47 ` Thomas Graf
2015-02-05 9:14 ` Ying Xue
2015-02-05 10:19 ` Thomas Graf
2015-02-06 2:36 ` Ying Xue [this message]
2015-02-06 10:40 ` Thomas Graf
2015-02-06 16:08 ` [PATCH net-next] rhashtable: Fix remove logic to avoid cross references between buckets Thomas Graf
2015-02-06 23:20 ` David Miller
2015-02-09 2:44 ` Ying Xue
2015-02-05 23:43 ` [PATCH 0/6 v2 net-next] rhashtable fixes David Miller
2015-02-06 23:20 ` David Miller
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=54D42892.3030808@windriver.com \
--to=ying.xue@windriver.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--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.