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] [day] [month] [year] [list]
Message-ID: <21554e23-e714-3f6f-cd70-4c277823bab3@users.sourceforge.net>
Date:   Sun, 3 Dec 2017 19:20:47 +0100
From:   SF Markus Elfring <elfring@...rs.sourceforge.net>
To:     Joe Perches <joe@...ches.com>, linux-omap@...r.kernel.org,
        linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-doc@...r.kernel.org
Cc:     "Andrew F. Davis" <afd@...com>,
        Arvind Yadav <arvind.yadav.cs@...il.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        LKML <linux-kernel@...r.kernel.org>,
        kernel-janitors@...r.kernel.org,
        Ladislav Michl <ladis@...ux-mips.org>,
        Tomi Valkeinen <tomi.valkeinen@...com>
Subject: Re: omapfb/dss: Delete an error message for a failed memory
 allocation in three functions

> How many times have I told you to include the reason for your patches
> in your proposed commit message?

Will it be useful to look again at the involved circumstances?


> Too often.

Did I answer any concerns partly?


> Many people do not know that a generic kmalloc does a dump_stack() on OOM.

Do you see a need to represent such information better?

Is it expected that the function “devm_kzalloc” has got a similar property?


> That information should be part of the commit message.

How do you think about to share it also from any reference documentation
in a clearer way?

Do we stumble on a target conflict in this case?

I am generally trying to improve the software situation to some degree.
I prefer then to work with safe information sources.
Unfortunately, I might have not reached a desired confidence level here
for a more detailed commit message. I assume that software development
efforts could increase in significant ways if something should be improved
further in a direction I hope. But this could mean that time frames will
grow for corresponding clarifications.

* Does such a situation block progress on the deletion of other remaining
  questionable error messages?

* Would you like to increase the software development attention anyhow?



By the way:
It seems that my update suggestion for the directory “omapfb/dss”
could be superseded by the patch “omapfb: dss: Do not duplicate features data”
from Ladislav Michl.
https://patchwork.kernel.org/patch/10082027/
https://lkml.kernel.org/r/<20171129123308.GA26578@...och>

Regards,
Markus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