linux-kernel - Re: [PATCH] PM / EM: consult something about cpumask in em_dev_register_perf

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] [day] [month] [year] [list]

Message-ID: <20201012131004.GB3366383@google.com>
Date:   Mon, 12 Oct 2020 14:10:04 +0100
From:   Quentin Perret <qperret@...gle.com>
To:     zhuguangqing83@...il.com
Cc:     lukasz.luba@....com, quentin.perret@....com, rjw@...ysocki.net,
        pavel@....cz, len.brown@...el.com, linux-pm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        zhuguangqing <zhuguangqing@...omi.com>
Subject: Re: [PATCH] PM / EM: consult something about cpumask in
 em_dev_register_perf_domain

On Monday 12 Oct 2020 at 14:05:01 (+0100), Quentin Perret wrote:
> > 3, The third question is, how can we ensure cpu_dev as follows is not
> > NULL? If we can't ensure that, maybe we should add a check before using
> > it.
> > /kernel/power/energy_model.c
> > 174) static int em_create_pd(struct device *dev, int nr_states,
> > 175)                    struct em_data_callback *cb, cpumask_t *cpus)
> > 176) {
> > 199)    if (_is_cpu_device(dev))
> > 200)            for_each_cpu(cpu, cpus) {
> > 201)                    cpu_dev = get_cpu_device(cpu);
> > 202)                    cpu_dev->em_pd = pd;
> > 203)            }
> 
> And that should not be necessary as we check for the !dev case at the
> top of em_dev_register_perf_domain(). Or were you thinking about
> something else?

Oh I think I read that one wrong, but the conclusion should be the same,
at least on Arm64 -- all _possible_ CPUs should be registered early
enough for that not to be an issue.

Did you observe anything wrong there for your use-case?

Thanks,
Quentin