linux-stable.git/drivers/rtc, branch v4.9.147

rtc: snvs: Add timeouts to avoid kernel lockups

2018-12-21T13:11:40+00:00

[ Upstream commit cd7f3a249dbed2858e6c2f30e5be7f1f7a709ee2 ]

In order to read correctly from asynchronously updated RTC registers,
it's necessary to read repeatedly until their values do not change from
read to read.  It's also necessary to wait for three RTC clock ticks for
certain operations.  There are no timeouts in this code and these
operations could possibly loop forever.

To avoid kernel hangs, put in timeouts.

The iMX7d can be configured to stop the SRTC on a tamper event, which
will lockup the kernel inside this driver as described above.

These hangs can happen when running under qemu, which doesn't emulate
the SNVS RTC, though currently the driver will refuse to load on qemu
due to a timeout in the driver probe method.

It could also happen if the SRTC block where somehow placed into reset
or the slow speed clock that drives the SRTC counter (but not the CPU)
were to stop.

The symptoms on a two core iMX7d are a work queue hang on
rtc_timer_do_work(), which eventually blocks a systemd fsnotify
operation that triggers a work queue flush, causing systemd to hang and
thus causing all services that should be started by systemd, like a
console getty, to fail to start or stop.

Also optimize the wait code to wait less.  It only needs to wait for the
clock to advance three ticks, not to see it change three times.

Cc: Alexandre Belloni 
Cc: Alessandro Zummo 
Cc: Fabio Estevam 
Cc: Shawn Guo 
Cc: Bryan O'Donoghue 
Signed-off-by: Trent Piepho 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: snvs: add a missing write sync

2018-12-21T13:11:40+00:00

[ Upstream commit 7bb633b1a9812a6b9f3e49d0cf17f60a633914e5 ]

The clear of the LPTA_EN flag should be synced before writing to the
alarm register. Omitting this synchronization creates a race when
trying to change existing alarm.

Signed-off-by: Guy Shapiro 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: pcf2127: fix a kmemleak caused in pcf2127_i2c_gather_write

2018-12-01T08:44:20+00:00

[ Upstream commit 9bde0afb7a906f1dabdba37162551565740b862d ]

pcf2127_i2c_gather_write() allocates memory as local variable
for i2c_master_send(), after finishing the master transfer,
the allocated memory should be freed. The kmemleak is reported:

unreferenced object 0xffff80231e7dba80 (size 64):
  comm "hwclock", pid 27762, jiffies 4296880075 (age 356.944s)
  hex dump (first 32 bytes):
    03 00 12 03 19 02 11 13 00 80 98 18 00 00 ff ff ................
    00 50 00 00 00 00 00 00 02 00 00 00 00 00 00 00 .P..............
  backtrace:
    [] create_object+0xf8/0x278
    [] kmemleak_alloc+0x74/0xa0
    [] __kmalloc+0x1ac/0x348
    [] pcf2127_i2c_gather_write+0x54/0xf8
    [] _regmap_raw_write+0x464/0x850
    [] regmap_bulk_write+0x1a4/0x348
    [] pcf2127_rtc_set_time+0xac/0xe8
    [] rtc_set_time+0x80/0x138
    [] rtc_dev_ioctl+0x398/0x610
    [] do_vfs_ioctl+0xb0/0x848
    [] SyS_ioctl+0x8c/0xa8
    [] el0_svc_naked+0x34/0x38
    [] 0xffffffffffffffff

Signed-off-by: Xulin Sun 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin

rtc: hctosys: Add missing range error reporting

2018-11-21T08:26:03+00:00

commit 7ce9a992ffde8ce93d5ae5767362a5c7389ae895 upstream.

