lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 4 Jun 2021 12:56:06 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Stephen Rothwell <sfr@...b.auug.org.au>
CC:     David Miller <davem@...emloft.net>,
        Networking <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Pankaj Dubey <pankaj.dubey@...sung.com>,
        Sriranjani P <sriranjani.p@...sung.com>
Subject: Re: linux-next: manual merge of the net-next tree with the net tree

Hi Stephen,

On Fri, Jun 04, 2021 at 11:28:25AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
>   drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>
> between commit:
>
>   593f555fbc60 ("net: stmmac: fix kernel panic due to NULL pointer dereference of mdio_bus_data")
>
> from the net tree and commit:
>
>   11059740e616 ("net: pcs: xpcs: convert to phylink_pcs_ops")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index c87202cbd3d6,6d41dd6f9f7a..000000000000
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@@ -1240,9 -1222,7 +1222,9 @@@ static int stmmac_phy_setup(struct stmm
>   	priv->phylink_config.dev = &priv->dev->dev;
>   	priv->phylink_config.type = PHYLINK_NETDEV;
>   	priv->phylink_config.pcs_poll = true;
> - 	if (priv->plat->mdio_bus_data)
>  -	priv->phylink_config.ovr_an_inband = mdio_bus_data->xpcs_an_inband;
> ++	if (mdio_bus_data)
>  +		priv->phylink_config.ovr_an_inband =
> - 			priv->plat->mdio_bus_data->xpcs_an_inband;
> ++			mdio_bus_data->xpcs_an_inband;
>
>   	if (!fwnode)
>   		fwnode = dev_fwnode(priv->device);

Your conflict resolution looks fine. I touched that area minimally (only
to keep priv->plat_mdio_bus_data in a variable), it should still be
checked against NULL.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