[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250703115504.GU1613200@noisy.programming.kicks-ass.net>
Date: Thu, 3 Jul 2025 13:55:04 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Michal Hocko <mhocko@...e.com>
Cc: "Chen, Yu C" <yu.c.chen@...el.com>, Ingo Molnar <mingo@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Valentin Schneider <vschneid@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Tim Chen <tim.c.chen@...el.com>, linux-kernel@...r.kernel.org,
Jirka Hladky <jhladky@...hat.com>,
Srikanth Aithal <Srikanth.Aithal@....com>,
Suneeth D <Suneeth.D@....com>, Libo Chen <libo.chen@...cle.com>
Subject: Re: [PATCH] sched/numa: Fix NULL pointer access to mm_struct durng
task swap
On Thu, Jul 03, 2025 at 01:51:23PM +0200, Michal Hocko wrote:
> Why not use find_lock_task_mm if task_lock is acceptable for this code
> path?
Having to take locks just to count a number nobody is ever going to look
at is silly. Iterating the whole thread group (might be hundreds or
thousands of tasks) just to maybe find one when racing with a fatal
signal is even more silly.
Powered by blists - more mailing lists