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: <cadb0da1-23d0-f629-8dcf-8d2566058812@users.sourceforge.net>
Date:   Mon, 15 Jan 2018 19:12:37 +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()

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

This was not really my intention here.


> So until evolution reaches ARM land, my point stands unchanged:
> Make it single allocation

Did I indicate a similar design direction (for the preferred stack trace
convenience) after your constructive feedback?


> or leave one of those two messages in place.

Are there any more preferences involved?


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

Would anybody insist to know for which driver instance an allocation attempt
was performed?


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

Thanks for this clarification. - So I hope that your solution approach
will be also fine. Will it supersede my proposal?

Regards,
Markus