All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benedikt Spranger <b.spranger@linutronix.de>
To: Roger Quadros <rogerq@kernel.org>
Cc: netdev@vger.kernel.org, MD Danish Anwar <danishanwar@ti.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>
Subject: Re: [PATCH] net: ti: icssg-prueth: Check return value to avoid a kernel oops
Date: Tue, 25 Mar 2025 11:46:11 +0100	[thread overview]
Message-ID: <20250325114611.4ac846b6@mitra> (raw)
In-Reply-To: <3bd78b6a-3c6d-4130-b086-36f2f728bc3e@kernel.org>

On Mon, 24 Mar 2025 16:44:20 +0200
Roger Quadros <rogerq@kernel.org> wrote:

> On 23/03/2025 17:18, Benedikt Spranger wrote:
> > On Sun, 23 Mar 2025 09:19:35 +0200
> > Roger Quadros <rogerq@kernel.org> wrote:
> >   
> >> Did you actually get a kernel oops?  
> > Yes. And I would like to attach the kernel output, but I do not have
> > access to the board ATM.
> >   
> >> If yes, which part of code produces the oops.  
> > I get an NULL pointer dereference in is_multicast_ether_addr().
> > It happens here:
> > 
> >     u32 a = *(const u32 *)addr;  
> 
> But this should not happen. Because ndev->addr (pointer) should not
> be zero. Driver allocated ndev with alloc_etherdev_mq() which
> allocates memory for ndev->addr using dev_addr_init(dev)).
Emphasis on *should* :)
OK, got your point. Dig deeper into that.

> >> Even if it fails we do set a random MAC address and do not return
> >> error. So above statement is false.  
> > I doubt that. of_get_ethdev_address() do not set a random MAC
> > address in case of a failure. It simply returns -ENODEV. Since
> > is_valid_ether_addr() fails with a NULL pointer dereference in
> > is_multicast_ether_addr() on the other hand, no random MAC address
> > is set.   
> 
> What I meant was we set random address using eth_hw_addr_random().
But that happens after the failing check. So evaluating the return of
of_get_ethdev_address() seem to be a good thing in the first place.

I my understanding (for now) it is nessesary to check both: the return
of of_get_ethdev_address() *and* !is_valid_ether_addr(). If any of these
checks fail eth_hw_addr_random() should be called and therefore a
random MAC address be set.

Regards
    Bene

      reply	other threads:[~2025-03-25 10:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-22 14:33 [PATCH] net: ti: icssg-prueth: Check return value to avoid a kernel oops Benedikt Spranger
2025-03-23  7:19 ` Roger Quadros
2025-03-23 15:18   ` Benedikt Spranger
2025-03-24 14:44     ` Roger Quadros
2025-03-25 10:46       ` Benedikt Spranger [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=20250325114611.4ac846b6@mitra \
    --to=b.spranger@linutronix.de \
    --cc=andrew+netdev@lunn.ch \
    --cc=danishanwar@ti.com \
    --cc=netdev@vger.kernel.org \
    --cc=rogerq@kernel.org \
    /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.