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
| ||
|
Date: Wed, 30 Mar 2016 16:51:04 +0530 From: Viresh Kumar <viresh.kumar@...aro.org> To: "Rafael J. Wysocki" <rafael@...nel.org> Cc: Rafael Wysocki <rjw@...ysocki.net>, Lists linaro-kernel <linaro-kernel@...ts.linaro.org>, "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] cpufreq: acpi: policy->driver_data can't be NULL in ->exit() On 30-03-16, 13:15, Rafael J. Wysocki wrote: > On Wed, Mar 30, 2016 at 6:24 AM, Viresh Kumar <viresh.kumar@...aro.org> wrote: > > Its always set by ->init() and so it will always be there in ->exit(). > > There is no need to have a special check for just that. > > I'm not sure what happens if there are two (or more) CPUs in the policy, though. > > That case is almost certainly handled incorrectly here (or rather not > handled at all), but it may just happen to sort of work, because the > first exiting CPU will clear driver_data and the second one will > notice that it is NULL now. Of course, that still is racy with > respect to governors etc, but I'd rather fix the driver properly. Sorry, I probably didn't understood your comments properly. But, the core will call ->exit() only for the last exiting CPU. So, driver_data will never be NULL. -- viresh
Powered by blists - more mailing lists