From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f73.google.com (mail-ed1-f73.google.com [209.85.208.73]) (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 3579F3ACF1F for ; Wed, 4 Feb 2026 09:51:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770198664; cv=none; b=PdCc1HtUkc315PijsT2CuKgvD8zisc/HxivQgKX96Xi3sHVBETA37JQ9/+6ZeMQ1gsnnfKUoLUKL1mj6pijeIT2V72C2btNz/2LqnswrRBNJ6orldGonfKG5/s71FwSQJy2v9sX1FWnkBcIMMGuhZykIaqpFdjB1yHaQB3jJVBA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770198664; c=relaxed/simple; bh=vLvss+Df18mwcv3kvmTDuXXVfLHpH42VLJXIFjNzRQ8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ic8BWVP9zuzMStLlTl8t/vyHv/BPNln3fADnpSRzNCBDbWtnEKcp08bRHeuX+F3j9/DGEnGtvr8jFBk2wUlPIcoEMp4z+/nUtmvQabg/aWzXMDLIzOdu0Bd8MeE+xHstGfTb+a8DNsX0PSDf/uhmPTk6I98iV+7v9CI/rLvZnAA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jpiecuch.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=w/8bszDF; arc=none smtp.client-ip=209.85.208.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jpiecuch.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="w/8bszDF" Received: by mail-ed1-f73.google.com with SMTP id 4fb4d7f45d1cf-64d1a0f7206so5630580a12.0 for ; Wed, 04 Feb 2026 01:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770198662; x=1770803462; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=70cmIgnUVUOGlf8++R56za90YLRrQn92YMbZ46tqNGY=; b=w/8bszDFd26zcbxCTX+LYz7XtxNAQc5Yfz84/nUKo5j59iCuIxFgTWMtu1BTSVgfHQ QX3WhnHqqnyW+5Inb4DqCQAZKTk4eV4YTXc2ui6octRMqUQYIkVdhgX/q1m1V1dmuBeY 8XQZmAaCv4yD1hQf6sE79IPEHk2xrtWFzP0sKuNfgT8Ctrq2sdhW8Ox8sedM0guAweld Fga9i08VA79cGdCrAwnbAcI7/0SWhamfoxglTc2OKWhmQSEzPPLWm7emL0rkDZBB6K/5 5/J4UwCsh1Z05Ivw3t6IAptAaYHNMkKFr3hGtdLzSiZibb7stlNEcfkAULkNtXnCqiw7 Ea9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770198662; x=1770803462; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=70cmIgnUVUOGlf8++R56za90YLRrQn92YMbZ46tqNGY=; b=Y1WHtpfPc0O8rBjHGz9XAZKV1VipBvoQu72SgtU2WyU5s0aPnqL+vcuJMpDEyCQoJk O5/VStBpG6mMZ5/PKBFoMG7OnwnhgsbPtmh5qQp7dze+i94ErRdoGnRMcLMurv5dgQGp ZpsRFHHzJ3OIiKibgFWY4hhN1LGP8kzq/Whx+iuS5bNEyC5iu9iZbXfYW7qPn34Nb/7K 2EVBke1LN1gWNq25erhccvLMQ3P6aEsHgYArJegbv9isOtfOG6J8WtBPfvWE2VbYoh5D Y9NoeQ2MuUGE1Q0lAlzhiV9DRuMt+HM8XIsYNZfYo5yURUeKs871xeEl/D00d7Gdygfl QU8w== X-Forwarded-Encrypted: i=1; AJvYcCWXbF3MVe7m3QbugjXQfZf7Mgga3VKTgpl6qVjKjZOKbOUx3YbOPuDo125hkFD/uzVP5BMewWfCObsZakA=@vger.kernel.org X-Gm-Message-State: AOJu0YyONN3e2TUxPvcsvzOtC/0wslpdM6eRe89Br37n588rSjH19Spf HxhPUl+F0q+kwpRLtZYYsA3QA5KfsbaxGArOd2Yr3ktIqrfdqNImlc2W6Rwdq/2hivM0byIRl7m ERh0QLucrgYYnPQ== X-Received: from edgi8-n2.prod.google.com ([2002:a05:6402:a588:20b0:659:444a:bd52]) (user=jpiecuch job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6402:5c8:b0:658:e713:2126 with SMTP id 4fb4d7f45d1cf-65949fdc209mr1438233a12.34.1770198662490; Wed, 04 Feb 2026 01:51:02 -0800 (PST) Date: Wed, 04 Feb 2026 09:51:02 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260201091318.178710-1-arighi@nvidia.com> <20260201091318.178710-2-arighi@nvidia.com> X-Mailer: aerc 0.21.0-0-g5549850facc2 Message-ID: Subject: Re: [PATCH 1/2] sched_ext: Fix ops.dequeue() semantics From: Kuba Piecuch To: Andrea Righi , Kuba Piecuch Cc: Christian Loehle , Tejun Heo , David Vernet , Changwoo Min , Emil Tsalapatis , Daniel Hodges , , Content-Type: text/plain; charset="UTF-8" On Wed Feb 4, 2026 at 9:36 AM UTC, Andrea Righi wrote: > diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c > index 292adf10fee1b..b189339e74101 100644 > --- a/kernel/sched/ext.c > +++ b/kernel/sched/ext.c > @@ -2260,6 +2260,15 @@ static void finish_dispatch(struct scx_sched *sch, struct rq *rq, > if (!is_terminal_dsq(dsq_id)) { > p->scx.flags |= SCX_TASK_OPS_ENQUEUED; > } else { > + /* > + * Locking: we're holding the @rq lock (the > + * dispatch CPU's rq), but not necessarily > + * task_rq(p), since @p may be from a remote CPU. > + * > + * This is safe because SCX_OPSS_DISPATCHING state > + * prevents racing dequeues, any concurrent > + * ops_dequeue() will wait for this state to clear. > + */ > if (p->scx.flags & SCX_TASK_OPS_ENQUEUED) > SCX_CALL_OP_TASK(sch, SCX_KF_REST, dequeue, rq, p, 0); Looks good, thanks :)