linux-kernel - [RFC] rcu: use killable versions of swait

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 14 Jun 2017 16:06:39 -0700
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     paulmck@...ux.vnet.ibm.com, josh@...htriplett.org,
        rostedt@...dmis.org, mathieu.desnoyers@...icios.com,
        jiangshanlai@...il.com
Cc:     paul.gortmaker@...driver.com, ebiederm@...ssion.com,
        dmitry.torokhov@...il.com, linux-kernel@...r.kernel.org,
        "Luis R. Rodriguez" <mcgrof@...nel.org>
Subject: [RFC] rcu: use killable versions of swait

These waits don't even check for the return value for interruption,
using the non-killable variants means we could be killed by other
signals than SIGKILL, this is fragile.

Signed-off-by: Luis R. Rodriguez <mcgrof@...nel.org>
---

The killable swaits were just posted [1] as part of a series where SIGCHLD
was detected as interrupting and killing kernel calls waiting using
non-killable swaits [1]. The fragility here made curious about other callers
and seeing if they really meant to use such broad wait which captures a lot
of signals.

I can't see why we'd want to have these killed by other signals, specialy
since it seems we don't even check for the return value... Granted to abort
properly we'd have to check for the return value for -ERESTARTSYS, but yeah,
none of this is done, so it would seem we don't want fragile signals
interrupting these ?

Also can someone confirm if the original change of to swait_event_timeout()
from wait_event_interruptible_timeout() was actually intentional on
synchronize_sched_expedited_wait() on commit abedf8e2419fb ("rcu: Use simple
wait queues where possible in rcutree") ? I can't easily confirm.

[0] https://lkml.kernel.org/r/20170614222017.14653-3-mcgrof@kernel.org
[1] https://lkml.kernel.org/r/20170614222017.14653-1-mcgrof@kernel.org

 kernel/rcu/tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 695fee7cafe0..9a8d06486a3c 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -2191,7 +2191,7 @@ static int __noreturn rcu_gp_kthread(void *arg)
 					       READ_ONCE(rsp->gpnum),
 					       TPS("reqwait"));
 			rsp->gp_state = RCU_GP_WAIT_GPS;
-			swait_event_interruptible(rsp->gp_wq,
+			swait_event_killable(rsp->gp_wq,
 						 READ_ONCE(rsp->gp_flags) &
 						 RCU_GP_FLAG_INIT);
 			rsp->gp_state = RCU_GP_DONE_GPS;
@@ -2224,7 +2224,7 @@ static int __noreturn rcu_gp_kthread(void *arg)
 					       READ_ONCE(rsp->gpnum),
 					       TPS("fqswait"));
 			rsp->gp_state = RCU_GP_WAIT_FQS;
-			ret = swait_event_interruptible_timeout(rsp->gp_wq,
+			ret = swait_event_killable_timeout(rsp->gp_wq,
 					rcu_gp_fqs_check_wake(rsp, &gf), j);
 			rsp->gp_state = RCU_GP_DOING_FQS;
 			/* Locking provides needed memory barriers. */
-- 
2.11.0