linux-kernel - Re: [PATCH V2] ARM: mvebu: at least report the kzalloc failure

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]

Date:   Wed, 17 Apr 2019 14:13:09 +0200
From:   Nicholas Mc Guire <der.herr@...r.at>
To:     Gregory CLEMENT <gregory.clement@...tlin.com>
Cc:     Andrew Lunn <andrew@...n.ch>, Jason Cooper <jason@...edaemon.net>,
        Russell King <linux@...linux.org.uk>,
        linux-kernel@...r.kernel.org, Nicholas Mc Guire <hofrat@...dl.org>,
        linux-arm-kernel@...ts.infradead.org,
        Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Subject: Re: [PATCH V2] ARM: mvebu: at least report the kzalloc failure

On Wed, Apr 17, 2019 at 02:07:44PM +0200, Gregory CLEMENT wrote:
> Hi Nicholas,
> 
> Nicholas Mc Guire <der.herr@...r.at> writes:
> 
> > On Tue, Apr 16, 2019 at 03:39:57PM +0200, Andrew Lunn wrote:
> >> On Tue, Apr 16, 2019 at 05:56:31AM +0200, Nicholas Mc Guire wrote:
> >> 
> >> > Note that this will trigger a checkpatch WARNING
> >> > "WARNING: Possible unnecessary 'out of memory' message"
> >> > but comparing the oops with an without the one-line pr_err I would
> >> > argue that it makes sense to include it:
> >> 
> >> Hi Nicholas
> >> 
> >> It might be worth adding this as a comment, so that newbies don't
> >> submit patches removing the pr_err() because of the checkpatch
> >> warning.
> >>
> > hmm... I think if we start doing that we would make quite a mess of
> > documentation in the kernel. Also note its a warning stating "possible 
> > unneceessary" - so I would not see the necessity.
> >
> > At most I would include a note on this in the commit message so that
> > anyone checking the origin would see that this is intenttional - assuming
> > that people modifying code would be using git blame to locate the
> > origin of any code...
> 
> Don't bother to send a new version I don't attempt to take this
> patch. As you pointed it is very unlikely that we get an error so early
> during the boot for a very small amount of memory.
> 
> If it happened then we have serious trouble and the message provided by
> the BUG() call will be more than enough.
>
yup - its a corner case - I'm trying to filter out those
cases that are actually in __init function returning void - as
those cases are, it seems, are generally cases where k{m,z}allocs
will not have explicit checking.

thx!
hofrat