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: Sun, 23 Feb 2020 20:01:33 -0500 From: Qian Cai <cai@....pw> To: "Rafael J. Wysocki" <rafael@...nel.org> Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, elver@...gle.com, Linux PM <linux-pm@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [PATCH -next] power/qos: fix a data race in pm_qos_*_value > On Feb 23, 2020, at 7:12 PM, Rafael J. Wysocki <rafael@...nel.org> wrote: > > It may be a bug under certain conditions, but you don't mention what > conditions they are. Reporting it as a general bug is not accurate at > the very least. Could we rule out load tearing, store tearing and reload of global_req in cpuidle_governor_latency() for all compilers and architectures which could introduce logic bugs? int global_req = cpu_latency_qos_limit(); if (device_req > global_req) device_req = global_req; If under register pressure, the compiler might get ride of the tmp variable, i.e., If (device_req > cpu_latency_qos_limit()) —-> race with the writer. device_req = cpu_latency_qos_limit();
Powered by blists - more mailing lists