From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 70437346A01 for ; Fri, 6 Mar 2026 09:41:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772790078; cv=none; b=HtSST6tctCjbND0q3Ij4j2OwXaKatdwHuBHNdQuetIj8KTA0Ji9cmFLWSpwJshU5xhSJabOuRcKR+q65uCMFwLu3qnW1HhulWD2Ze2yOtfle9YNmwbZ9rddDbzsisWx5WYdsinVzT9tXMU7SZdFD1Slucb8a9NvrPNmHsTkCaTw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772790078; c=relaxed/simple; bh=7q/qr3EasxGpK0KBXmkQggZVdN3yLD8iMA4rtNNF5qw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=osxp9hHdqZtwhGx73WKVXiHOFbf/0t/h/Nt8v+Ljc+2KezHCYCNw65zar8qJW1rFiO/gCE8Bq0kV56q2Gd9JrS2Fm3aQCh/NrbGQ5FskFOcPnsUfSiv/MVzfpB7hDQdkGGwQN2bcCojUdMvI91lMfxvfMzrfW0l31P7at2q4I50= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=h4u/9Jgx; arc=none smtp.client-ip=209.85.210.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="h4u/9Jgx" Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-829a27414a3so273694b3a.3 for ; Fri, 06 Mar 2026 01:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772790077; x=1773394877; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=H39b8OwxchQec01wzUpNEADaw8FiFONIgFr8aWEhBS0=; b=h4u/9JgxCZXeuMrBOmDvWmvwqqL6HsxB/GLTcd97N+NY7ty+jfPzAgErP0NYb4TvCS /xXYSlxEj7TY1+Mon/+Z0pgXZvlYQkp716U4LeXovKjku9tvQGvOAjI6DdVUGbQhRXYN K9Yhh1i3XulDvl3vGvtID0nlqSaQIzqQQYZwCsP1I4vz6jDsfeMN5AYcv4Ng6I+bSpsU kS+czfMXw9Nd1zwwHHySGcVXvt+PM0V95COUva5T9Iuu734C6rTwaWqwGNxlIvU5PNOc spDfSTIeORtlfShOeRzuh+O6Xe1JeI53GmvWSS/5iDQnUvkgd8wbPWqjpXN8XFp1ZIdn Qhzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772790077; x=1773394877; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=H39b8OwxchQec01wzUpNEADaw8FiFONIgFr8aWEhBS0=; b=UtM2ot/HJBv+EcZzvlO857ByWV6sfl/Zx7kk+gAlsUjI0EhpbMJUi630k2N8Eyvy6o W1wm3OzwmmBTAhgjdmMK2OH5Q3cOgWXU/FRpES9C3d+rH5w0N5mHCyrUcP5F2li4rHNn F51wSXvXS34d3X5t9JcCDrZx2LxT3+XQzkbYBDNXmPnW915kyojnkeCmNRxGjoP5oPHD V8oCqn8Cz5ZxDtT/Zt2mYvGtiL53EhqLtu2+2f5VrRtb+EvlQmI9+V54uV8Wzim/GkfP AMuYIJDXlhpZGMktn05C+yx1E+KADUC0Jcx+Z47i34u0QPMlyWG07SiijX9a6/MARZ2a qBeQ== X-Gm-Message-State: AOJu0YxttbWnl2ECsY9vbrbP6DMvm7w09GGbpfTrlrr8ayRW98xa8sNB TiXLjonjljeGnOoNlWpUQ40RZQ2/azARYfAaFxmHIyM69n5m6ZRF9ENX X-Gm-Gg: ATEYQzxHTDv7ug2r7DpoqhN1jSdV+lCR4josQ5AO8i57OsEMHi5CtI8AwR7a7UsrNs7 1Yo7Z5c5c9pWypluYs5GrCC/p02SyLnVLxXoPMq57f9eo8L8TMUWHhPj96COO2NR7Fxxjh3pPeu zeCDUSVyL4P/MSMg40uDeM+lW3kUVYFOn2ehiN7gXA0UjhiMOPeBo/dmw9djOA+0sAhnj/gB24E VaiTHd4O1otxkZPyIkiwPLLsBNivW/SlDe4oiXOqoShGIFbQAyf+AGoHqMgyO/CRl7FbfE7Aake ml40aSNhOM7EP6BjHa34xsoYk+7kSyDdgfmK6rzpllFRVt8esgowLtpXB+/Og1NrXaWv9pkWZQd W+mODIXmlQspYvtqeW45QeUKEiLv4g1uspD2PTR/gA6Hgx/qN9NKRNBUiPBLpAEcgKLi++6ynAJ gZOuVYoZBAXD5RAzhfS12bsq2G2uTBk7YWSMuR/14= X-Received: by 2002:a05:6a00:99b:b0:823:12cb:f5d1 with SMTP id d2e1a72fcca58-829a2d94f37mr1557363b3a.6.1772790076580; Fri, 06 Mar 2026 01:41:16 -0800 (PST) Received: from eric-wcnlab ([2001:288:7001:1099:d8b4:9a91:beb0:3001]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-829a48a54cesm1238731b3a.48.2026.03.06.01.41.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 06 Mar 2026 01:41:16 -0800 (PST) Date: Fri, 6 Mar 2026 17:41:08 +0800 From: Cheng-Yang Chou To: Tejun Heo Cc: linux-kernel@vger.kernel.org, sched-ext@lists.linux.dev, void@manifault.com, arighi@nvidia.com, changwoo@igalia.com, emil@etsalapatis.com, jserv@ccns.ncku.edu.tw Subject: Re: [PATCH 29/34] sched_ext: Implement cgroup sub-sched enabling and disabling Message-ID: References: <20260304220119.4095551-1-tj@kernel.org> <20260304220119.4095551-30-tj@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260304220119.4095551-30-tj@kernel.org> Hi Tejun, I've been reading through this patch and I think I may have spotted a lock leak in the abort: error path of scx_sub_enable_workfn(), but I'm not fully familiar with this code so please correct me if I'm wrong. percpu_down_write(&scx_fork_rwsem) and scx_cgroup_lock() are acquired before the first task iteration loop: percpu_down_write(&scx_fork_rwsem); scx_cgroup_lock(); On Wed, Mar 04, 2026 at 12:01:14PM -1000, Tejun Heo wrote: > +abort: > + put_task_struct(p); > + scx_task_iter_stop(&sti); > + scx_enabling_sub_sched = NULL; > + > + scx_task_iter_start(&sti, sch->cgrp); > + while ((p = scx_task_iter_next_locked(&sti))) { > + if (p->scx.flags & SCX_TASK_SUB_INIT) { > + __scx_disable_and_exit_task(sch, p); > + p->scx.flags &= ~SCX_TASK_SUB_INIT; > + } > + } > + scx_task_iter_stop(&sti); /* scx_cgroup_unlock() and percpu_up_write() seem missing here? */ > out_put_cgrp: > cgroup_put(cgrp); > out_unlock: > abort: can be reached when assert_task_ready_or_enabled() fails or __scx_init_task() returns an error during the init loop. If I'm reading this correctly, leaving those locks unreleased would deadlock the next caller of scx_fork_rwsem or scx_cgroup_lock() (e.g. any fork or future scheduler load attempt). Would the fix be to add before out_put_cgrp: : diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c index fd6e2173cefe..25d16d0f45d0 100644 --- a/kernel/sched/ext.c +++ b/kernel/sched/ext.c @@ -6389,6 +6389,8 @@ static void scx_sub_enable_workfn(struct kthread_work *work) } } scx_task_iter_stop(&sti); + scx_cgroup_unlock(); + percpu_up_write(&scx_fork_rwsem); out_put_cgrp: cgroup_put(cgrp); out_unlock: mirroring what err_unlock_and_disable: already does? Or am I missing something that handles this on the abort path? -- Thanks, Cheng-Yang