From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 66F36379C33 for ; Wed, 13 May 2026 20:33:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778704430; cv=none; b=hKnbMvU4rY/UERAim6mTLXlmRjOINyX30iZuJmicTVefZmZP70ljSQDSV/01EfzwfJvtgZa96lq0vNpzwV8sCfhjPeRB0zuzr2LHrWx+vF4xQol0woyr576E0c8gdgAT5Oc5FuGgqJZZLb0PhYvX7uiJx6Dsi8YZIxqaJ/2R7JI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778704430; c=relaxed/simple; bh=X7rEYXsps9lolKowVjX6yfvNXC4HUV/AW1S5DZm0CWw=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=aecz0eyBM/8uH/qLTYIvTQvdV9rxjxrOPTO94cHntb5UWDWPcTAfx+2SdyveP0yX59gWHrQIK5tz+Paq8MVgCzsBtofCSVAIYCRZMlwloovbAVE26fNlFpxk75CCH3Q81g5B26kmmXaGb++LW0solWfcxS+D8HJoKY9OFOME/ro= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=HaVik9vd; arc=none smtp.client-ip=198.175.65.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="HaVik9vd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1778704421; x=1810240421; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=X7rEYXsps9lolKowVjX6yfvNXC4HUV/AW1S5DZm0CWw=; b=HaVik9vd5050uzo8wv7tNjMM3riyOw6umXw4iJ5JntEtfmPfPEjtBYDS Br19V4wjBmDP/QENT/8hfHLFaoKwXlH0i734tF8O/2rY47vBvucV7jFNx n9EfRUqxBjE8/NtRQsAnpawPfip4yEFQRpYH4dnmM64d/Cy9X9zAXVmF+ 1I83oCMKeW4/YKpOCIZ5ZgSViEEDmVpj3QdqLBbUhbHgDcV6SFjrSyUyT F+eT71hTuWSANINmNJ2QjBX9sfsQ+c/v6/K//Ew7/k42t8vB2doh1Yy8c UAVn/PFsy5TwUcVIilQjnjGe4UaRyNBRA3HS2bk6/4Pfz6eXSU9LYesat g==; X-CSE-ConnectionGUID: jjElaELlQlqt0Pw5HhF/1Q== X-CSE-MsgGUID: mQrHFYrgRAaLN7SGht0JNQ== X-IronPort-AV: E=McAfee;i="6800,10657,11785"; a="79623127" X-IronPort-AV: E=Sophos;i="6.23,233,1770624000"; d="scan'208";a="79623127" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2026 13:33:41 -0700 X-CSE-ConnectionGUID: bU0/dPyARu6YYe+GqnizOw== X-CSE-MsgGUID: gl0WTuQLQouL4gu8cgT/fg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,233,1770624000"; d="scan'208";a="238076374" Received: from b04f130c83f2.jf.intel.com ([10.165.154.98]) by orviesa008.jf.intel.com with ESMTP; 13 May 2026 13:33:40 -0700 From: Tim Chen To: Peter Zijlstra , Ingo Molnar , K Prateek Nayak , Vincent Guittot Cc: Chen Yu , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Madadi Vineeth Reddy , Hillf Danton , Shrikanth Hegde , Jianyong Wu , Yangyu Chen , Tingyin Duan , Vern Hao , Vern Hao , Len Brown , Tim Chen , Aubrey Li , Zhao Liu , Chen Yu , Adam Li , Aaron Lu , Tim Chen , Josh Don , Gavin Guo , Qais Yousef , Libo Chen , Luo Gengkun , linux-kernel@vger.kernel.org Subject: [Patch v4 08/16] sched/cache: Fix potential NULL mm pointer access Date: Wed, 13 May 2026 13:39:19 -0700 Message-Id: <066d8cfa45d4822bf4367e788c50377c66bbcc82.1778703694.git.tim.c.chen@linux.intel.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Chen Yu A concurrent task exit might cause a NULL pointer dereference in account_mm_sched(). Use the locally cached mm pointer instead, since the active_mm reference guarantees the structure remains allocated. Meanwhile, skip the kernel thread because it has nothing to do with cache aware scheduling. This bug was reported by sashiko and Vern. Fixes: df0d98475954 ("sched/cache: Introduce infrastructure for cache-aware load balancing") Reported-by: Vern Hao Signed-off-by: Chen Yu Co-developed-by: Tim Chen Signed-off-by: Tim Chen Link: https://lore.kernel.org/all/09cf7ee3-6e27-4505-9692-4b4a4707c8b2@gmail.com/ --- kernel/sched/fair.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index be96d80c9310..913b09254732 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1649,7 +1649,7 @@ void account_mm_sched(struct rq *rq, struct task_struct *p, s64 delta_exec) if (!mm || !mm->sc_stat.pcpu_sched) return; - pcpu_sched = per_cpu_ptr(p->mm->sc_stat.pcpu_sched, cpu_of(rq)); + pcpu_sched = per_cpu_ptr(mm->sc_stat.pcpu_sched, cpu_of(rq)); scoped_guard (raw_spinlock, &rq->cpu_epoch_lock) { __update_mm_sched(rq, pcpu_sched); @@ -1689,7 +1689,8 @@ static void task_tick_cache(struct rq *rq, struct task_struct *p) if (!sched_cache_enabled()) return; - if (!mm || !mm->sc_stat.pcpu_sched) + if (!mm || p->flags & PF_KTHREAD || + !mm->sc_stat.pcpu_sched) return; epoch = rq->cpu_epoch; -- 2.32.0