From: David Daney <ddaney.cavm@gmail.com>
To: David Miller <davem@davemloft.net>, arvind.yadav.cs@gmail.com
Cc: peter.chen@nxp.com, fw@strlen.de, david.daney@cavium.com,
f.fainelli@gmail.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [v3] net: ethernet: cavium: octeon: octeon_mgmt: Handle return NULL error from devm_ioremap
Date: Mon, 19 Dec 2016 13:37:35 -0800 [thread overview]
Message-ID: <49c07a34-ad57-518f-66f5-2a4f70f6a095@gmail.com> (raw)
In-Reply-To: <20161219.110420.1570801461162159172.davem@davemloft.net>
On 12/19/2016 08:04 AM, David Miller wrote:
> From: Arvind Yadav <arvind.yadav.cs@gmail.com>
> Date: Thu, 15 Dec 2016 00:33:30 +0530
>
>> Here, If devm_ioremap will fail. It will return NULL.
>> Kernel can run into a NULL-pointer dereference.
>> This error check will avoid NULL pointer dereference.
>>
>> Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
>
> Since ioremap() is in fact designed to possibly fail, we do
> need to always check it's return value. So this change is
> correct and I have applied it to the 'net' tree.
Yes, I think that is fine, although I have not tested the patch.
In general I like to know if a patch fixes a problem that has occurred
on a platform used by the patch author, or if the author just noticed an
issue through code inspection or automated tool for a platform that they
cannot test on.
This patch appears to fall into the second category, but attempts to
determine this for sure were for the most part unsuccessful.
With respect to ioremap(), in general I agree that it is designed to
possibly fail. For mips64 however, I think the implementation can never
fail. Certainly testing for failure fits better with what we expect to
see in Linux kernel code.
>
> Thanks.
>
prev parent reply other threads:[~2016-12-19 21:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-14 19:03 [v3] net: ethernet: cavium: octeon: octeon_mgmt: Handle return NULL error from devm_ioremap Arvind Yadav
2016-12-14 19:28 ` David Daney
2016-12-15 15:00 ` arvind Yadav
2016-12-19 16:04 ` David Miller
2016-12-19 21:37 ` David Daney [this message]
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=49c07a34-ad57-518f-66f5-2a4f70f6a095@gmail.com \
--to=ddaney.cavm@gmail.com \
--cc=arvind.yadav.cs@gmail.com \
--cc=davem@davemloft.net \
--cc=david.daney@cavium.com \
--cc=f.fainelli@gmail.com \
--cc=fw@strlen.de \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peter.chen@nxp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).