linux-kernel - Re: [PATCH] clocksource/drivers/tango-xtal: Fix incorrect test

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] [day] [month] [year] [list]

Date:	Wed, 20 Apr 2016 06:55:51 +0200
From:	Daniel Lezcano <daniel.lezcano@...aro.org>
To:	Mason <slash.tmp@...e.fr>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Sebastian Frias <sf84@...oste.net>,
	Mans Rullgard <mans@...sr.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] clocksource/drivers/tango-xtal: Fix incorrect test

[ ... ]

> About the error handling... you advised against panic()
> because there might be other clock sources.
> 
> Does it makes sense to give up registering sched_clock
> and delay_timer when the clocksource registration fails?

Actually, all the problem is coming from the CLOCKSOURCE_OF_DECLARE where 
the init_func is a void (*init_func)(struct device_node *) signature, thus 
not allowing to return a value.

Because of that, the init code path of the different drivers are somewhat 
fuzzy when an error occurs.

If the function could return an error code, then the drivers would be 
written in a way to catch and handle the errors gracefully. That implies the 
clocksource-probe() routine will be able to detect when the init_func() is 
failing, trace it and count if one clocksource/clockevent succeed at boot 
time.

So because the latter, it would make sense to give up registering and leave 
a clean place in the init function when something is going wrong.

  -- Daniel