linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Eric W. Biederman" <ebiederm@xmission.com>
To: linux-kernel@vger.kernel.org
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Linux Containers <containers@lists.linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	linux-arch@vger.kernel.org,
	Philipp Reisner <philipp.reisner@linbit.com>,
	Lars Ellenberg <lars.ellenberg@linbit.com>,
	drbd-dev@lists.linbit.com
Subject: [REVIEW][PATCH 04/26] signal/drbd: Use send_sig not force_sig
Date: Wed, 22 May 2019 19:38:54 -0500	[thread overview]
Message-ID: <20190523003916.20726-5-ebiederm@xmission.com> (raw)
In-Reply-To: <20190523003916.20726-1-ebiederm@xmission.com>

The drbd module exclusively sends signals to kernel threads it creates with
kthread_create.  These kernel threads do not block or ignore signals (only
flush signals after they have been delivered), nor can drbd threads
possibly be pid namespace init processes so the extra work that force_sig
performs that send_sig does not is unnecessary.

Further force_sig is for delivering synchronous signals (aka exceptions).
The locking in force_sig is not prepared to deal with running processes, as
tsk->sighand may change during exec for a running process.

In short it is not only unnecessary for drbd to use force_sig it is
semantically wrong.

With drbd using send_sig it becomes easier to maintain force_sig as only
synchronous signals need to be considered.

Cc: Philipp Reisner <philipp.reisner@linbit.com>
Cc: Lars Ellenberg <lars.ellenberg@linbit.com>
Cc: drbd-dev@lists.linbit.com
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
 drivers/block/drbd/drbd_int.h  | 2 +-
 drivers/block/drbd/drbd_main.c | 2 +-
 drivers/block/drbd/drbd_nl.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/block/drbd/drbd_int.h b/drivers/block/drbd/drbd_int.h
index 549c64df9708..035829435710 100644
--- a/drivers/block/drbd/drbd_int.h
+++ b/drivers/block/drbd/drbd_int.h
@@ -1972,7 +1972,7 @@ static inline void wake_ack_receiver(struct drbd_connection *connection)
 {
 	struct task_struct *task = connection->ack_receiver.task;
 	if (task && get_t_state(&connection->ack_receiver) == RUNNING)
-		force_sig(SIGXCPU, task);
+		send_sig(SIGXCPU, task, 1);
 }
 
 static inline void request_ping(struct drbd_connection *connection)
diff --git a/drivers/block/drbd/drbd_main.c b/drivers/block/drbd/drbd_main.c
index 714eb64fabfd..8597aefe027b 100644
--- a/drivers/block/drbd/drbd_main.c
+++ b/drivers/block/drbd/drbd_main.c
@@ -477,7 +477,7 @@ void _drbd_thread_stop(struct drbd_thread *thi, int restart, int wait)
 		smp_mb();
 		init_completion(&thi->stop);
 		if (thi->task != current)
-			force_sig(DRBD_SIGKILL, thi->task);
+			send_sig(DRBD_SIGKILL, thi->task, 1);
 	}
 
 	spin_unlock_irqrestore(&thi->t_lock, flags);
diff --git a/drivers/block/drbd/drbd_nl.c b/drivers/block/drbd/drbd_nl.c
index 1cb5a0b85fd9..638b3ba9b976 100644
--- a/drivers/block/drbd/drbd_nl.c
+++ b/drivers/block/drbd/drbd_nl.c
@@ -611,7 +611,7 @@ void conn_try_outdate_peer_async(struct drbd_connection *connection)
 	struct task_struct *opa;
 
 	kref_get(&connection->kref);
