linux-kernel - Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc

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]

Message-ID: <1522282337.10662.268.camel@impinj.com>
Date:   Thu, 29 Mar 2018 00:12:18 +0000
From:   Trent Piepho <tpiepho@...inj.com>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "alexandre.belloni@...e-electrons.com" 
        <alexandre.belloni@...e-electrons.com>,
        "pure.logic@...us-software.ie" <pure.logic@...us-software.ie>
CC:     "shawn.guo@...aro.org" <shawn.guo@...aro.org>,
        "stefan@...er.ch" <stefan@...er.ch>,
        "bianpan2016@....com" <bianpan2016@....com>,
        "a.zummo@...ertech.it" <a.zummo@...ertech.it>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "guy.shapiro@...i-wize.com" <guy.shapiro@...i-wize.com>,
        "Frank.Li@...escale.com" <Frank.Li@...escale.com>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>
Subject: Re: [RESEND] rtc: snvs: Fix usage of snvs_rtc_enable

On Wed, 2018-03-28 at 20:14 +0100, Bryan O'Donoghue wrote:
> 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().
> 
> 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.
> 

I sent a patch a couple weeks ago that addressed a similar issue, see
https://patchwork.ozlabs.org/patch/887090/

Does this also fix the problem you see?

I think what you've done will prevent the driver from loading if the
clock is not working, but if the clock does not tick properly after
loading, there are still points (snvs_rtc_read_time for one) that will
lock up in the kernel.