linux-kernel - Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)

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, 14 May 2014 21:13:50 +0200
From:	Alexander Holler <holler@...oftware.de>
To:	Rob Herring <robherring2@...il.com>
CC:	Grant Likely <grant.likely@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Jon Loeliger <jdl@....com>,
	Russell King <linux@....linux.org.uk>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Rob Herring <robh+dt@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization
 order based on the DT)

Am 14.05.2014 20:16, schrieb Alexander Holler:
> Am 14.05.2014 19:53, schrieb Alexander Holler:
>> Am 14.05.2014 19:45, schrieb Alexander Holler:
>>
>>> One of the biggest problem of the deferred probe stuff is the problem
>>> how to identify real problems if everything ends up with a deferred
>>> probe when an error occurs? That means if you display an error whenever
>>> something is deferred, the log becomes almost unreadable. If you don't
>>> display an error, you never will see an error. And how do you display
>>> the real error when deferred probes finally do fail? The deferred probe
>>> stuff doesn't has any information about the underlying error, so it
>>> can't display it.
>>
>> And that is a real problem. I've recently tried to identify why a driver
>> failed and it was a nightmare because nothing offered any message (debug
>> or not) when a probe was deferred. So I had to insert tons of printks to
>> walk upwards to find the finally place where the probe failed.
>> Everything afterwards just has forwarded the -EPROBE_DEFER without
>> printing any message.
>
> To add some numbers, I had to insert around 20-30 printks in around 10
> or more files to find the underlying problem. Having to do such whenever
> an error happens because everything assumes the error will disappear in
> a later try, which doesn't happen for real errors, is just a nightmare.

And to give other people an idea how such a nightmare which has become 
reality does look like:

You see a driver fails (through the deferred stuff). You look at that 
the driver and see around 5-10 places which return or forward an 
-EPROBE_DEFER. You add printks (to all or just some of them, hopefully 
the right ones, but Murphy ...). Then you go to the underlying 
functions. You see again several places which do the same, you add again 
printks. You go to the underlying functions ...

Finally you've created a tree full with nodes of printks, searching for 
the one leaf which is the origin of the -EPROBE_DEFER for your problem.

Regards,

Alexander Holler

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