linux-kernel - Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

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:   Tue, 28 Nov 2017 19:09:11 +0100
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Ladislav Michl <ladis@...ux-mips.org>, linux-omap@...r.kernel.org,
        linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org
Cc:     Julia Lawall <julia.lawall@...6.fr>, Joe Perches <joe@...ches.com>,
        "Andrew F. Davis" <afd@...com>,
        Arvind Yadav <arvind.yadav.cs@...il.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org
Subject: Re: omapfb/dss: Delete an error message for a failed memory
 allocation in three functions

>> Additional improvement possibilities can be taken into account
>> after corresponding software development discussions, can't they?
> 
> Sure, but that is in contrary to all you replies.

Where do you see a contradiction in this case?


> I guess you are familiar with Documentation/process/submitting-patches.rst chapter 8.

I hope so in principle.


> No matter that patch was generated or suggested by a tool, you sent
> it and normal review procedure follows.

This is generally fine.


> And here you ignored _all_ suggestions

I did not integrate a few of them for my commit message so far
because it seems that there are open issues for further clarification.

Do you want that I send a second approach for this software module
before your own evolving update suggestion?


> and concentrate solely on improving Coccinelle scripts.

I hope not.


> On kernel related lists suggestions to patch itself are discussed.

This is usual.


> Whenever you take them into account while developing Coccinelle
> is up to you (on the Cocci list).

This is also happening, isn't it?

Regards,
Markus