From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7154920E4 for ; Tue, 3 Jan 2023 08:17:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4A73C433D2; Tue, 3 Jan 2023 08:17:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1672733833; bh=MpwhqiXhOk4c5z7KQwtyBu+QDEjT5mowJjvKFfLHYHU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SWTaQefA2gH/3gsQ9a8CzkYa7m7dMWA/9INiAvpwIov71FKn86jye649LEu+jQV0g IMEdSHlA2qhVMivmoC318PpvlAGg+GVa/i0vqDvT8tshxV/GmFcOmFbvtPAZ1LlmQk zo5QnkT8kkQQjzr0QaYZH0nT47V0TKnUuGujTbLA= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Song Liu , John Stultz , Douglas Anderson , Jens Axboe , Sedat Dilek Subject: [PATCH 5.10 57/63] task_work: unconditionally run task_work from get_signal() Date: Tue, 3 Jan 2023 09:14:27 +0100 Message-Id: <20230103081312.034796892@linuxfoundation.org> X-Mailer: git-send-email 2.39.0 In-Reply-To: <20230103081308.548338576@linuxfoundation.org> References: <20230103081308.548338576@linuxfoundation.org> User-Agent: quilt/0.67 Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Jens Axboe [ Upstream commit 35d0b389f3b23439ad15b610d6e43fc72fc75779 ] Song reported a boot regression in a kvm image with 5.11-rc, and bisected it down to the below patch. Debugging this issue, turns out that the boot stalled when a task is waiting on a pipe being released. As we no longer run task_work from get_signal() unless it's queued with TWA_SIGNAL, the task goes idle without running the task_work. This prevents ->release() from being called on the pipe, which another boot task is waiting on. For now, re-instate the unconditional task_work run from get_signal(). For 5.12, we'll collapse TWA_RESUME and TWA_SIGNAL, as it no longer makes sense to have a distinction between the two. This will turn task_work notification into a simple boolean, whether to notify or not. Fixes: 98b89b649fce ("signal: kill JOBCTL_TASK_WORK") Reported-by: Song Liu Tested-by: John Stultz Tested-by: Douglas Anderson Tested-by: Sedat Dilek # LLVM/Clang version 11.0.1 Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- kernel/signal.c | 3 +++ 1 file changed, 3 insertions(+) --- a/kernel/signal.c +++ b/kernel/signal.c @@ -2520,6 +2520,9 @@ bool get_signal(struct ksignal *ksig) struct signal_struct *signal = current->signal; int signr; + if (unlikely(current->task_works)) + task_work_run(); + /* * For non-generic architectures, check for TIF_NOTIFY_SIGNAL so * that the arch handlers don't all have to do it. If we get here