public inbox for linux-bcache@vger.kernel.org
 help / color / mirror / Atom feed
From: Coly Li <colyli@suse.de>
To: axboe@kernel.dk
Cc: linux-bcache@vger.kernel.org, linux-block@vger.kernel.org,
	hare@suse.de, mhocko@suse.com, mkoutny@suse.com,
	Coly Li <colyli@suse.de>
Subject: [PATCH 2/2] bcache: fix code comments for ignore pending signals
Date: Mon,  2 Mar 2020 17:34:50 +0800	[thread overview]
Message-ID: <20200302093450.48016-3-colyli@suse.de> (raw)
In-Reply-To: <20200302093450.48016-1-colyli@suse.de>

Commit 0b96da639a48 ("bcache: ignore pending signals when creating gc
and allocator thread") explains the ignoring signal is sent from OOM
killer, which was wrong. Michal Koutný, Michal Hocko and Hannes Reinecke
point out the bcache registration process might be killed by udevd other
than the OOM killer during the system boot time due to timeout.

After more diagnose, it turns out the registration process has pending
signal after exuected for 180 seconds. Now I believe the killing signal
is indeed from udevd by the following reasons,
- The signal is only received in system boot time. If register bcache
  device in command line after boot up, no pending signal received.
  the automatic bcache registration in boot up time is performed by
  udev rule only.
- The udevd has a default timeout as 180 seconds, if a rule execution
  is not finished within 180 seconds, it will try to kill the task.
  The timeout is exactly same as the seconds I observe when bcache
  registration process receives signal.

This patch does not change executable code, just changes code comments
for why flush_signals() should be called before creating bcache gc and
allocator kernel thread, to explain things in correct way.

Fixes: 0b96da639a48 ("bcache: ignore pending signals when creating gc and allocator thread")
Signed-off-by: Coly Li <colyli@suse.de>
Cc: Michal Koutný <mkoutny@suse.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
---
 drivers/md/bcache/alloc.c | 14 +++++++-------
 drivers/md/bcache/btree.c | 14 +++++++-------
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/md/bcache/alloc.c b/drivers/md/bcache/alloc.c
index 8bc1faf71ff2..2cb4db87bded 100644
--- a/drivers/md/bcache/alloc.c
+++ b/drivers/md/bcache/alloc.c
@@ -737,13 +737,13 @@ int bch_cache_allocator_start(struct cache *ca)
 	struct task_struct *k;
 
 	/*
-	 * In case previous btree check operation occupies too many
-	 * system memory for bcache btree node cache, and the
-	 * registering process is selected by OOM killer. Here just
-	 * ignore the SIGKILL sent by OOM killer if there is, to
-	 * avoid kthread_run() being failed by pending signals. The
-	 * bcache registering process will exit after the registration
-	 * done.
+	 * In case previous btree check operation takes too long time
+	 * for bcache btree node cache, if the registration process is
+	 * executed from a bcache udev rule and killed by udevd due to
+	 * timeout (default as 180s) in system boot time, here just
+	 * ignore the signal sent by udev if there is, to avoid
+	 * kthread_run() being failed by pending signals. The bcache
+	 * registering process will exit after the registration done.
 	 */
 	if (signal_pending(current))
 		flush_signals(current);
diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c
index b12186c87f52..8c428e318990 100644
--- a/drivers/md/bcache/btree.c
+++ b/drivers/md/bcache/btree.c
@@ -1915,13 +1915,13 @@ static int bch_gc_thread(void *arg)
 int bch_gc_thread_start(struct cache_set *c)
 {
 	/*
-	 * In case previous btree check operation occupies too many
-	 * system memory for bcache btree node cache, and the
-	 * registering process is selected by OOM killer. Here just
-	 * ignore the SIGKILL sent by OOM killer if there is, to
-	 * avoid kthread_run() being failed by pending signals. The
-	 * bcache registering process will exit after the registration
-	 * done.
+	 * In case previous btree check operation takes too long time
+	 * for bcache btree node cache, if the registration process is
+	 * executed from a bcache udev rule and killed by udevd due to
+	 * timeout (default as 180s) in system boot time, here just
+	 * ignore the signal sent by udev if there is, to avoid
+	 * kthread_run() being failed by pending signals. The bcache
+	 * registering process will exit after the registration done.
 	 */
 	if (signal_pending(current))
 		flush_signals(current);
-- 
2.16.4

      parent reply	other threads:[~2020-03-02  9:35 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-02  9:34 [PATCH 0/2] bcache patches for Linux v5.6-rc5 Coly Li
2020-03-02  9:34 ` [PATCH 1/2] bcache: ignore pending signals in bcache_device_init() Coly Li
2020-03-02 12:27   ` Michal Hocko
2020-03-02 13:29     ` Coly Li
2020-03-02 13:40       ` Michal Hocko
2020-03-02 17:06         ` Coly Li
2020-03-02 17:28           ` Michal Hocko
2020-03-02 17:47             ` Coly Li
2020-03-03  1:22               ` Guoqing Jiang
2020-03-03  1:30                 ` Coly Li
2020-03-03  6:58           ` Сорокин Артем Сергеевич
2020-04-13  8:17             ` Coly Li
2020-03-02 13:49     ` Oleg Nesterov
2020-03-02 17:16       ` Coly Li
2020-03-02 17:19         ` Jens Axboe
2020-03-02 17:32           ` Coly Li
2020-03-02 20:33             ` Jens Axboe
2020-03-03  1:08               ` Coly Li
2020-03-03  7:22             ` Hannes Reinecke
2020-03-03  8:05       ` Michal Hocko
2020-03-03 12:19         ` Oleg Nesterov
2020-03-03 16:03           ` Michal Hocko
2020-03-04 11:36             ` Oleg Nesterov
2020-03-04 11:53               ` Oleg Nesterov
2020-03-04 18:42                 ` Jens Axboe
2020-03-04 11:57               ` Michal Hocko
2020-03-04 12:13                 ` Oleg Nesterov
2020-03-04 12:22                   ` Michal Hocko
2020-03-04 12:33                     ` Oleg Nesterov
2020-03-04 12:41                       ` Michal Hocko
2020-03-04 13:02                         ` Oleg Nesterov
2020-03-04 13:21                           ` Michal Hocko
2020-03-02 15:01     ` Jens Axboe
2020-03-02  9:34 ` Coly Li [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=20200302093450.48016-3-colyli@suse.de \
    --to=colyli@suse.de \
    --cc=axboe@kernel.dk \
    --cc=hare@suse.de \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=mkoutny@suse.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