From: Nicholas Mc Guire <der.herr@hofr.at>
To: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: Andrew Lunn <andrew@lunn.ch>, Jason Cooper <jason@lakedaemon.net>,
linux-kernel@vger.kernel.org,
Russell King <linux@armlinux.org.uk>,
Nicholas Mc Guire <hofrat@osadl.org>,
linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH V2] ARM: mvebu: at least report the kzalloc failure
Date: Wed, 17 Apr 2019 14:13:09 +0200 [thread overview]
Message-ID: <20190417121309.GA20864@osadl.at> (raw)
In-Reply-To: <877ebsal7z.fsf@FE-laptop>
On Wed, Apr 17, 2019 at 02:07:44PM +0200, Gregory CLEMENT wrote:
> Hi Nicholas,
>
> Nicholas Mc Guire <der.herr@hofr.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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Mc Guire <der.herr@hofr.at>
To: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: Andrew Lunn <andrew@lunn.ch>, Jason Cooper <jason@lakedaemon.net>,
Russell King <linux@armlinux.org.uk>,
linux-kernel@vger.kernel.org,
Nicholas Mc Guire <hofrat@osadl.org>,
linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH V2] ARM: mvebu: at least report the kzalloc failure
Date: Wed, 17 Apr 2019 14:13:09 +0200 [thread overview]
Message-ID: <20190417121309.GA20864@osadl.at> (raw)
In-Reply-To: <877ebsal7z.fsf@FE-laptop>
On Wed, Apr 17, 2019 at 02:07:44PM +0200, Gregory CLEMENT wrote:
> Hi Nicholas,
>
> Nicholas Mc Guire <der.herr@hofr.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
next prev parent reply other threads:[~2019-04-17 12:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-16 3:56 [PATCH V2] ARM: mvebu: at least report the kzalloc failure Nicholas Mc Guire
2019-04-16 3:56 ` Nicholas Mc Guire
2019-04-16 13:39 ` Andrew Lunn
2019-04-16 13:39 ` Andrew Lunn
2019-04-17 11:42 ` Nicholas Mc Guire
2019-04-17 11:42 ` Nicholas Mc Guire
2019-04-17 12:07 ` Gregory CLEMENT
2019-04-17 12:07 ` Gregory CLEMENT
2019-04-17 12:13 ` Nicholas Mc Guire [this message]
2019-04-17 12:13 ` Nicholas Mc Guire
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190417121309.GA20864@osadl.at \
--to=der.herr@hofr.at \
--cc=andrew@lunn.ch \
--cc=gregory.clement@bootlin.com \
--cc=hofrat@osadl.org \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=sebastian.hesselbarth@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.