linux-kernel - Re: [PATCH] x86: honor ACPI FADT flag indicating absence of a CMOS 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: <5261015702000078000FBFA1@nat28.tlf.novell.com>
Date:	Fri, 18 Oct 2013 08:37:26 +0100
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Ingo Molnar" <mingo@...nel.org>
Cc:	<mingo@...e.hu>, "John Stultz" <john.stultz@...aro.org>,
	<tglx@...utronix.de>, <linux-kernel@...r.kernel.org>,
	<hpa@...or.com>
Subject: Re: [PATCH] x86: honor ACPI FADT flag indicating absence of a
 CMOS RTC

>>> On 18.10.13 at 08:29, Ingo Molnar <mingo@...nel.org> wrote:
> * Jan Beulich <JBeulich@...e.com> wrote:
> 
>> We shouldn't be creating a corresponding platform device in that case.
> 
> There's a sad lack of context in the changelog, how was it found, does 
> this address any problem/bug observed in practice, etc?

This was a result from code review in Xen hypervisor code in
the context of ACPI 5 work there, which lead me to check whether
Linux would honor that flag. No known issue in practice so far.
Once the below got clarified, I can certainly extend the description
in an eventual resubmission (albeit I would have though that fixing
the not honoring of a firmware flag should speak for itself).

>> +#ifdef CONFIG_ACPI
>> +	if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_CMOS_RTC)
>> +		return -ENODEV;
>> +#endif
> 
> It might also be prudent to emit a KERN_INFO line telling that we don't 
> create the device - so that people who suddenly see unexpected breakage or 
> change in behavior have a chance to see what we've done?

There are so many other -ENODEV return paths here which don't
emit messages that this seemed inappropriate, the more that a
message _is_ being issued if the platform RTC device does get
registered (and hence one could judge by the message
disappearing between before and after the patch got applied).

Jan

--
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/