* Re: [rhashtable] 5d60de5ff1 [ INFO: suspicious RCU usage. ] [not found] <20170218052331.dlr4si7gbhnukewb@wfg-t540p.sh.intel.com> @ 2017-02-25 14:39 ` Herbert Xu 2017-02-27 2:34 ` David Miller 2017-02-27 4:31 ` [LKP] " Ye Xiaolong 0 siblings, 2 replies; 3+ messages in thread From: Herbert Xu @ 2017-02-25 14:39 UTC (permalink / raw) To: Fengguang Wu; +Cc: LKP, netdev, Thomas Graf On Sat, Feb 18, 2017 at 01:23:31PM +0800, Fengguang Wu wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://github.com/0day-ci/linux Herbert-Xu/rhashtable-Handle-table-allocation-failure-during-insertion/20170212-030221 > > commit 5d60de5ff12fb1e966c863bcb41c1e2bdde66c50 > Author: Herbert Xu <herbert@gondor.apana.org.au> > AuthorDate: Sat Feb 11 19:26:47 2017 +0800 > Commit: 0day robot <fengguang.wu@intel.com> > CommitDate: Sun Feb 12 03:02:26 2017 +0800 > > rhashtable: Add nested tables > > This patch adds code that handles GFP_ATOMIC kmalloc failure on > insertion. As we cannot use vmalloc, we solve it by making our > hash table nested. That is, we allocate single pages at each level > and reach our desired table size by nesting them. > > When a nested table is created, only a single page is allocated > at the top-level. Lower levels are allocated on demand during > insertion. Therefore for each insertion to succeed, only two > (non-consecutive) pages are needed. > > After a nested table is created, a rehash will be scheduled in > order to switch to a vmalloced table as soon as possible. Also, > the rehash code will never rehash into a nested table. If we > detect a nested table during a rehash, the rehash will be aborted > and a new rehash will be scheduled. > > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> > > +------------------------------------------------------------------+------------+------------+------------------+ > | | eadcee1e3a | 5d60de5ff1 | v4.10-rc8_021716 | > +------------------------------------------------------------------+------------+------------+------------------+ > | boot_successes | 0 | 0 | 9 | > | boot_failures | 177 | 48 | 82 | > | Kernel_panic-not_syncing:softlockup:hung_tasks | 177 | 48 | 14 | > | INFO:suspicious_RCU_usage | 0 | 39 | 64 | > | BUG:KASAN:user-memory-access_on_address | 0 | 0 | 16 | > | BUG:unable_to_handle_kernel | 0 | 0 | 18 | > | Oops | 0 | 0 | 18 | > | Kernel_panic-not_syncing:Fatal_exception | 0 | 0 | 18 | > | BUG:kernel_hang_in_test_stage | 0 | 0 | 19 | > | WARNING:at_kernel/sched/sched.h:#set_next_entity | 0 | 0 | 15 | > | INFO:possible_circular_locking_dependency_detected | 0 | 0 | 4 | > | WARNING:at_include/linux/cpumask.h:#find_get_context | 0 | 0 | 2 | > | invoked_oom-killer:gfp_mask=0x | 0 | 0 | 4 | > | Mem-Info | 0 | 0 | 4 | > | Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 0 | 0 | 4 | > | Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= | 0 | 0 | 7 | > +------------------------------------------------------------------+------------+------------+------------------+ > > [ 9.022401] Testing concurrent rhashtable access from 10 threads > [ 15.800003] > [ 15.801145] =============================== > [ 15.801802] [ INFO: suspicious RCU usage. ] > [ 15.802476] 4.10.0-rc7-00090-g5d60de5 #1 Not tainted > [ 15.803235] ------------------------------- > [ 15.803866] lib/rhashtable.c:1126 suspicious rcu_dereference_protected() usage! Sorry, I chose the wrong annotation to fix the previous report. This patch should fix it completely. ---8<--- Subject: rhashtable: Fix RCU dereference annotation in rht_bucket_nested The current annotation is wrong as it says that we're only called under spinlock. In fact it should be marked as under either spinlock or RCU read lock. Fixes: da20420f83ea ("rhashtable: Add nested tables") Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> --- lib/rhashtable.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/rhashtable.c b/lib/rhashtable.c index fac1a78..c5b9b93 100644 --- a/lib/rhashtable.c +++ b/lib/rhashtable.c @@ -1121,12 +1121,13 @@ struct rhash_head __rcu **rht_bucket_nested(const struct bucket_table *tbl, union nested_table *ntbl; ntbl = (union nested_table *)rcu_dereference_raw(tbl->buckets[0]); - ntbl = rht_dereference_bucket(ntbl[index].table, tbl, hash); + ntbl = rht_dereference_bucket_rcu(ntbl[index].table, tbl, hash); subhash >>= tbl->nest; while (ntbl && size > (1 << shift)) { index = subhash & ((1 << shift) - 1); - ntbl = rht_dereference_bucket(ntbl[index].table, tbl, hash); + ntbl = rht_dereference_bucket_rcu(ntbl[index].table, + tbl, hash); size >>= shift; subhash >>= shift; } -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [rhashtable] 5d60de5ff1 [ INFO: suspicious RCU usage. ] 2017-02-25 14:39 ` [rhashtable] 5d60de5ff1 [ INFO: suspicious RCU usage. ] Herbert Xu @ 2017-02-27 2:34 ` David Miller 2017-02-27 4:31 ` [LKP] " Ye Xiaolong 1 sibling, 0 replies; 3+ messages in thread From: David Miller @ 2017-02-27 2:34 UTC (permalink / raw) To: herbert; +Cc: fengguang.wu, lkp, netdev, tgraf From: Herbert Xu <herbert@gondor.apana.org.au> Date: Sat, 25 Feb 2017 22:39:50 +0800 > Subject: rhashtable: Fix RCU dereference annotation in rht_bucket_nested > > The current annotation is wrong as it says that we're only called > under spinlock. In fact it should be marked as under either > spinlock or RCU read lock. > > Fixes: da20420f83ea ("rhashtable: Add nested tables") > Reported-by: Fengguang Wu <fengguang.wu@intel.com> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Applied. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [LKP] [rhashtable] 5d60de5ff1 [ INFO: suspicious RCU usage. ] 2017-02-25 14:39 ` [rhashtable] 5d60de5ff1 [ INFO: suspicious RCU usage. ] Herbert Xu 2017-02-27 2:34 ` David Miller @ 2017-02-27 4:31 ` Ye Xiaolong 1 sibling, 0 replies; 3+ messages in thread From: Ye Xiaolong @ 2017-02-27 4:31 UTC (permalink / raw) To: Herbert Xu; +Cc: Fengguang Wu, Thomas Graf, netdev, LKP On 02/25, Herbert Xu wrote: >On Sat, Feb 18, 2017 at 01:23:31PM +0800, Fengguang Wu wrote: >> Greetings, >> >> 0day kernel testing robot got the below dmesg and the first bad commit is >> >> https://github.com/0day-ci/linux Herbert-Xu/rhashtable-Handle-table-allocation-failure-during-insertion/20170212-030221 >> >> commit 5d60de5ff12fb1e966c863bcb41c1e2bdde66c50 >> Author: Herbert Xu <herbert@gondor.apana.org.au> >> AuthorDate: Sat Feb 11 19:26:47 2017 +0800 >> Commit: 0day robot <fengguang.wu@intel.com> >> CommitDate: Sun Feb 12 03:02:26 2017 +0800 >> >> rhashtable: Add nested tables >> >> This patch adds code that handles GFP_ATOMIC kmalloc failure on >> insertion. As we cannot use vmalloc, we solve it by making our >> hash table nested. That is, we allocate single pages at each level >> and reach our desired table size by nesting them. >> >> When a nested table is created, only a single page is allocated >> at the top-level. Lower levels are allocated on demand during >> insertion. Therefore for each insertion to succeed, only two >> (non-consecutive) pages are needed. >> >> After a nested table is created, a rehash will be scheduled in >> order to switch to a vmalloced table as soon as possible. Also, >> the rehash code will never rehash into a nested table. If we >> detect a nested table during a rehash, the rehash will be aborted >> and a new rehash will be scheduled. >> >> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> >> >> +------------------------------------------------------------------+------------+------------+------------------+ >> | | eadcee1e3a | 5d60de5ff1 | v4.10-rc8_021716 | >> +------------------------------------------------------------------+------------+------------+------------------+ >> | boot_successes | 0 | 0 | 9 | >> | boot_failures | 177 | 48 | 82 | >> | Kernel_panic-not_syncing:softlockup:hung_tasks | 177 | 48 | 14 | >> | INFO:suspicious_RCU_usage | 0 | 39 | 64 | >> | BUG:KASAN:user-memory-access_on_address | 0 | 0 | 16 | >> | BUG:unable_to_handle_kernel | 0 | 0 | 18 | >> | Oops | 0 | 0 | 18 | >> | Kernel_panic-not_syncing:Fatal_exception | 0 | 0 | 18 | >> | BUG:kernel_hang_in_test_stage | 0 | 0 | 19 | >> | WARNING:at_kernel/sched/sched.h:#set_next_entity | 0 | 0 | 15 | >> | INFO:possible_circular_locking_dependency_detected | 0 | 0 | 4 | >> | WARNING:at_include/linux/cpumask.h:#find_get_context | 0 | 0 | 2 | >> | invoked_oom-killer:gfp_mask=0x | 0 | 0 | 4 | >> | Mem-Info | 0 | 0 | 4 | >> | Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 0 | 0 | 4 | >> | Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= | 0 | 0 | 7 | >> +------------------------------------------------------------------+------------+------------+------------------+ >> >> [ 9.022401] Testing concurrent rhashtable access from 10 threads >> [ 15.800003] >> [ 15.801145] =============================== >> [ 15.801802] [ INFO: suspicious RCU usage. ] >> [ 15.802476] 4.10.0-rc7-00090-g5d60de5 #1 Not tainted >> [ 15.803235] ------------------------------- >> [ 15.803866] lib/rhashtable.c:1126 suspicious rcu_dereference_protected() usage! > >Sorry, I chose the wrong annotation to fix the previous report. >This patch should fix it completely. This warning is gone with the fix patch in 0day environment. Tested-by: Xiaolong Ye <xiaolong.ye@intel.com> Thanks, Xiaolong > >---8<--- >Subject: rhashtable: Fix RCU dereference annotation in rht_bucket_nested > >The current annotation is wrong as it says that we're only called >under spinlock. In fact it should be marked as under either >spinlock or RCU read lock. > >Fixes: da20420f83ea ("rhashtable: Add nested tables") >Reported-by: Fengguang Wu <fengguang.wu@intel.com> >Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> >--- > > lib/rhashtable.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > >diff --git a/lib/rhashtable.c b/lib/rhashtable.c >index fac1a78..c5b9b93 100644 >--- a/lib/rhashtable.c >+++ b/lib/rhashtable.c >@@ -1121,12 +1121,13 @@ struct rhash_head __rcu **rht_bucket_nested(const struct bucket_table *tbl, > union nested_table *ntbl; > > ntbl = (union nested_table *)rcu_dereference_raw(tbl->buckets[0]); >- ntbl = rht_dereference_bucket(ntbl[index].table, tbl, hash); >+ ntbl = rht_dereference_bucket_rcu(ntbl[index].table, tbl, hash); > subhash >>= tbl->nest; > > while (ntbl && size > (1 << shift)) { > index = subhash & ((1 << shift) - 1); >- ntbl = rht_dereference_bucket(ntbl[index].table, tbl, hash); >+ ntbl = rht_dereference_bucket_rcu(ntbl[index].table, >+ tbl, hash); > size >>= shift; > subhash >>= shift; > } >-- >Email: Herbert Xu <herbert@gondor.apana.org.au> >Home Page: http://gondor.apana.org.au/~herbert/ >PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt >_______________________________________________ >LKP mailing list >LKP@lists.01.org >https://lists.01.org/mailman/listinfo/lkp ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-02-27 8:17 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20170218052331.dlr4si7gbhnukewb@wfg-t540p.sh.intel.com>
2017-02-25 14:39 ` [rhashtable] 5d60de5ff1 [ INFO: suspicious RCU usage. ] Herbert Xu
2017-02-27 2:34 ` David Miller
2017-02-27 4:31 ` [LKP] " Ye Xiaolong
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).