From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: kernel test robot <rong.a.chen@intel.com>
Cc: Barret Rhoden <brho@google.com>, Tejun Heo <tj@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
lkp@01.org
Subject: Re: [LKP] [rcu] f836ea2ec9: BUG:unable_to_handle_kernel
Date: Thu, 21 Mar 2019 09:43:40 -0700 [thread overview]
Message-ID: <20190321164340.GV4102@linux.ibm.com> (raw)
In-Reply-To: <20190321084936.GK2813@shao2-debian>
On Thu, Mar 21, 2019 at 04:49:37PM +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: f836ea2ec954a20af25861e68075ad743be046f4 ("rcu: Forbid DEFINE{,_STATIC}_SRCU() from modules")
> https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git dev.2019.03.18a
This commit has been replaced by eb89abcb3073 ("rcu: Forbid
DEFINE{,_STATIC}_SRCU() from modules"), but this did locate an otherwise
mostly latent bug, the fix for which is shown below.
So thank you again. ;-)
Thanx, Paul
------------------------------------------------------------------------
commit 6534d5b0f24accd71620873980ba5a14aa85e898
Author: Paul E. McKenney <paulmck@linux.ibm.com>
Date: Thu Mar 21 09:27:28 2019 -0700
rcutorture: Fix cleanup path for invalid torture_type strings
If the specified rcutorture.torture_type is not in the rcu_torture_init()
function's torture_ops[] array, rcutorture prints some console messages
and then invokes rcu_torture_cleanup() to set state so that a future
torture test can run. However, rcu_torture_cleanup() also attempts to
end the test that didn't actually start, and in doing so relies on the
value of cur_ops, a value that is not particularly relevant in this case.
This can result in confusing output or even follow-on failures due to
attempts to use facilities that have not been properly initialized.
This commit therefore sets the value of cur_ops to NULL in this case
and inserts a check near the beginning of rcu_torture_cleanup(),
thus avoiding relying on an irrelevant cur_ops value.
Reported-by: kernel test robot <rong.a.chen@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 7086caa743c7..af31ddee7b36 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -2101,6 +2101,10 @@ rcu_torture_cleanup(void)
cur_ops->cb_barrier();
return;
}
+ if (!cur_ops) {
+ torture_cleanup_end();
+ return;
+ }
rcu_torture_barrier_cleanup();
torture_stop_kthread(rcu_torture_fwd_prog, fwd_prog_task);
@@ -2281,6 +2285,7 @@ rcu_torture_init(void)
pr_cont("\n");
WARN_ON(!IS_MODULE(CONFIG_RCU_TORTURE_TEST));
firsterr = -EINVAL;
+ cur_ops = NULL;
goto unwind;
}
if (cur_ops->fqs == NULL && fqs_duration != 0) {
prev parent reply other threads:[~2019-03-21 16:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-21 8:49 [rcu] f836ea2ec9: BUG:unable_to_handle_kernel kernel test robot
2019-03-21 8:49 ` [LKP] " kernel test robot
2019-03-21 16:43 ` Paul E. McKenney [this message]
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=20190321164340.GV4102@linux.ibm.com \
--to=paulmck@linux.ibm.com \
--cc=brho@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=rong.a.chen@intel.com \
--cc=tj@kernel.org \
/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.