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!