From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) (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 5083F1E5724 for ; Wed, 22 Apr 2026 10:51:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776855080; cv=none; b=VVjvL04SFfi3oYIzo8KlwqcWWw7T0po6tAItXMyw1EieNGAc6+fcA07/UuIgpzS6QWTc2ubhSODlv98Tlbc0fr3C6TyGL8z2bM7NiKWccSZEqf1yvVgVga0ne+GZkAwSVxwXHF0e5RX8L541xdclxoiBfgYJJ/pWPwF4wPaOKMg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776855080; c=relaxed/simple; bh=7HOTuwDeCLZJO7sqFzIrCwQPvn4VX9ZUJ1cQpYQFI5c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Xr9bBSG3ZAA45pHlEeAxVlRPoQ/5QbywpbsehlM2QjzTvgwzqmMQFz0LZHLCPfxsq21oOAP+FkcpaEcP9c10iai4AmyDId1uJELXKA89c/T0ijhaD354oYAP/u2IPfbyXvxQsH7nJ9AgjjQnksM/wHy/tVmrHvbhqBU4i+pwMxs= 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=BfzW7d0l; arc=none smtp.client-ip=209.85.216.48 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="BfzW7d0l" Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-35d971fb6f1so4141537a91.0 for ; Wed, 22 Apr 2026 03:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776855079; x=1777459879; 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=BrfPZZNqJZIU1swqWsCZeR23pBvS4pwR9vbdDEDGcn0=; b=BfzW7d0lgo3li4HKj78p7N+0zMjQY+eE73SR+ietBjF7mEMGglTxjYHINKmm5MqCQ2 l6sIZu3vebB0/1DLrBUNjavYnI09EB7K7tG3e+chQ1mMAqaq98jfVx9NIpi2bhc2KOzM 5cqpTtLcwSKozlCJG1xWh+Os+1H1o3KH/8cWnL5F5eVmxXLYCCCh8ETqGw0O5oMeiEVh 4cK41cHY0e74zZWbFt2mhy2BKxTAm026ZQDgNUjwoNrawWhwPlPeNkHYz/A3tnL4wo6e +lgQLi9HQj1KTkxcmqPSTZMIvMC5Ucu4IjqNcgtM7mrzDhtsytgZmq6VHc1lUuR7f76D /pGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776855079; x=1777459879; 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=BrfPZZNqJZIU1swqWsCZeR23pBvS4pwR9vbdDEDGcn0=; b=mco6EE9Q18rnduXegbt7ByNN/J/x5p5nhlPx/ncAOcvNfPApHba2lS7kfJEV6JAfxo 0FMh0004NCG1YcoFGF+3MBymRCDFVvKw+/BZbXuuxEvEuOPxSuWnHlWF/KdgGIjKr0W4 ebQe53sQrcKdly2ymIGZwcSAn77Zt3U+s2im+o/WMpN0G3qFRVrMeoPl+zkEgh+ojwJf VZqv3+lTpsd6N/HVGB87xIg0Vndu1dqWC9yQymbsBsfebuHsgzrW98J+rw6kjI04tCVg z1/+a3SGDJNzGnaE1U46FzJ52A0HyST+q+myxedcn9UMdk75yV6Ip0446YwK4rcqD5Bk oi4w== X-Forwarded-Encrypted: i=1; AFNElJ8TegmmzOx1LIr5+2VEq9UUZUjD40KY8CS5MznNg6r760MjLceSFUm9HME2RVPEIil1iiNxymeVT02wyOU=@vger.kernel.org X-Gm-Message-State: AOJu0YwbzcaGEUAJ6GnCx141yersA/WI/hx3dA9MllZSOIkUP6ZAQeeM fsZIXAh8yuhCUDPjsEObkhJ2PvbMDxB06QV3bFYRDoa+xwAYzriTopRI X-Gm-Gg: AeBDieuYYVQRHnIt1uay+q+RAdY7ejto5oH7PQ/zu4AYWYwv+IVE4KwNmED9l/h3hH/ RqHGvonReTq/sew+/JPHE7EFWtM0+p601iyxDxSvK1M43jcCSzOw5OTVu2Og5h3ikBOZfDhtmw5 bWNAnZuAH2Y3pNQVx1P1mYci/LJ3niDsaNiIa5/GCM56BgBXjAUh8dl93tFbYlnO8bBng9rr3f9 TlvQr+olFJU31KSywArSaG/U3mZD4BMPo//f5+aeKBLvZuTDUMlVzqOE6j88TnVQ09LigdJoL+b EZy1j8A+eqAS8E0o4ctbUMT9Pg/XRcnV2HJgKuSbupdEpds/t+V0+Eid0osqbQ1W+C6vUeDL6pj zpkVvln0tkgQMQeZ5afrb3ZsRumQv2hOUO9MSPSp0ALEQB6Ks0PKqWjoEM58IXhxjXSrmvysIpz FvRF4qFRR5SfQY6HpFAB21B3T+2nB95MQQhrsVnrk+ZLhMbYUilvl3CeXbGHYcmdxcrG244wjBs HQSH+z3l0uKoMGI X-Received: by 2002:a17:90b:2892:b0:35f:b5df:456 with SMTP id 98e67ed59e1d1-36140463bb0mr22110329a91.18.1776855078447; Wed, 22 Apr 2026 03:51:18 -0700 (PDT) Received: from cchengyang.duckdns.org (36-225-97-241.dynamic-ip.hinet.net. [36.225.97.241]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-36145fe05f4sm7218289a91.0.2026.04.22.03.51.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2026 03:51:18 -0700 (PDT) Date: Wed, 22 Apr 2026 18:51:13 +0800 From: Cheng-Yang Chou To: Richard Cheng Cc: arighi@nvidia.com, mingo@redhat.com, peterz@infradead.org, tj@kernel.org, void@manifault.com, changwoo@igalia.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, sched-ext@lists.linux.dev, linux-kernel@vger.kernel.org, newtonl@nvidia.com, kristinc@nvidia.com, kaihengf@nvidia.com, kobak@nvidia.com, Ching-Chun Huang , Chia-Ping Tsai Subject: Re: [PATCH] sched_ext: sync disable_irq_work in bpf_scx_unreg() Message-ID: <20260422183307.Gf0f8@cchengyang.duckdns.org> References: <20260422100938.35781-1-icheng@nvidia.com> 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: <20260422100938.35781-1-icheng@nvidia.com> Hi Richard, On Wed, Apr 22, 2026 at 06:09:38PM +0800, Richard Cheng wrote: > When unregistered my self-written scx scheduler, the following panic > occurs [1]. Nit: you've placed the panic log [1] below the --- separator. Content below this line will not be preserved in the comment msg. Could you please move it into the commit msg body and send a v2 patch? > > The root cause is that the JIT page backing ops->quiescent() is freed > before all callers of that function have stopped. > > The expected ordering during teardown is: > bitmap_zero(sch->has_op) + synchronize_rcu() > -> guarantees no CPU will ever call sch->ops.* again > -> only THEN free the BPF struct_ops JIT page > > bpf_scx_unreg() is supposed to enforce the order, but after > commit f4a6c506d118 ("sched_ext: Always bounce scx_disable() through > irq_work"), disable_work is no longer queued directly, causing > kthread_flush_work() to be a noop. Thus, the caller drops the struct_ops > map too early and poisoned with AARCH64_BREAK_FAULT before > disable_workfn ever execute. > > So the subsequent dequeue_task() still sees SCX_HAS_OP(sch, quiescent) > as true and calls ops.quiescent, which hit on the poisoned page and BRK > panic. > > Fix it by syncing disable_irq_work first, so disable_work is guaranteed > to be queued before waiting for it. > > Fixes: f4a6c506d118 ("sched_ext: Always bounce scx_disable() through irq_work") > Signed-off-by: Richard Cheng Thanks for the fix, and the logic looks correct to me. Reviewed-by: Cheng-Yang Chou Also, scx_root_enable_workfn() has the same pattern in its error path: scx_error(sch, "scx_root_enable() failed (%d)", ret); kthread_flush_work(&sch->disable_work); The comment above indicates that this flush is meant to "ensure that error is reported before init completion". However, because scx_error() goes through scx_vexit() -> irq_work_queue(), the flush can be a no-op here as well. The same applies to the sub-scheduler enable error path. Should those be fixed in the same patch? Tejun, Andrea, wdyt? Thanks [...] > diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c > index 012ca8bd70fb..065660382a0c 100644 > --- a/kernel/sched/ext.c > +++ b/kernel/sched/ext.c > @@ -7349,6 +7349,12 @@ static void bpf_scx_unreg(void *kdata, struct bpf_link *link) > struct scx_sched *sch = rcu_dereference_protected(ops->priv, true); > > scx_disable(sch, SCX_EXIT_UNREG); > + /* > + * sch->disable_work might still not queued, causing kthread_flush_work() > + * as a noop. Syncing the irq_work first is required to guarantee the Perhaps s/noop/no-op/? Though it's just a matter of taste. ^_^ > + * kthread work has been queued before waiting for it. > + */ > + irq_work_sync(&sch->disable_irq_work); > kthread_flush_work(&sch->disable_work); > RCU_INIT_POINTER(ops->priv, NULL); > kobject_put(&sch->kobj); > -- > 2.43.0 > > -- Cheers, Cheng-Yang