On Mon, 21 Dec 2020 18:30:32 +0000 Russell King - ARM Linux admin wrote:
> On Mon, Dec 21, 2020 at 10:25:39AM -0800, Jakub Kicinski wrote:
> > We need to work with stable maintainers on this, let's see..
> >
> > Greg asked for a clear description of what happens, from your
> > previous response it sounds like a null-deref in mvpp2_mac_config().
> > Is the netdev -> config -> netdev linking not ready by the time
> > mvpp2_mac_config() is called?
>
> We are going round in circles, so nothing is going to happen.
>
> I stated in detail in one of my emails on the 10th December why the
> problem occurs. So, Greg has the description already. There is no
> need to repeat it.
>
> Can we please move forward with this?
Well, the fact it wasn't quoted in Marcin's reply and that I didn't
spot it when scanning the 30 email thread should be a clear enough
indication whether pinging threads is a good strategy..
A clear, fresh backport request would had been much more successful
and easier for Greg to process. If you still don't see a reply in
2 weeks, please just do that.
In case Greg is in fact reading this:
Greg, can we backport:
6c2b49eb9671 ("net: mvpp2: add mvpp2_phylink_to_port() helper")
to 5.4? Quoting Russell:
The problem is that mvpp2_acpi_start() passes an un-initialised
(zeroed) port->phylink_config, as phylink is not used in ACPI setups.
Crash occurs because port->phylink_config.dev (which is a NULL pointer
in this instance) is passed to to_net_dev():
#define to_net_dev(d) container_of(d, struct net_device, dev)
Which then means netdev_priv(dev) attempts to dereference a not-quite
NULL pointer, leading to an oops.
Folks here are willing to provide a more cut down fix if necessary.
Thanks!
