linux-toradex.git/kernel/time/clocksource.c, branch v2.6.32.15

timekeeping: Prevent oops when GENERIC_TIME=n

2010-04-01T22:58:06+00:00

commit ad6759fbf35d104dbf573cd6f4c6784ad6823f7e upstream.

Aaro Koskinen reported an issue in kernel.org bugzilla #15366, where
on non-GENERIC_TIME systems, accessing
/sys/devices/system/clocksource/clocksource0/current_clocksource
results in an oops.

It seems the timekeeper/clocksource rework missed initializing the
curr_clocksource value in the !GENERIC_TIME case.

Thanks to Aaro for reporting and diagnosing the issue as well as
testing the fix!

Reported-by: Aaro Koskinen 
Signed-off-by: John Stultz 
Cc: Martin Schwidefsky 
LKML-Reference: <1267475683.4216.61.camel@localhost.localdomain>
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

clocksource: fix compilation if no GENERIC_TIME

2010-02-09T12:50:54+00:00

commit a362c638bdf052bf424bce7645d39b101090f6ba upstream

Commit a9238ce3bb0fda6e760780b702c6cbd3793087d3 broke compilation on
platforms that do not implement GENERIC_TIME (e.g. iop32x):

  kernel/time/clocksource.c: In function 'clocksource_register':
  kernel/time/clocksource.c:556: error: implicit declaration of function 'clocksource_max_deferment'

Provide the implementation of clocksource_max_deferment() also for
such platforms.

Signed-off-by: Aaro Koskinen 
Cc: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

nohz: Prevent clocksource wrapping during idle

2010-01-28T23:01:12+00:00

commit 98962465ed9e6ea99c38e0af63fe1dcb5a79dc25 upstream.

The dynamic tick allows the kernel to sleep for periods longer than a
single tick, but it does not limit the sleep time currently. In the
worst case the kernel could sleep longer than the wrap around time of
the time keeping clock source which would result in losing track of
time.

Prevent this by limiting it to the safe maximum sleep time of the
current time keeping clock source. The value is calculated when the
clock source is registered.

[ tglx: simplified the code a bit and massaged the commit msg ]

Signed-off-by: Jon Hunter 
Cc: John Stultz 
LKML-Reference: <1250617512-23567-2-git-send-email-jon-hunter@ti.com>
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

clocksource: Resume clocksource without taking the clocksource mutex

2009-09-24T20:37:53+00:00

git commit 75c5158f70c065b9 converted the clocksource spinlock to a
mutex. This causes the following BUG:

BUG: sleeping function called from invalid context at
kernel/mutex.c:280 in_atomic(): 0, irqs_disabled(): 1, pid: 2473,
name: pm-suspend 2 locks held by pm-suspend/2473:
 #0:  (&buffer->mutex){......}, at: []
sysfs_write_file+0x3c/0x137
 #1:  (pm_mutex){......}, at: []
enter_state+0x39/0x130 Pid: 2473, comm: pm-suspend Not tainted 2.6.31
#1 Call Trace:
 [] ? __debug_show_held_locks+0x22/0x24
 [] __might_sleep+0x107/0x10b
 [] mutex_lock_nested+0x25/0x43
 [] clocksource_resume+0x1c/0x60
 [] timekeeping_resume+0x1e/0x1c8
 [] __sysdev_resume+0x25/0xcf
 [] sysdev_resume+0x6d/0xae
 [] suspend_devices_and_enter+0x12b/0x1af
 [] enter_state+0xdf/0x130
 [] state_store+0xb6/0xd3
 [] kobj_attr_store+0x17/0x19
 [] sysfs_write_file+0xfb/0x137
 [] vfs_write+0xae/0x10b
 [] ? __up_read+0x1a/0x7f
 [] sys_write+0x4a/0x6e
 [] system_call_fastpath+0x16/0x1b

clocksource_resume is called early in the resume process, there is
only one cpu, no processes are running and the interrupts are
disabled. It is therefore possible to resume the clocksources
without taking the clocksource mutex.

