If request_module() failed then we didn't have the correct
opmode module that the driver needs to function, so print
a warning in this case to make it more obvious what could
be wrong. This still won't catch the case where the module
simply doesn't exist because it wasn't compiled though.
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For NUL terminated string we always need to set '\0' at the end.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Cc: rostedt@goodmis.org
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/516243B7.9020405@asianux.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
For NUL terminated string we always need to set '\0' at the end.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Cc: rostedt@goodmis.org
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Link: http://lkml.kernel.org/r/51624254.30301@asianux.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
For NUL terminated string, always make sure that there's '\0' at the end.
In our case we need a return value, so still use strncpy() and
fix up the tail explicitly.
(strlcpy() returns the size, not the pointer)
Signed-off-by: Chen Gang <gang.chen@asianux.com>
Cc: a.p.zijlstra@chello.nl <a.p.zijlstra@chello.nl>
Cc: paulus@samba.org <paulus@samba.org>
Cc: acme@ghostprotocols.net <acme@ghostprotocols.net>
Link: http://lkml.kernel.org/r/51623E0B.7070101@asianux.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Commit 201c373e8e ("sched/debug: Limit sd->*_idx range on
sysctl") was an incomplete bug fix.
This patch fixes sd->*_idx limit range to [0 ~ CPU_LOAD_IDX_MAX-1]
avoiding array overflow caused by setting sd->*_idx to CPU_LOAD_IDX_MAX
on sysctl.
Signed-off-by: Libin <huawei.libin@huawei.com>
Cc: <jiang.liu@huawei.com>
Cc: <guohanjun@huawei.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/51626610.2040607@huawei.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
feng xiangjun reports that my
commit 382a103b2b
Author: Johannes Berg <johannes.berg@intel.com>
Date: Fri Mar 22 22:30:09 2013 +0100
mac80211: fix idle handling sequence
broke the wireless status LED. The reason is that
we now call ieee80211_idle_off() when the channel
context is assigned, and that doesn't recalculate
the LED state. Fix this by making that function a
wrapper around most of idle recalculation while
forcing active.
Reported-by: feng xiangjun <fengxj325@gmail.com>
Tested-by: feng xiangjun <fengxj325@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
KBUILD_OUTPUT is always empty here, so it is useless to test it. But
while use O=.., objtree and srctree will be different. I compare them
instead.
Signed-off-by: Bin Wang <wbin00@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
This patch moves cpufreq driver of ARM based integrator platform to
drivers/cpufreq.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch moves cpufreq driver of ARM based pxa2xx platform to drivers/cpufreq.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch moves cpufreq driver of ARM based pxa3xx platform to drivers/cpufreq.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Eric Miao <eric.y.miao@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch moves cpufreq driver of ARM based davinci platform to
drivers/cpufreq.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch moves cpufreq driver of ARM based tegra platform to drivers/cpufreq.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Normally we keep drivers in alphabetical inside Kconfig and Makefile and over
time this was broken for ARM cpufreq drivers. Fix it.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Let's do the changes properly and fix the same problem everywhere, not
just for one case.
Cc: <stable@vger.kernel.org> # kernels containing 15e0d9e37c or equivalent
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Propagate errors from ip_xfrm_me_harder() instead of returning EPERM in
all cases.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Propagate routing errors from ip_route_me_harder() when dropping a packet
using NF_DROP_ERR(). This makes userspace get the proper error instead of
EPERM for everything.
# ip -6 r a unreachable default table 100
# ip -6 ru add fwmark 0x1 lookup 100
# ip6tables -t mangle -A OUTPUT -d 2001:4860:4860::8888 -j MARK --set-mark 0x1
Old behaviour:
PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
New behaviour:
PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Propagate routing errors from ip_route_me_harder() when dropping a packet
using NF_DROP_ERR(). This makes userspace get the proper error instead of
EPERM for everything.
Example:
# ip r a unreachable default table 100
# ip ru add fwmark 0x1 lookup 100
# iptables -t mangle -A OUTPUT -d 8.8.8.8 -j MARK --set-mark 0x1
Current behaviour:
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
New behaviour:
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
* acpi-assorted:
PCI / ACPI: Don't query OSC support with all possible controls
ACPI / processor_thermal: avoid null pointer deference error
ACPI / fan: avoid null pointer deference error
ACPI / video: Fix applying indexed initial brightness value.
ACPI / video: Make logic a little easier to understand.
ACPI / video: Fix brightness control initialization for some laptops.
ACPI: Use resource_size() in osl.c
ACPI / acpi_pad: Used PTR_RET
ACPI: suppress compiler warning in container.c
ACPI: suppress compiler warning in battery.c
ACPI: suppress compiler warnings in processor_throttling.c
ACPI: suppress compiler warnings in button.c
ACPI: replace kmalloc+memcpy with kmemdup
ACPI: Remove acpi_pci_bind_root() definition
ACPI video: ignore BIOS backlight value for HP dm4
* acpica: (22 commits)
ACPI: Set length even for TYPE_END_TAG acpi resource
ACPICA: Update version to 20130214
ACPICA: Object repair: Allow 0-length packages for variable-length packages
ACPICA: Disassembler: Add warnings for unresolved control methods
ACPICA: Return object repair: Add resource template repairs
ACPICA: Return object repair: Add string-to-unicode conversion
ACPICA: Split object conversion functions to a new file
ACPICA: Add mechanism for early object repairs on a per-name basis
ACPICA: Remove trailing comma in enum declarations
ACPICA: Add exception descriptions to exception info table
ACPICA: Add macros to exception code definitions
ACPICA: Regression fix: reinstate safe exit macros
ACPICA: Update for ACPI 5 hardware-reduced feature
ACPICA: Add parens within macros around parameter names
ACPICA: Add macros to access pointer to next object in the descriptor list
ACPICA: Update error/debug messages for fixed events
ACPICA: Fix a long-standing bug in local cache
ACPICA: iASL/Disassembler: Add support for MTMR table
ACPICA: iASL/Disassembler: Add support for VRTC table
ACPICA: Update RASF table definition
...
* acpi-lpss:
ACPI / LPSS: make code less confusing for reader
ACPI / LPSS: Add support for exposing LTR registers to user space
ACPI / scan: Add special handler for Intel Lynxpoint LPSS devices
* acpi-hotplug:
ACPI / memhotplug: Remove info->failed bit
ACPI / memhotplug: set info->enabled for memory present at boot time
ACPI: Verify device status after eject
acpi: remove reference to ACPI_HOTPLUG_IO
ACPI: Update _OST handling for notify
ACPI: Update PNPID match handling for notify
ACPI: Update PNPID set/free interfaces
ACPI: Remove acpi_device dependency in acpi_device_set_id()
ACPI / hotplug: Make acpi_hotplug_profile_ktype static
ACPI / scan: Make memory hotplug driver use struct acpi_scan_handler
ACPI / container: Use hotplug profile user space interface
ACPI / hotplug: Introduce user space interface for hotplug profiles
ACPI / scan: Introduce acpi_scan_handler_matching()
ACPI / container: Use common hotplug code
ACPI / scan: Introduce common code for ACPI-based device hotplug
ACPI / scan: Introduce acpi_scan_match_handler()
The implementation of ab8500_ext_fixed_get_voltage is identical to
ab8500_ext_list_voltage. We can avoid the duplicate implementation by just
remove get_voltage. For fixed regulator, regulator core will call
list_voltage(rdev, 0) to get voltage if both get_voltage get_voltage_sel are
not implemented.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This code was added by commit 0fe17e20a6
"regulator: ab8500-ext: Add support for AB9540 regulators"
and commit bd44e2cb "regulator: ab8500: Also check for AB8505 based platforms"
The original patch[1] is to set info->desc.ops = &ab9540_ext_regulator_ops.
However, ab9540_ext_regulator_ops is identical to ab8500_ext_regulator_ops[2].
Thus we can complete remove the unnecessary checking for ab9540 and ab8540.
[1] https://lkml.org/lkml/2013/3/28/333
[2] https://lkml.org/lkml/2013/4/1/178
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The intention of this patch is to simplify the code.
Maintain the is_enabled flag is not trivial, it not only needs to set/clear the
flag in disable()/enable() but also needs to set the flag in is_enable() to get
initial status. The only benefit of keeping is_enabled flag is just save a
register read when set_mode(). Remove is_enabled flag makes the code simpler.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The intention of this patch is to simplify the code.
Maintain the is_enabled flag is not trivial, it not only needs to set/clear the
flag in disable()/enable() but also needs to set the flag in is_enable() to get
initial status. The only benefit of keeping is_enabled flag is just save a
register read when set_mode(). Remove is_enabled flag makes the code simpler.
This patch also moves ab8500_regulator_is_enabled() close to
ab8500_regulator_[en|dis]able functions.
This is required to avoid a forward declaration because now we call
ab8500_regulator_is_enabled() in ab8500_regulator_set_mode().
This change also makes the code better in readability by moving similar
functions to one place.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Symbol rate ratio were using a rough calculus, as the code was
limited to 32 bits arithmetic. Change it to 64 bits, in order
to better estimate the bandwidth low-pass filter on the demod.
This should reduce the noise and improve reception.
Reported-by: Hans-Peter Jansen <hpj@urpla.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Using 'i' for the guard interval temporary var is a bad idea, as
'i' is generally used by "anonymous" indexes.
Let's rename modulation, fec and guard interval temp vars with
a meaningful name, as that makes easier to understand the code
and avoids cut-and-paste types of error.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As reported by Dan Carpenter <dan.carpenter@oracle.com>:
Smatch warnings:
drivers/media/dvb-frontends/mb86a20s.c:644 mb86a20s_layer_bitrate() error: buffer overflow 'state->estimated_rate' 3 <= 3
What happens there is that estimate_rate index should be the layer
number, and not the guard interval.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We're using the anonymous 'i' to indicate the layer number
on several places on the driver. That's not good, as some
cut-and-paste type of change might be doing the wrong thing.
So, call it as "layer" everywhere.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using the magic number "3", use NUM_LAYERS macro
on all places that are related to the ISDB-T layers.
This makes the source code a little more readable.
No functional changes.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Use enum instead of magic values for LNA config in tda8290.
Update tda827x, tda18271 and saa7134 to use the enum too.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Add AverMedia AverTV Satellite Hybrid+FM (A706) card to saa7134 driver.
Working: analog inputs, TV, FM radio and IR remote control.
Untested: DVB-S.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The variable kvm_rebooting is a common kvm variable, so move its
declaration from arch/x86/include/asm/kvm_host.h to
include/asm/kvm_host.h.
Fixes this sparse warning when building on arm64:
virt/kvm/kvm_main.c⚠️ symbol 'kvm_rebooting' was not declared. Should it be static?
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
The routine kvm_spurious_fault() is an x86 specific routine, so
move it from virt/kvm/kvm_main.c to arch/x86/kvm/x86.c.
Fixes this sparse warning when building on arm64:
virt/kvm/kvm_main.c⚠️ symbol 'kvm_spurious_fault' was not declared. Should it be static?
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
The routines get_user_page_nowait(), kvm_io_bus_sort_cmp(), kvm_io_bus_insert_dev()
and kvm_io_bus_get_first_dev() are only referenced within kvm_main.c, so give them
static linkage.
Fixes sparse warnings like these:
virt/kvm/kvm_main.c: warning: symbol 'get_user_page_nowait' was not declared. Should it be static?
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
The variables vm_list and kvm_lock are common to all architectures, so
move the declarations from arch/x86/include/asm/kvm_host.h to
include/linux/kvm_host.h.
Fixes sparse warnings like these when building for arm64:
virt/kvm/kvm_main.c: warning: symbol 'kvm_lock' was not declared. Should it be static?
virt/kvm/kvm_main.c: warning: symbol 'vm_list' was not declared. Should it be static?
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
config looks like a hack that was added to tuner-core to allow some
configuration of TDA8290 tuner (it's not used by any other driver).
But with the new configuration options of tda8290 driver (no_i2c_gate
and std_map), it's no longer sufficient.
Change config to be void * instead, which allows passing tuner-dependent
config struct to drivers.
Also update saa7134 driver to reflect this change (no other driver uses this).
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Allow specifying a custom std_map for tda18271 by external configuration.
This is required by cards that require custom std_map for analog TV or radio,
like AverMedia A706.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Allow disabling I2C gate handling by external configuration.
This is required by cards that have all devices on a single I2C bus,
like AverMedia A706.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
'patch_regs' cannot be used uninitialized in wm8994_device_init(),
because 'patch_regs' was already guarded by 'regmap_patch'.
Thus, that's a bogus warning.
Without this patch, the build warning happens as below:
drivers/mfd/wm8994-core.c: In function 'wm8994_i2c_probe':
drivers/mfd/wm8994-core.c:595:7: warning: 'patch_regs' may be used uninitialized in this function [-Wuninitialized]
drivers/mfd/wm8994-core.c:408:14: note: 'patch_regs' was declared here
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Hauppauge Nova-S-Plus DVB-S model 92001 does not lock on horizontal
polarisation. According with the info provided at the BZ, model
92002 does.
The difference is that, on model 92001, the tone select is done via
isl6421, while, on other devices, this is done via cx24123 code.
This patch adds a way to override the demod's set_tone at isl6421
driver. In order to avoid regressions, the override is enabled
only for cx88 Nova S plus model 92001. For all other models and
devices, the set_tone is provided by the demod driver.
Patch originally proposed at bz@9476[1] by Michel Meyers and
John Donoghue but applying the original patch would break support
for all other devices based on isl6421.
[1] https://bugzilla.kernel.org/show_bug.cgi?id=9476
Tested-by: Adam Sampson <ats@offog.org>
Tested-by: Hans-Peter Jansen <hpj@urpla.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
rc_unregister_device already calls rc_free_device to free the passed
device. But in one of ttusbir's probe fail paths, we call
rc_unregister_device _and_ rc_free_device. This is wrong and results
in a double free.
Instead, set rc to NULL resulting in rc_free_device being a noop.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
"enum dmx_ts_pes" and "typedef enum dmx_pes_type_t" are just the
same enum declared twice, since Kernel (2.6.12). There's no reason
to duplicate it there, and sparse complains about that:
drivers/media/dvb-core/dmxdev.c:600:55: warning: mixing different enum types
So, remove the internal define, keeping just the external one.
Internally, use only "enum dmx_ts_pes", as it is too late to drop
dmx_pes_type_t from the userspace API.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The sched_clock_remote() implementation has the following inatomicity
problem on 32bit systems when accessing the remote scd->clock, which
is a 64bit value.
CPU0 CPU1
sched_clock_local() sched_clock_remote(CPU0)
...
remote_clock = scd[CPU0]->clock
read_low32bit(scd[CPU0]->clock)
cmpxchg64(scd->clock,...)
read_high32bit(scd[CPU0]->clock)
While the update of scd->clock is using an atomic64 mechanism, the
readout on the remote cpu is not, which can cause completely bogus
readouts.
It is a quite rare problem, because it requires the update to hit the
narrow race window between the low/high readout and the update must go
across the 32bit boundary.
The resulting misbehaviour is, that CPU1 will see the sched_clock on
CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value
to this bogus timestamp. This stays that way due to the clamping
implementation for about 4 seconds until the synchronization with
CLOCK_MONOTONIC undoes the problem.
The issue is hard to observe, because it might only result in a less
accurate SCHED_OTHER timeslicing behaviour. To create observable
damage on realtime scheduling classes, it is necessary that the bogus
update of CPU1 sched_clock happens in the context of an realtime
thread, which then gets charged 4 seconds of RT runtime, which results
in the RT throttler mechanism to trigger and prevent scheduling of RT
tasks for a little less than 4 seconds. So this is quite unlikely as
well.
The issue was quite hard to decode as the reproduction time is between
2 days and 3 weeks and intrusive tracing makes it less likely, but the
following trace recorded with trace_clock=global, which uses
sched_clock_local(), gave the final hint:
<idle>-0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80
<idle>-0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ...
irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0
<idle>-0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80
What happens is that CPU0 goes idle and invokes
sched_clock_idle_sleep_event() which invokes sched_clock_local() and
CPU1 runs a remote wakeup for CPU0 at the same time, which invokes
sched_remote_clock(). The time jump gets propagated to CPU0 via
sched_remote_clock() and stays stale on both cores for ~4 seconds.
There are only two other possibilities, which could cause a stale
sched clock:
1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic
wrong value.
2) sched_clock() which reads the TSC returns a sporadic wrong value.
#1 can be excluded because sched_clock would continue to increase for
one jiffy and then go stale.
#2 can be excluded because it would not make the clock jump
forward. It would just result in a stale sched_clock for one jiffy.
After quite some brain twisting and finding the same pattern on other
traces, sched_clock_remote() remained the only place which could cause
such a problem and as explained above it's indeed racy on 32bit
systems.
So while on 64bit systems the readout is atomic, we need to verify the
remote readout on 32bit machines. We need to protect the local->clock
readout in sched_clock_remote() on 32bit as well because an NMI could
hit between the low and the high readout, call sched_clock_local() and
modify local->clock.
Thanks to Siegfried Wulsch for bearing with my debug requests and
going through the tedious tasks of running a bunch of reproducer
systems to generate the debug information which let me decode the
issue.
Reported-by: Siegfried Wulsch <Siegfried.Wulsch@rovema.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
