linux-kernel - Re: [PATCH] alarmtimer: Add the verification code for rtc device error.

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Jul 2014 10:58:17 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Hyogi Gim <hyogi.gim@....com>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] alarmtimer: Add the verification code for rtc device error.

On Thu, Jul 10, 2014 at 6:24 PM, Hyogi Gim <hyogi.gim@....com> wrote:
> In alarmtimer_suspend(), the error after rtc_read_time() is not checked.
> If rtc device fail to read rtc time, we cannot ensure the following process.
>
> Furthermore, the return value of rtc_timer_start() needs to distinguish
> -ETIME and other rtc device error. If the error is relevant to rtc device,
> suspend is failed unintentionally. In this case, it just returns zero for
> a stable suspend. Otherwise, in the worst case, suspend will fail continually.


Hey! Sorry for the late response here.

So this seems reasonable as always failing suspend is problematic, but
I worry that for the case where we do have a failure to read or set
the RTC, we'd suspend and not wake up as specified, which is an issue
as well. Absorbing the error silently in these cases would make it
difficult to debug. Should we at least print some output out to help
folks hunt down this sort of issue?

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/