linux-kernel - Re: MIPS: Alchemy: Delete an error message for a failed memory allocation in alchemy_pci

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:   Thu, 25 May 2017 11:29:49 +0200
From:   Manuel Lauss <manuel.lauss@...il.com>
To:     SF Markus Elfring <elfring@...rs.sourceforge.net>
Cc:     Linux-MIPS <linux-mips@...ux-mips.org>,
        Paul Burton <paul.burton@...tec.com>,
        Ralf Bächle <ralf@...ux-mips.org>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: MIPS: Alchemy: Delete an error message for a failed memory
 allocation in alchemy_pci_probe()

On Thu, May 25, 2017 at 8:54 AM, SF Markus Elfring
<elfring@...rs.sourceforge.net> wrote:
>>> How do you think about to achieve a small code reduction also for this software module?
>>
>> Generally speaking, sure.
>
> Thanks for your interest in such a direction.
>
>
>> But why remove just this one?  Is it because it loosely follows a
>> pattern that was deemed removable in that slidedeck you linked to?
>
> I derived another source code search approach from the implementation
> of the check “OOM_MESSAGE” in the script “checkpatch.pl” for
> the semantic patch language (Coccinelle software).
> The involved search patterns are still evolving and the used lists
> (or regular expressions) for function names where it might make sense
> to reconsider the usage of special logging calls is therefore incomplete.
>
>
>> (the "usb_submit_urb()" part)?
>
> Would you like to extend the function selection for further considerations?
>
>
>>> Do you find information from a Linux allocation failure report sufficient
>>> for such a function implementation?
>>
>> Yes, I wrote that code, and in case this driver doesn't load, I'd like
>> to know precisely where initialization failed.
>> I can happily spare a few bytes for that.
>
> Does this kind of answer contain a bit of contradiction?
>
> * Why do you seem to insist on another message if information from a Linux
>   allocation failure report would be sufficient already also for this
>   software module?
>
> * Do you want that it can become easier to map a position in a backtrace
>   to a place in your source code?

Does kmalloc() nowadays print a message which invocation (source line) failed?
If so I won't be standing in your way, but if not, you need to come up with
something for convincing than answering questions with more questions.

Manuel