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: <20180115174122.GA20745@lenoch>
Date:   Mon, 15 Jan 2018 18:41:22 +0100
From:   Ladislav Michl <ladis@...ux-mips.org>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:     linux-omap@...r.kernel.org, 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()

On Mon, Jan 15, 2018 at 06:06:20PM +0100, SF Markus Elfring wrote:
> >>> 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?

ARM_UNWIND

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

I'm aware of this article. Please bear in mind which driver you are modifying.
Not everything is desktop or server machine with almost unlimited resources
and embedded people are rarely using latest stuff with all that bells and
whistles.

That said, you might end having only fragment of log in only one of thousands
machines in field. And saying technician he needs to use another kernel
(upgrade all machines) and wait another several weeks for bug to trigger
is no way.

So until evolution reaches ARM land, my point stands unchanged: Make it
single allocation or leave one of those two messages in place.

In practice it probably does not matter if we know which allocation
failed. We simply run out of memmory.

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

Of course not as there will be only one memory allocation in the probe
function.

Best regards,
	ladis