[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SA1PR18MB4709E390AC13A1EF5F652165A02AA@SA1PR18MB4709.namprd18.prod.outlook.com>
Date: Fri, 30 Jun 2023 05:19:27 +0000
From: Sai Krishna Gajula <saikrishnag@...vell.com>
To: Dan Carpenter <dan.carpenter@...aro.org>
CC: "davem@...emloft.net" <davem@...emloft.net>,
"edumazet@...gle.com" <edumazet@...gle.com>,
"kuba@...nel.org" <kuba@...nel.org>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Sunil Kovvuri Goutham <sgoutham@...vell.com>,
"maciej.fijalkowski@...el.com" <maciej.fijalkowski@...el.com>,
Naveen Mamindlapalli <naveenm@...vell.com>
Subject: Re: [net PATCH v2] octeontx2-af: Move validation of ptp pointer
before its usage
> -----Original Message-----
> From: Dan Carpenter <dan.carpenter@...aro.org>
> Sent: Friday, June 23, 2023 5:14 PM
> To: Sai Krishna Gajula <saikrishnag@...vell.com>
> Cc: davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> pabeni@...hat.com; netdev@...r.kernel.org; linux-
> kernel@...r.kernel.org; Sunil Kovvuri Goutham <sgoutham@...vell.com>;
> maciej.fijalkowski@...el.com; Naveen Mamindlapalli
> <naveenm@...vell.com>
> Subject: Re: [net PATCH v2] octeontx2-af: Move validation of ptp
> pointer before its usage
>
> On Fri, Jun 23, 2023 at 11:28:19AM +0000, Sai Krishna Gajula wrote:
> > > This probe function is super weird how it returns success on the failure
> path.
> > > One concern, I had initially was that if anything returns
> > > -EPROBE_DEFER then we cannot recover. That's not possible in the
> > > current code, but it makes me itch... But here is a different crash.
> > >
> >
> > In few circumstances, the PTP device is probed before the AF device in
> > the driver. In such instance, -EPROBE_DEFER is used.
> > -- EDEFER_PROBE is useful when probe order changes. Ex: AF driver probes
> before PTP.
> >
>
> You're describing how -EPROBE_DEFER is *supposed* to work. But that's not
> what this driver does.
>
> If the AF driver is probed before the PTP driver then ptp_probe() should
> return -EPROBE_DEFER and that would allow the kernel to automatically retry
> ptp_probe() later. But instead of that, ptp_probe() returns success. So I
> guess the user would have to manually rmmod it and insmod it again? So,
> what I'm saying I don't understand why we can't do this in the normal way.
>
> The other thing I'm saying is that the weird return success on error stuff
> hasn't been tested or we would have discovered the crash through testing.
>
> regards,
> dan carpenter
As suggested, we will return error in ptp_probe in case of any failure conditions. In this case AF driver continues without PTP support.
When the AF driver is probed before PTP driver , we will defer the AF probe. Hope these changes are inline with your view.
I will send a v3 patch with these changes.
Regards,
Sai
Powered by blists - more mailing lists