Received: by 2002:a05:6358:e9c4:b0:b2:91dc:71ab with SMTP id hc4csp4261268rwb; Sun, 7 Aug 2022 19:40:10 -0700 (PDT) X-Google-Smtp-Source: AA6agR7SWx1fDxxLRCKNNOVyTZaWsc1pNA6wwwmeG4N4wk4XRVb2UVVUbwpDLJNMU4dQ0G1vXv64 X-Received: by 2002:a05:6402:287:b0:43c:c604:addb with SMTP id l7-20020a056402028700b0043cc604addbmr16358512edv.201.1659926410424; Sun, 07 Aug 2022 19:40:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1659926410; cv=none; d=google.com; s=arc-20160816; b=yJ5RrkkfOANF+j3fqGnpPQfdAWONJjq1UDjOJxg6peEpevXBj4noqjoFODk/a9B5oL mYhh6mPZV66z55+cyvzvDOtWEeLaAa4gaUmRYLCW6GrywR/P0gC5MpciTNJVVFbA8auv g0mK5AaE7+nvc1YysKxY3izU+JVdrq6h5W3ETbAlSeDfl8oEuFfXeR3a1jjyMQXtURhj +ghMHJGwcHYyYC/RZ2Z0a19WENxQjqjy9ukNGqj9ueoD7i96E2yJhq0joa2LsGo45aau LM4zDol4gwkkmRpHWAIcDQWJOCoze2W+muhYhC0ZXFJuxVWjo1xF/iOTkOXMARdhkotW iDfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=DN7BOThAC7xnDKYEm/2cyY9mc61H0km13uPHeOkSnf8=; b=uZOm+lAnxnxR4VkrW5jBN2Jt00aifdJEARQsPRbjCmIi77OKxZ23aV8NTe5U9xUzW3 wPrvhHf+h5IAo+Axyn5I+QfWuSjnn4f2JZ6nW5HBwoG5/a8/D9DG6gSMcG++IqyDtp47 8qUxIxDlsbVCi3U6JhRJCyyQR6AT6eABlZwETbUew8pE39C3tB/Wu7MrKAR/Y8LsKoEX k477ZNIjJBrDwWLWa1CJpDabxqFZoFMfhz1kAtttbWnWOSMe2UYCml8mETowTDyU+PAp yDnvbafUYl2/FuJKJR4VT6sXj9Z/ykTm5Cq8tRl1BICFkHKz9m0J2aSu5uoApaouibtk RSbQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qq4wLRT5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w16-20020a056402269000b0043c0af44278si5726665edd.10.2022.08.07.19.39.45; Sun, 07 Aug 2022 19:40:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qq4wLRT5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242259AbiHHBeO (ORCPT + 99 others); Sun, 7 Aug 2022 21:34:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57536 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242183AbiHHBdR (ORCPT ); Sun, 7 Aug 2022 21:33:17 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8988ABF41; Sun, 7 Aug 2022 18:32:38 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id EE65460DDF; Mon, 8 Aug 2022 01:32:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A2F2C433D6; Mon, 8 Aug 2022 01:32:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659922357; bh=y683IYnjz5gSz366uPqUz0S4nqhMMgjNKCG7wfZFxno=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qq4wLRT5nYcJp9cYJX9hp1AM+MYpkWA4mKNif/9Ni/jgajcPSNDC5iwb4/Lg8dsa5 igJavMUSX1FNZdYt4L9CRgqLOFjrCmUkXrVro37UKkktvv9pLquUiEO+20VdsLX0FT n7VadwYVhxGtRyFYODzZDgxJh/D2tva8XfCyxz7MA43ZtYozDwp067JxxdpwbR9G7y fA45CSTeQciHs2ZmRPAlzrDKvJPnuddWIc1CFsV79F0gGyYvTZ6wQG45VX2PeZz3o5 UcYBDy4aStY1WxAu4ca7rD/8FnsIwX9QoZkGssH/HUtUYvzTw400OMYOTsyIAe8Gwq KSCPdT8maCQEA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: John Keeping , Peter Zijlstra , Steven Rostedt , Sasha Levin , mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org Subject: [PATCH AUTOSEL 5.19 21/58] sched/core: Always flush pending blk_plug Date: Sun, 7 Aug 2022 21:30:39 -0400 Message-Id: <20220808013118.313965-21-sashal@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220808013118.313965-1-sashal@kernel.org> References: <20220808013118.313965-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: John Keeping [ Upstream commit 401e4963bf45c800e3e9ea0d3a0289d738005fd4 ] With CONFIG_PREEMPT_RT, it is possible to hit a deadlock between two normal priority tasks (SCHED_OTHER, nice level zero): INFO: task kworker/u8:0:8 blocked for more than 491 seconds. Not tainted 5.15.49-rt46 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:0 state:D stack: 0 pid: 8 ppid: 2 flags:0x00000000 Workqueue: writeback wb_workfn (flush-7:0) [] (__schedule) from [] (schedule+0xdc/0x134) [] (schedule) from [] (rt_mutex_slowlock_block.constprop.0+0xb8/0x174) [] (rt_mutex_slowlock_block.constprop.0) from [] +(rt_mutex_slowlock.constprop.0+0xac/0x174) [] (rt_mutex_slowlock.constprop.0) from [] (fat_write_inode+0x34/0x54) [] (fat_write_inode) from [] (__writeback_single_inode+0x354/0x3ec) [] (__writeback_single_inode) from [] (writeback_sb_inodes+0x250/0x45c) [] (writeback_sb_inodes) from [] (__writeback_inodes_wb+0x7c/0xb8) [] (__writeback_inodes_wb) from [] (wb_writeback+0x2c8/0x2e4) [] (wb_writeback) from [] (wb_workfn+0x1a4/0x3e4) [] (wb_workfn) from [] (process_one_work+0x1fc/0x32c) [] (process_one_work) from [] (worker_thread+0x22c/0x2d8) [] (worker_thread) from [] (kthread+0x16c/0x178) [] (kthread) from [] (ret_from_fork+0x14/0x38) Exception stack(0xc10e3fb0 to 0xc10e3ff8) 3fa0: 00000000 00000000 00000000 00000000 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 INFO: task tar:2083 blocked for more than 491 seconds. Not tainted 5.15.49-rt46 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:tar state:D stack: 0 pid: 2083 ppid: 2082 flags:0x00000000 [] (__schedule) from [] (schedule+0xdc/0x134) [] (schedule) from [] (io_schedule+0x14/0x24) [] (io_schedule) from [] (bit_wait_io+0xc/0x30) [] (bit_wait_io) from [] (__wait_on_bit_lock+0x54/0xa8) [] (__wait_on_bit_lock) from [] (out_of_line_wait_on_bit_lock+0x84/0xb0) [] (out_of_line_wait_on_bit_lock) from [] (fat_mirror_bhs+0xa0/0x144) [] (fat_mirror_bhs) from [] (fat_alloc_clusters+0x138/0x2a4) [] (fat_alloc_clusters) from [] (fat_alloc_new_dir+0x34/0x250) [] (fat_alloc_new_dir) from [] (vfat_mkdir+0x58/0x148) [] (vfat_mkdir) from [] (vfs_mkdir+0x68/0x98) [] (vfs_mkdir) from [] (do_mkdirat+0xb0/0xec) [] (do_mkdirat) from [] (ret_fast_syscall+0x0/0x1c) Exception stack(0xc2e1bfa8 to 0xc2e1bff0) bfa0: 01ee42f0 01ee4208 01ee42f0 000041ed 00000000 00004000 bfc0: 01ee42f0 01ee4208 00000000 00000027 01ee4302 00000004 000dcb00 01ee4190 bfe0: 000dc368 bed11924 0006d4b0 b6ebddfc Here the kworker is waiting on msdos_sb_info::s_lock which is held by tar which is in turn waiting for a buffer which is locked waiting to be flushed, but this operation is plugged in the kworker. The lock is a normal struct mutex, so tsk_is_pi_blocked() will always return false on !RT and thus the behaviour changes for RT. It seems that the intent here is to skip blk_flush_plug() in the case where a non-preemptible lock (such as a spinlock) has been converted to a rtmutex on RT, which is the case covered by the SM_RTLOCK_WAIT schedule flag. But sched_submit_work() is only called from schedule() which is never called in this scenario, so the check can simply be deleted. Looking at the history of the -rt patchset, in fact this change was present from v5.9.1-rt20 until being dropped in v5.13-rt1 as it was part of a larger patch [1] most of which was replaced by commit b4bfa3fcfe3b ("sched/core: Rework the __schedule() preempt argument"). As described in [1]: The schedule process must distinguish between blocking on a regular sleeping lock (rwsem and mutex) and a RT-only sleeping lock (spinlock and rwlock): - rwsem and mutex must flush block requests (blk_schedule_flush_plug()) even if blocked on a lock. This can not deadlock because this also happens for non-RT. There should be a warning if the scheduling point is within a RCU read section. - spinlock and rwlock must not flush block requests. This will deadlock if the callback attempts to acquire a lock which is already acquired. Similarly to being preempted, there should be no warning if the scheduling point is within a RCU read section. and with the tsk_is_pi_blocked() in the scheduler path, we hit the first issue. [1] https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/0022-locking-rtmutex-Use-custom-scheduling-function-for-s.patch?h=linux-5.10.y-rt-patches Signed-off-by: John Keeping Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Steven Rostedt (Google) Link: https://lkml.kernel.org/r/20220708162702.1758865-1-john@metanate.com Signed-off-by: Sasha Levin --- include/linux/sched/rt.h | 8 -------- kernel/sched/core.c | 8 ++++++-- 2 files changed, 6 insertions(+), 10 deletions(-) diff --git a/include/linux/sched/rt.h b/include/linux/sched/rt.h index e5af028c08b4..994c25640e15 100644 --- a/include/linux/sched/rt.h +++ b/include/linux/sched/rt.h @@ -39,20 +39,12 @@ static inline struct task_struct *rt_mutex_get_top_task(struct task_struct *p) } extern void rt_mutex_setprio(struct task_struct *p, struct task_struct *pi_task); extern void rt_mutex_adjust_pi(struct task_struct *p); -static inline bool tsk_is_pi_blocked(struct task_struct *tsk) -{ - return tsk->pi_blocked_on != NULL; -} #else static inline struct task_struct *rt_mutex_get_top_task(struct task_struct *task) { return NULL; } # define rt_mutex_adjust_pi(p) do { } while (0) -static inline bool tsk_is_pi_blocked(struct task_struct *tsk) -{ - return false; -} #endif extern void normalize_rt_tasks(void); diff --git a/kernel/sched/core.c b/kernel/sched/core.c index da0bf6fe9ecd..410b04decb90 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6500,8 +6500,12 @@ static inline void sched_submit_work(struct task_struct *tsk) io_wq_worker_sleeping(tsk); } - if (tsk_is_pi_blocked(tsk)) - return; + /* + * spinlock and rwlock must not flush block requests. This will + * deadlock if the callback attempts to acquire a lock which is + * already acquired. + */ + SCHED_WARN_ON(current->__state & TASK_RTLOCK_WAIT); /* * If we are going to sleep and we have plugged IO queued, -- 2.35.1