netdev - RE: [PATCH v5 net-next 2/2] net: phy: micrel: Fix warn: passing zero to PTR

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CO1PR11MB4771F8AA1CCAD01EAE797E59E2E29@CO1PR11MB4771.namprd11.prod.outlook.com>
Date:   Mon, 12 Dec 2022 08:34:44 +0000
From:   <Divya.Koppera@...rochip.com>
To:     <andrew@...n.ch>
CC:     <hkallweit1@...il.com>, <linux@...linux.org.uk>,
        <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
        <pabeni@...hat.com>, <netdev@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <richardcochran@...il.com>,
        <UNGLinuxDriver@...rochip.com>
Subject: RE: [PATCH v5 net-next 2/2] net: phy: micrel: Fix warn: passing zero
 to PTR_ERR

Hi Andrew,

> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Tuesday, December 6, 2022 7:39 PM
> To: Divya Koppera - I30481 <Divya.Koppera@...rochip.com>
> Cc: hkallweit1@...il.com; linux@...linux.org.uk; davem@...emloft.net;
> edumazet@...gle.com; kuba@...nel.org; pabeni@...hat.com;
> netdev@...r.kernel.org; linux-kernel@...r.kernel.org;
> richardcochran@...il.com; UNGLinuxDriver
> <UNGLinuxDriver@...rochip.com>
> Subject: Re: [PATCH v5 net-next 2/2] net: phy: micrel: Fix warn: passing zero
> to PTR_ERR
> 
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
> 
> > > > -     if (!IS_ENABLED(CONFIG_PTP_1588_CLOCK) ||
> > > > -         !IS_ENABLED(CONFIG_NETWORK_PHY_TIMESTAMPING))
> > > > -             return 0;
> > > > -
> > >
> > > Why are you removing this ?
> > >
> >
> > I got review comment from Richard in v2 as below, making it as consistent
> by checking ptp_clock. So removed it in next revision.
> >
> > " > static int lan8814_ptp_probe_once(struct phy_device *phydev)
> > > {
> > >         struct lan8814_shared_priv *shared = phydev->shared->priv;
> > >
> > >         if (!IS_ENABLED(CONFIG_PTP_1588_CLOCK) ||
> > >             !IS_ENABLED(CONFIG_NETWORK_PHY_TIMESTAMPING))
> > >                 return 0;
> >
> > It is weird to use macros here, but not before calling ptp_clock_register.
> > Make it consistent by checking shared->ptp_clock instead.
> > That is also better form."
> 
> O.K. If Richard said this fine.
> 
> Just out of interest, could you disassemble lan8814_ptp_probe_once() when
> CONFIG_PTP_1588_CLOCK is disabled, with and without this check?
> 

If I understand correctly,

With (!IS_ENABLED(CONFIG_PTP_1588_CLOCK) check, initialization of mutex and members of shared->ptp_clock_info need to be done in first function.
Without above check ptp_clock_register should be done in second function. Correct me if I'm wrong.

In this case, if first function is bypassed because of clock disable config, no need to go to second function. Could you please check below solution, if that works fine?

> My guess is, when PTP is disabled, the mutex still gets initialised, all the
> member of shared->ptp_clock_info are set. The optimise cannot remove it.
> With the macro check, the function is empty. So you end up with a slightly
> bigger text size.
> 

If that is the case, I'll keep the CONFIG_PTP_1588_CLOCK disabled check before calling lan8814_ptp_probe_once.

Next thing is if CONFIG_PTP_1588_CLOCK disabled check pass then ptp_clock_register will never return null because we are bypassing hardware clock check before calling function itself.
So, I can remove ptp_clock null check too. Let me know if this works, I'll do changes in next revision.

>        Andrew