Re: [PATCH 1/6] sched/numa: clear fault locality state on execve

[Li Zhe]

On 10/14/26 9:02 PM, Gregory Price wrote:
> On Wed, Oct 14, 2026 at 05:43:42PM +0800, Li Zhe wrote:
>> task_numa_free(p, false) is used by execve() to reset NUMA balancing
>> state without freeing p->numa_faults, because concurrent readers may
>> still observe the task.
>>
> Is a process that exec()'s going to run long enough to actually collect
> any real numa fault data?
>
>> the retained p->numa_faults array, but leaves the current-window buffer
>> half and p->numa_faults_locality unchanged. Those are also NUMA fault
>> feedback consumed by task_numa_placement() and update_task_scan_period(),
>> so a newly executed image can inherit stale fault feedback from the old
>> image.
> I'm not sure this actually corrects much unless you have a long running
> program that eventually exec()'s - and even then it seems like this all
> self-corrects within a couple seconds.
>
> Do you have some clear reproduction that makes an obvious wrong effect,
> or was this just some static analysis?
>
> It's "not wrong", but I'm trying to understand what impact this actually
> has.


This was found by code inspection, but it is related to the same class of
stale numa_faults_locality problem Eric fixed for update_task_scan_period():

https://lore.kernel.org/all/OS7PR01MB139144C7E07C97B3F3B47016796D52@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/

That patch clears locality feedback after the scan-period update, so stale
locality and migration-failure information does not affect later scan-period
decisions. This patch handles another reset boundary: execve() already calls
task_numa_free(p, false) to reset NUMA balancing state for the new 
image, but
that path leaves the current-window counters and numa_faults_locality 
behind.

So a newly exec'ed image can consume locality or migration-failure feedback
from the old image during its first placement update. I agree that the 
impact
is likely transient, especially once Eric's fix is present. The intent 
here is
to make the execve reset path complete, rather than to claim a severe 
runtime
bug.

Thanks,
Zhe


>
>> The non-final path clears p->total_numa_faults and the averaged half of
>>
>> Clear the whole retained p->numa_faults array and p->numa_faults_locality
>> together in the non-final reset path.
>>
>> Fixes: 04bb2f947505 ("sched/numa: Adjust scan rate in task_numa_placement")
>> Signed-off-by: Li Zhe <lizhe.67@xxxxxxxxxxxxx>
>> ---
>>   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 57360f5cdde4..1053437933ee 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -4177,8 +4177,9 @@ void task_numa_free(struct task_struct *p, bool final)
>>   		kfree(numa_faults);
>>   	} else {
>>   		p->total_numa_faults = 0;
>> -		for (i = 0; i < NR_NUMA_HINT_FAULT_STATS * nr_node_ids; i++)
>> -			numa_faults[i] = 0;
>> +		memset(p->numa_faults_locality, 0, sizeof(p->numa_faults_locality));
>> +		memset(numa_faults, 0, sizeof(*numa_faults) *
>> +		       NR_NUMA_HINT_FAULT_BUCKETS * nr_node_ids);
>>   	}
>>   }
>>   
>> -- 
>> 2.20.1