Reported-by: Xiaotian Feng 
Signed-off-by: Martin Schwidefsky 
Tested-by: Michal Schmidt 
Cc: Xiaotian Feng 
Cc: John Stultz 
LKML-Reference: <20090924172952.49697825@mschwide.boeblingen.de.ibm.com>
Signed-off-by: Ingo Molnar

clocksource: Delay clocksource down rating to late boot

2009-09-14T19:59:32+00:00

The down rating of clock sources in the early boot process via the
clock source watchdog mechanism can happen way before the per cpu
event queues are initialized. This leads to a boot crash on x86 when
the TSC is marked unstable in the SMP bring up.

The selection of a clock source for time keeping happens in the late
boot process so we can safely delay the list manipulation until
clocksource_done_booting() is called.

Signed-off-by: Thomas Gleixner 
LKML-Reference: 
Cc: Martin Schwidefsky

clocksource: clocksource_select must be called with mutex locked

2009-09-14T19:59:32+00:00

The callers of clocksource_select must hold clocksource_mutex to
protect the clocksource_list.

Signed-off-by: Thomas Gleixner 
LKML-Reference: 
Cc: Martin Schwidefsky

clocksource: Resolve cpu hotplug dead lock with TSC unstable, fix crash

2009-09-11T18:17:18+00:00

The watchdog timer is started after the watchdog clocksource
and at least one watched clocksource have been registered. The
clocksource work element watchdog_work is initialized just
before the clocksource timer is started. This is too late for
the clocksource_mark_unstable call from native_cpu_up. To fix
this use a static initializer for watchdog_work.

This resolves a boot crash reported by multiple people.

Signed-off-by: Martin Schwidefsky 
Cc: Jens Axboe 
Cc: John Stultz 
LKML-Reference: <20090911153305.3fe9a361@skybase>
Signed-off-by: Ingo Molnar

clocksource: Resolve cpu hotplug dead lock with TSC unstable

2009-08-28T18:25:24+00:00

Martin Schwidefsky analyzed it:
To register a clocksource the clocksource_mutex is acquired and if
necessary timekeeping_notify is called to install the clocksource as
the timekeeper clock. timekeeping_notify uses stop_machine which needs
to take cpu_add_remove_lock mutex.
Starting a new cpu is done with the cpu_add_remove_lock mutex held.
native_cpu_up checks the tsc of the new cpu and if the tsc is no good
clocksource_change_rating is called. Which needs the clocksource_mutex
and the deadlock is complete.

The solution is to replace the TSC via the clocksource watchdog
mechanism. Mark the TSC as unstable and schedule the watchdog work so
it gets removed in the watchdog thread context.

Signed-off-by: Thomas Gleixner 
LKML-Reference: 
Cc: Martin Schwidefsky 
Cc: John Stultz

clocksource: Avoid clocksource watchdog circular locking dependency

2009-08-19T10:00:56+00:00

stop_machine from a multithreaded workqueue is not allowed because
of a circular locking dependency between cpu_down and the workqueue
execution. Use a kernel thread to do the clocksource downgrade.

Signed-off-by: Martin Schwidefsky 
Cc: Peter Zijlstra 
Cc: john stultz 
LKML-Reference: <20090818170942.3ab80c91@skybase>
Signed-off-by: Thomas Gleixner

clocksource: Protect the watchdog rating changes with clocksource_mutex

2009-08-19T09:42:48+00:00

Martin pointed out that commit 6ea41d2529 (clocksource: Call
clocksource_change_rating() outside of watchdog_lock) has a
theoretical reference count problem. The calls to
clocksource_change_rating() are now done outside of the clocksource
mutex and outside of the watchdog lock. A concurrent
clocksource_unregister() could remove the clock.

Split out the code which changes the rating from
clocksource_change_rating() into __clocksource_change_rating().

Protect the clocksource_watchdog_work() code sequence with the
clocksource_mutex() and call __clocksource_change_rating().

LKML-Reference: 
Signed-off-by: Thomas Gleixner 
Cc: Martin Schwidefsky