linux-kernel - Re: [PATCH v3 3/8] sched/topology: Switch to assigning "sd->shared" from s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d466812b-24fb-4ac0-8e42-bf8f97c76e2f@linux.ibm.com>
Date: Fri, 23 Jan 2026 09:38:45 +0530
From: Shrikanth Hegde <sshegde@...ux.ibm.com>
To: K Prateek Nayak <kprateek.nayak@....com>
Cc: 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>,
        Chen Yu <yu.c.chen@...el.com>,
        "Gautham R. Shenoy" <gautham.shenoy@....com>,
        Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/8] sched/topology: Switch to assigning "sd->shared"
 from s_data



On 1/22/26 2:06 PM, K Prateek Nayak wrote:
> Hello Shrikanth,
> 
> On 1/22/2026 1:42 PM, Shrikanth Hegde wrote:
>>> @@ -2709,6 +2720,9 @@ build_sched_domains(const struct cpumask *cpu_map, struct sched_domain_attr *att
>>>            if (!cpumask_test_cpu(i, cpu_map))
>>>                continue;
>>>    +        if (atomic_read(&(*per_cpu_ptr(d.sds, i))->ref))
>>> +            *per_cpu_ptr(d.sds, i) = NULL;
>>> +
>>
>> Can we do this claim_allocations only?
> 
> I didn't do it there since we didn't have reference to the "s_data"
> inside claim_allocations().
> 
> If I remember this right, only init_sched_groups_capacity() has the
> requirement to traverse the CPUs in reverse to do
> update_group_capacity() when we hit the first CPU in the group.
> It doesn't modify the "->ref" of any allocations.
> 
> I can put the claim_allocations() bits the previous loop and pass the
> CPU and the s_data reference so it can free both "d.sds" and all the
> "d.sd" bits in one place and retain this reverse loop for
> init_sched_groups_capacity(). Does that sound better?
> 

Yes.IMO Having it in one place is better.
Even the next loop could be used to do that.

>> sdt_alloc and free is complicated already.
>>
>>>            for (sd = *per_cpu_ptr(d.sd, i); sd; sd = sd->parent) {
>>>                claim_allocations(i, sd);
>>>                init_sched_groups_capacity(i, sd);
>>
>