linux-kernel - Re: [1/3] mfd/omap-usb-tll: Delete two error messages for a failed memory allocation in usbtll_omap

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: <ead577ac-a36b-dfc4-9f2c-3d5f34495d78@users.sourceforge.net>
Date:   Mon, 15 Jan 2018 18:06:20 +0100
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Ladislav Michl <ladis@...ux-mips.org>, linux-omap@...r.kernel.org
Cc:     Lee Jones <lee.jones@...aro.org>, Tony Lindgren <tony@...mide.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: [1/3] mfd/omap-usb-tll: Delete two error messages for a failed
 memory allocation in usbtll_omap_probe()

>>> Now, if probe function calls devm_kzalloc two times and one of them fails,
>>> you cannot easily say which one without looking at assembly listing.
>>
>> Will this situation change with any other implementation for such backtraces?
> 
> How much that situation changes depends mainly on that very person who is
> sending bugreport and his/her ability and willigness to eventually change
> said implementation.

Have you got any more influence on the selection?

Which variant was applied for your example?


> In the other words your question (presumably) expects a world of
> ideal backtraces, which is (so far) rarely the case.

I assume that further software evolution will matter.

Does an article like “The ORCs are coming” (by Jonathan Corbet from 2017-07-20)
point information out which is also useful for this issue here?

https://lwn.net/Articles/728339/


> Anyway, if we agree to change the way we allocate driver data here,
> the issue this debate is about will no longer exist.

Does your update suggestion contain still any additional error messages for
memory allocation failures?

Regards,
Markus