Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2171250imm; Mon, 28 May 2018 03:09:29 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrRcxah5tZFGP/V0qJJTmyvX/WNjIrmRgUtEz9Eka7CXwV1xPHiOxLm0cO3pImkmy6Ko6iD X-Received: by 2002:a17:902:b60a:: with SMTP id b10-v6mr12733521pls.221.1527502168983; Mon, 28 May 2018 03:09:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527502168; cv=none; d=google.com; s=arc-20160816; b=VDeZ1Kz5khwkmqjETo75GyhsoSwPVU+k4M4z3ewDWVP1bKJo7+DiP24Au6iC95JlK1 AqLCjGFsnzDGRKg8tFkWNfc6x22lzBmojak+GAa7zT0R+neapqzVk/VPZUSUI5tPORjE WMgSMRMoN1cmeF5w7wwm0iZnFqEXaC97mnQlMRxKce/G8bdjFa/VF5elidS5RIFLxh06 s3CdPUCPlDiDEz1LJqzMOU14amsprS37k/FrM2Q4WaBzQimGdMj7/HA+QQ9MYbsIIoRL jGO3StNKEXF2GPtOqks0q+lNVF0GP6YDAb5YyzO5rgVJ657WNM2BXwNwq4Zj9i7vJcPg 4kRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from:dkim-signature :arc-authentication-results; bh=TWz3tACLBqleu84JYLfTKXHXYYD1XoHm8g3+IR91ok0=; b=cl+ttn4+bhNnwz0xJXxAVSy7/2RUTvU3O+GQxbaEC5U8OrGSfni8HZE2dNrqXhkoFY SeHZiPSEaR7bvTHZfD4zIKOgtk/sZ3U/mj+9kmdF4uW3RcqDQF+Ncblc3ySmZFoKwcwH PdCiKKy9Lr+OKpfz8ZySr0jsSR5mvIlVmQ6J0m9cQ/AVStg8YBWzdgW9gs7AKtONZ/wd cgebm5WnFQStzcdxOG+rnG1JTSRI8BDuFAbvpxhhhdMiKHqcYvHx3vc7wPu1TuhcqLxN MPf7FyR4VqqQjTSLNSa6ZkHPDfLbyPFXPAULR8A0hwatNbnQmTSsmnf+1OomuJJHhvwh E34A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=h4UD6Ge0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 6-v6si7954061pgf.378.2018.05.28.03.09.14; Mon, 28 May 2018 03:09:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=h4UD6Ge0; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934984AbeE1KIx (ORCPT + 99 others); Mon, 28 May 2018 06:08:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:56856 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934203AbeE1KIq (ORCPT ); Mon, 28 May 2018 06:08:46 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 87DE7206B7; Mon, 28 May 2018 10:08:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1527502126; bh=nhosXQsFeyRQwtQerMO+fMjf8M6alTib9abhhIerpp4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=h4UD6Ge0LGGPjanbHXNi0qTaB+MUeJxJxLs/UoGux0osNm4VOSyWZxSgwGr8dZY2t Uwnls+agM3aE8HdzhHi3gzmzH5HsMSzEsJskL6HoPhxTplyDrTPzWEvt0hg/rbh2DB JLX6xiDw2VDZqHBzDuzorPU9I2Nl4ydvoy1PWYDE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Coly Li , Hannes Reinecke , Michael Lyle , Junhui Tang , Jens Axboe , Sasha Levin Subject: [PATCH 3.18 041/185] bcache: properly set task state in bch_writeback_thread() Date: Mon, 28 May 2018 12:01:22 +0200 Message-Id: <20180528100054.276713317@linuxfoundation.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180528100050.700971285@linuxfoundation.org> References: <20180528100050.700971285@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.18-stable review patch. If anyone has any objections, please let me know. ------------------ From: Coly Li [ Upstream commit 99361bbf26337186f02561109c17a4c4b1a7536a ] Kernel thread routine bch_writeback_thread() has the following code block, 447 down_write(&dc->writeback_lock); 448~450 if (check conditions) { 451 up_write(&dc->writeback_lock); 452 set_current_state(TASK_INTERRUPTIBLE); 453 454 if (kthread_should_stop()) 455 return 0; 456 457 schedule(); 458 continue; 459 } If condition check is true, its task state is set to TASK_INTERRUPTIBLE and call schedule() to wait for others to wake up it. There are 2 issues in current code, 1, Task state is set to TASK_INTERRUPTIBLE after the condition checks, if another process changes the condition and call wake_up_process(dc-> writeback_thread), then at line 452 task state is set back to TASK_INTERRUPTIBLE, the writeback kernel thread will lose a chance to be waken up. 2, At line 454 if kthread_should_stop() is true, writeback kernel thread will return to kernel/kthread.c:kthread() with TASK_INTERRUPTIBLE and call do_exit(). It is not good to enter do_exit() with task state TASK_INTERRUPTIBLE, in following code path might_sleep() is called and a warning message is reported by __might_sleep(): "WARNING: do not call blocking ops when !TASK_RUNNING; state=1 set at [xxxx]". For the first issue, task state should be set before condition checks. Ineed because dc->writeback_lock is required when modifying all the conditions, calling set_current_state() inside code block where dc-> writeback_lock is hold is safe. But this is quite implicit, so I still move set_current_state() before all the condition checks. For the second issue, frankley speaking it does not hurt when kernel thread exits with TASK_INTERRUPTIBLE state, but this warning message scares users, makes them feel there might be something risky with bcache and hurt their data. Setting task state to TASK_RUNNING before returning fixes this problem. In alloc.c:allocator_wait(), there is also a similar issue, and is also fixed in this patch. Changelog: v3: merge two similar fixes into one patch v2: fix the race issue in v1 patch. v1: initial buggy fix. Signed-off-by: Coly Li Reviewed-by: Hannes Reinecke Reviewed-by: Michael Lyle Cc: Michael Lyle Cc: Junhui Tang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- drivers/md/bcache/alloc.c | 4 +++- drivers/md/bcache/writeback.c | 7 +++++-- 2 files changed, 8 insertions(+), 3 deletions(-) --- a/drivers/md/bcache/alloc.c +++ b/drivers/md/bcache/alloc.c @@ -285,8 +285,10 @@ do { \ break; \ \ mutex_unlock(&(ca)->set->bucket_lock); \ - if (kthread_should_stop()) \ + if (kthread_should_stop()) { \ + set_current_state(TASK_RUNNING); \ return 0; \ + } \ \ try_to_freeze(); \ schedule(); \ --- a/drivers/md/bcache/writeback.c +++ b/drivers/md/bcache/writeback.c @@ -425,19 +425,22 @@ static int bch_writeback_thread(void *ar while (!kthread_should_stop()) { down_write(&dc->writeback_lock); + set_current_state(TASK_INTERRUPTIBLE); if (!atomic_read(&dc->has_dirty) || (!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) && !dc->writeback_running)) { up_write(&dc->writeback_lock); - set_current_state(TASK_INTERRUPTIBLE); - if (kthread_should_stop()) + if (kthread_should_stop()) { + set_current_state(TASK_RUNNING); return 0; + } try_to_freeze(); schedule(); continue; } + set_current_state(TASK_RUNNING); searched_full_index = refill_dirty(dc);