Fix an issue with the 32-bit range error path in `rtc_hctosys' where no
error code is set and consequently the successful preceding call result
from `rtc_read_time' is propagated to `rtc_hctosys_ret'.  This in turn
makes any subsequent call to `hctosys_show' incorrectly report in sysfs
that the system time has been set from this RTC while it has not.

Set the error to ERANGE then if we can't express the result due to an
overflow.

Signed-off-by: Maciej W. Rozycki 
Fixes: b3a5ac42ab18 ("rtc: hctosys: Ensure system time doesn't overflow time_t")
Cc: stable@vger.kernel.org # 4.17+
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman

rtc: bq4802: add error handling for devm_ioremap

2018-09-26T06:36:39+00:00

[ Upstream commit 7874b919866ba91bac253fa219d3d4c82bb944df ]

When devm_ioremap fails, the lack of error-handling code may
cause unexpected results.

This patch adds error-handling code after calling devm_ioremap.

Signed-off-by: Zhouyang Jia 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: omap: fix potential crash on power off

2018-09-09T18:01:22+00:00

commit 5c8b84f410b3819d14cb1ebf32e4b3714b5a6e0b upstream.

Do not set the system power-off callback and omap power-off rtc pointer
until we're done setting up our device to avoid leaving stale pointers
around after a late probe error.

Fixes: 97ea1906b3c2 ("rtc: omap: Support ext_wakeup configuration")
Cc: stable      # 4.9
Cc: Marcin Niestroj 
Cc: Tony Lindgren 
Signed-off-by: Johan Hovold 
Acked-by: Tony Lindgren 
Reviewed-by: Marcin Niestroj 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Greg Kroah-Hartman

rtc: ensure rtc_set_alarm fails when alarms are not supported

2018-08-03T05:55:13+00:00

[ Upstream commit abfdff44bc38e9e2ef7929f633fb8462632299d4 ]

When using RTC_ALM_SET or RTC_WKALM_SET with rtc_wkalrm.enabled not set,
rtc_timer_enqueue() is not called and rtc_set_alarm() may succeed but the
subsequent RTC_AIE_ON ioctl will fail. RTC_ALM_READ would also fail in that
case.

Ensure rtc_set_alarm() fails when alarms are not supported to avoid letting
programs think the alarms are working for a particular RTC when they are
not.

Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: tx4939: avoid unintended sign extension on a 24 bit shift

2018-05-25T14:13:15+00:00

[ Upstream commit 347876ad47b9923ce26e686173bbf46581802ffa ]

The shifting of buf[5] by 24 bits to the left will be promoted to
a 32 bit signed int and then sign-extended to an unsigned long. If
the top bit of buf[5] is set then all then all the upper bits sec
end up as also being set because of the sign-extension. Fix this by
casting buf[5] to an unsigned long before the shift.

Detected by CoverityScan, CID#1465292 ("Unintended sign extension")

Fixes: 0e1492330cd2 ("rtc: add rtc-tx4939 driver")
Signed-off-by: Colin Ian King 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: hctosys: Ensure system time doesn't overflow time_t

2018-05-25T14:13:15+00:00

[ Upstream commit b3a5ac42ab18b7d1a8f2f072ca0ee76a3b754a43 ]

On 32bit platforms, time_t is still a signed 32bit long. If it is
overflowed, userspace and the kernel cant agree on the current system time.
This causes multiple issues, in particular with systemd:
https://github.com/systemd/systemd/issues/1143

A good workaround is to simply avoid using hctosys which is something I
greatly encourage as the time is better set by userspace.

However, many distribution enable it and use systemd which is rendering the
system unusable in case the RTC holds a date after 2038 (and more so after
2106). Many drivers have workaround for this case and they should be
eliminated so there is only one place left to fix when userspace is able to
cope with dates after the 31bit overflow.

Acked-by: Arnd Bergmann 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

rtc: snvs: Fix usage of snvs_rtc_enable

2018-05-25T14:13:15+00:00

[ Upstream commit 1485991c024603b2fb4ae77beb7a0d741128a48e ]

commit 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver") introduces
the SNVS RTC driver with a function snvs_rtc_enable().

snvs_rtc_enable() can return an error on the enable path however this
driver does not currently trap that failure on the probe() path and
consequently if enabling the RTC fails we encounter a later error spinning
forever in rtc_write_sync_lp().

[   36.093481] [] (__irq_svc) from [] (_raw_spin_unlock_irqrestore+0x34/0x44)
[   36.102122] [] (_raw_spin_unlock_irqrestore) from [] (regmap_read+0x4c/0x5c)
[   36.110938] [] (regmap_read) from [] (rtc_write_sync_lp+0x6c/0x98)
[   36.118881] [] (rtc_write_sync_lp) from [] (snvs_rtc_alarm_irq_enable+0x40/0x4c)
[   36.128041] [] (snvs_rtc_alarm_irq_enable) from [] (rtc_timer_do_work+0xd8/0x1a8)
[   36.137291] [] (rtc_timer_do_work) from [] (process_one_work+0x28c/0x76c)
[   36.145840] [] (process_one_work) from [] (worker_thread+0x34/0x58c)
[   36.153961] [] (worker_thread) from [] (kthread+0x138/0x150)
[   36.161388] [] (kthread) from [] (ret_from_fork+0x14/0x20)
[   36.168635] rcu_sched kthread starved for 2602 jiffies! g496 c495 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=0
[   36.178564] rcu_sched       R  running task        0     8      2 0x00000000
[   36.185664] [] (__schedule) from [] (schedule+0x3c/0xa0)
[   36.192739] [] (schedule) from [] (schedule_timeout+0x78/0x4e0)
[   36.200422] [] (schedule_timeout) from [] (rcu_gp_kthread+0x648/0x1864)
[   36.208800] [] (rcu_gp_kthread) from [] (kthread+0x138/0x150)
[   36.216309] [] (kthread) from [] (ret_from_fork+0x14/0x20)

This patch fixes by parsing the result of rtc_write_sync_lp() and
propagating both in the probe and elsewhere. If the RTC doesn't start we
don't proceed loading the driver and don't get into this loop mess later
on.

Fixes: 179a502f8c46 ("rtc: snvs: add Freescale rtc-snvs driver")
Signed-off-by: Bryan O'Donoghue 
Acked-by: Shawn Guo 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman