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 08:54:48 +0200
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Manuel Lauss <manuel.lauss@...il.com>, linux-mips@...ux-mips.org
Cc:     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()

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

Regards,
Markus