-	/* We may just have force_sig()'ed this thread
+	/* We may have just sent a signal to this thread
 	 * to get it out of some blocking network function.
 	 * Clear signals; otherwise kthread_run(), which internally uses
 	 * wait_on_completion_killable(), will mistake our pending signal
-- 
2.21.0


  parent reply	other threads:[~2019-05-23  0:40 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23  0:38 [REVIEW][PATCH 00/26] signal: Remove task argument from force_sig_info Eric W. Biederman
2019-05-23  0:38 ` [REVIEW][PATCH 01/26] signal: Correct namespace fixups of si_pid and si_uid Eric W. Biederman
     [not found]   ` <20190529131503.F2AC221871@mail.kernel.org>
2019-05-29 15:18     ` Eric W. Biederman
2019-05-23  0:38 ` [REVIEW][PATCH 02/26] signal/ptrace: Simplify and fix PTRACE_KILL Eric W. Biederman
2019-05-29 14:35   ` Eric W. Biederman
2019-05-23  0:38 ` [REVIEW][PATCH 03/26] signal/arm64: Use force_sig not force_sig_fault for SIGKILL Eric W. Biederman
2019-05-23 10:17   ` Will Deacon
2019-05-23 14:59     ` Eric W. Biederman
2019-05-23 16:11     ` [REVIEW][PATCHv2 " Eric W. Biederman
2019-05-23 16:15       ` Will Deacon
2019-05-23 20:59         ` Eric W. Biederman
2019-05-24 10:00           ` Will Deacon
2019-05-24 22:36             ` Eric W. Biederman
2019-05-29 15:12               ` Will Deacon
2019-05-29 15:34                 ` Eric W. Biederman
2019-05-23 10:21   ` [REVIEW][PATCH " Dave Martin
2019-05-23 14:53     ` Eric W. Biederman
2019-05-23 16:12       ` Dave P Martin
2019-05-23 21:00         ` Eric W. Biederman
2019-05-23  0:38 ` Eric W. Biederman [this message]
2019-05-23  0:38 ` [REVIEW][PATCH 05/26] signal/bpfilter: Fix bpfilter_kernl to use send_sig not force_sig Eric W. Biederman
2019-05-23  0:38 ` [REVIEW][PATCH 06/26] signal/pid_namespace: Fix reboot_pid_ns " Eric W. Biederman
2019-05-23  0:38 ` [REVIEW][PATCH 07/26] signal/cifs: Fix cifs_put_tcp_session to call send_sig instead of force_sig Eric W. Biederman
2019-05-23  0:38 ` [REVIEW][PATCH 08/26] signal: Remove task parameter from force_sigsegv Eric W. Biederman
2019-05-23  0:38 ` [REVIEW][PATCH 09/26] signal: Remove task parameter from force_sig Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 10/26] signal: Remove task parameter from force_sig_mceerr Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 11/26] signal/x86: Remove task parameter from send_sigtrap Eric W. Biederman
2019-05-28 18:18   ` Thomas Gleixner
2019-05-23  0:39 ` [REVIEW][PATCH 12/26] signal/um: " Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 13/26] signal/sh: Remove tsk parameter from force_sig_info_fault Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 14/26] signal/riscv: Remove tsk parameter from do_trap Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 15/26] signal/nds32: Remove tsk parameter from send_sigtrap Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 16/26] signal/arm: Remove tsk parameter from ptrace_break Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 17/26] signal/arm: Remove tsk parameter from __do_user_fault Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 18/26] signal/unicore32: " Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 19/26] signal: Explicitly call force_sig_fault on current Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 20/26] signal: Use force_sig_fault_to_task for the two calls that don't deliver to current Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 21/26] signal: Remove the task parameter from force_sig_fault Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 22/26] signal: Properly set TRACE_SIGNAL_LOSE_INFO in __send_signal Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 23/26] signal: Move the computation of force into send_signal and correct it Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 24/26] signal: Generate the siginfo in force_sig Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 25/26] signal: Factor force_sig_info_to_task out of force_sig_info Eric W. Biederman
2019-05-23  0:39 ` [REVIEW][PATCH 26/26] signal: Remove the signal number and task parameters from force_sig_info Eric W. Biederman
2019-05-24 23:35 ` [REVIEW][PATCH 00/26] signal: Remove task argument " Eric W. Biederman
2019-05-29 15:37 ` Eric W. Biederman

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=20190523003916.20726-5-ebiederm@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=drbd-dev@lists.linbit.com \
    --cc=lars.ellenberg@linbit.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=philipp.reisner@linbit.com \
    /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 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).