| Message ID | 20250328102403.2626974-4-m-malladi@ti.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Bug fixes from XDP and perout series | expand |
Meghana, On 28/03/2025 12:24, Meghana Malladi wrote: > ICSS IEP driver has flags to check if perout or pps has been enabled > at any given point of time. Whenever there is request to enable or > disable the signal, the driver first checks its enabled or disabled > and acts accordingly. > > After bringing the interface down and up, calling PPS/perout enable > doesn't work as the driver believes PPS is already enabled, How? aren't we calling icss_iep_pps_enable(iep, false)? wouldn't this disable the IEP and clear the iep->pps_enabled flag? And, what if you brought 2 interfaces of the same ICSS instances up but put only 1 interface down and up? > (iep->pps_enabled is not cleared during interface bring down) > and driver will just return true even though there is no signal. > Fix this by setting pps and perout flags to false instead of > disabling perout to avoid possible null pointer dereference. > > Fixes: 9b115361248d ("net: ti: icssg-prueth: Fix clearing of IEP_CMP_CFG registers during iep_init") > Reported-by: Dan Carpenter <dan.carpenter@linaro.org> > Closes: https://lore.kernel.org/all/7b1c7c36-363a-4085-b26c-4f210bee1df6@stanley.mountain/ > Signed-off-by: Meghana Malladi <m-malladi@ti.com> > --- > > Changes from v2(v3-v2): > - Add Reported-by tag and link to the bug reported by Dan Carpenter <dan.carpenter@linaro.org> > - drop calling icss_iep_perout_enable() for disabling perout and set perout to false instead > > drivers/net/ethernet/ti/icssg/icss_iep.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ethernet/ti/icssg/icss_iep.c b/drivers/net/ethernet/ti/icssg/icss_iep.c > index b4a34c57b7b4..b70e4c482d74 100644 > --- a/drivers/net/ethernet/ti/icssg/icss_iep.c > +++ b/drivers/net/ethernet/ti/icssg/icss_iep.c > @@ -820,9 +820,9 @@ int icss_iep_exit(struct icss_iep *iep) > icss_iep_disable(iep); > > if (iep->pps_enabled) > - icss_iep_pps_enable(iep, false); > + iep->pps_enabled = false; > else if (iep->perout_enabled) > - icss_iep_perout_enable(iep, NULL, false); > + iep->perout_enabled = false; > > return 0; > }
On 4/2/2025 5:58 PM, Roger Quadros wrote: > Meghana, > > On 28/03/2025 12:24, Meghana Malladi wrote: >> ICSS IEP driver has flags to check if perout or pps has been enabled >> at any given point of time. Whenever there is request to enable or >> disable the signal, the driver first checks its enabled or disabled >> and acts accordingly. >> >> After bringing the interface down and up, calling PPS/perout enable >> doesn't work as the driver believes PPS is already enabled, > > How? aren't we calling icss_iep_pps_enable(iep, false)? > wouldn't this disable the IEP and clear the iep->pps_enabled flag? > The whole purpose of calling icss_iep_pps_enable(iep, false) is to clear iep->pps_enabled flag, because if this flag is not cleared it hinders generating new pps signal (with the newly loaded firmware) once any of the interfaces are up (check icss_iep_perout_enable()), so instead of calling icss_iep_pps_enable(iep, false) I am just clearing the iep->pps_enabled flag. > And, what if you brought 2 interfaces of the same ICSS instances up > but put only 1 interface down and up? > Then the flag need not be disabled if only one interface is brought down because the IEP is still alive and all the IEP configuration (including pps/perout) is still valid. please refer for more details: https://lore.kernel.org/all/20241211135941.1800240-1-m-malladi@ti.com/ >> (iep->pps_enabled is not cleared during interface bring down) >> and driver will just return true even though there is no signal. >> Fix this by setting pps and perout flags to false instead of >> disabling perout to avoid possible null pointer dereference. >> >> Fixes: 9b115361248d ("net: ti: icssg-prueth: Fix clearing of IEP_CMP_CFG registers during iep_init") >> Reported-by: Dan Carpenter <dan.carpenter@linaro.org> >> Closes: https://lore.kernel.org/all/7b1c7c36-363a-4085-b26c-4f210bee1df6@stanley.mountain/ >> Signed-off-by: Meghana Malladi <m-malladi@ti.com> >> --- >> >> Changes from v2(v3-v2): >> - Add Reported-by tag and link to the bug reported by Dan Carpenter <dan.carpenter@linaro.org> >> - drop calling icss_iep_perout_enable() for disabling perout and set perout to false instead >> >> drivers/net/ethernet/ti/icssg/icss_iep.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/ethernet/ti/icssg/icss_iep.c b/drivers/net/ethernet/ti/icssg/icss_iep.c >> index b4a34c57b7b4..b70e4c482d74 100644 >> --- a/drivers/net/ethernet/ti/icssg/icss_iep.c >> +++ b/drivers/net/ethernet/ti/icssg/icss_iep.c >> @@ -820,9 +820,9 @@ int icss_iep_exit(struct icss_iep *iep) >> icss_iep_disable(iep); >> >> if (iep->pps_enabled) >> - icss_iep_pps_enable(iep, false); >> + iep->pps_enabled = false; >> else if (iep->perout_enabled) >> - icss_iep_perout_enable(iep, NULL, false); >> + iep->perout_enabled = false; >> >> return 0; >> } >
On 4/2/25 2:37 PM, Malladi, Meghana wrote: > On 4/2/2025 5:58 PM, Roger Quadros wrote: >> On 28/03/2025 12:24, Meghana Malladi wrote: >>> ICSS IEP driver has flags to check if perout or pps has been enabled >>> at any given point of time. Whenever there is request to enable or >>> disable the signal, the driver first checks its enabled or disabled >>> and acts accordingly. >>> >>> After bringing the interface down and up, calling PPS/perout enable >>> doesn't work as the driver believes PPS is already enabled, >> >> How? aren't we calling icss_iep_pps_enable(iep, false)? >> wouldn't this disable the IEP and clear the iep->pps_enabled flag? >> > > The whole purpose of calling icss_iep_pps_enable(iep, false) is to clear > iep->pps_enabled flag, because if this flag is not cleared it hinders > generating new pps signal (with the newly loaded firmware) once any of > the interfaces are up (check icss_iep_perout_enable()), so instead of > calling icss_iep_pps_enable(iep, false) I am just clearing the > iep->pps_enabled flag. IDK what Roger thinks, but the above is not clear to me. I read it as you are stating that icss_iep_pps_enable() indeed clears the flag, so i don't see/follow the reasoning behind this change. Skimmir over the code, icss_iep_pps_enable() could indeed avoid clearing the flag under some circumstances is that the reason? Possibly a more describing commit message would help. >> And, what if you brought 2 interfaces of the same ICSS instances up >> but put only 1 interface down and up? >> > > Then the flag need not be disabled if only one interface is brought down > because the IEP is still alive and all the IEP configuration (including > pps/perout) is still valid. I read the above as stating this fix is not correct in such scenario, leading to the wrong final state. I think it would be better to either give a better reasoning about this change in the commit message or refactor it to handle even such scenario, Thanks, Paolo
On 03/04/2025 14:25, Paolo Abeni wrote: > On 4/2/25 2:37 PM, Malladi, Meghana wrote: >> On 4/2/2025 5:58 PM, Roger Quadros wrote: >>> On 28/03/2025 12:24, Meghana Malladi wrote: >>>> ICSS IEP driver has flags to check if perout or pps has been enabled >>>> at any given point of time. Whenever there is request to enable or >>>> disable the signal, the driver first checks its enabled or disabled >>>> and acts accordingly. >>>> >>>> After bringing the interface down and up, calling PPS/perout enable >>>> doesn't work as the driver believes PPS is already enabled, >>> >>> How? aren't we calling icss_iep_pps_enable(iep, false)? >>> wouldn't this disable the IEP and clear the iep->pps_enabled flag? >>> >> >> The whole purpose of calling icss_iep_pps_enable(iep, false) is to clear >> iep->pps_enabled flag, because if this flag is not cleared it hinders >> generating new pps signal (with the newly loaded firmware) once any of >> the interfaces are up (check icss_iep_perout_enable()), so instead of >> calling icss_iep_pps_enable(iep, false) I am just clearing the >> iep->pps_enabled flag. > > IDK what Roger thinks, but the above is not clear to me. I read it as > you are stating that icss_iep_pps_enable() indeed clears the flag, so i > don't see/follow the reasoning behind this change. > > Skimmir over the code, icss_iep_pps_enable() could indeed avoid clearing > the flag under some circumstances is that the reason? > > Possibly a more describing commit message would help. I would expect that modifying the xxx_enabled flag should be done only in the icss_iep_xxx_enable() function. Doing it anywhere else will be difficult to track/debug in the long term. I don't see why the flag needs to be set anywhere else. Maye better to improve logic inside icss_iep_pps_enable() like Paolo suggests. > >>> And, what if you brought 2 interfaces of the same ICSS instances up >>> but put only 1 interface down and up? >>> >> >> Then the flag need not be disabled if only one interface is brought down >> because the IEP is still alive and all the IEP configuration (including >> pps/perout) is still valid. > > I read the above as stating this fix is not correct in such scenario, > leading to the wrong final state. > > I think it would be better to either give a better reasoning about this > change in the commit message or refactor it to handle even such scenario, > > Thanks, > > Paolo >
On 4/3/2025 4:55 PM, Paolo Abeni wrote: > On 4/2/25 2: 37 PM, Malladi, Meghana wrote: > On 4/2/2025 5: 58 PM, > Roger Quadros wrote: >> On 28/03/2025 12: 24, Meghana Malladi wrote: >>> > ICSS IEP driver has flags to check if perout or pps has been enabled >>> at > ZjQcmQRYFpfptBannerStart > This message was sent from outside of Texas Instruments. > Do not click links or open attachments unless you recognize the source > of this email and know the content is safe. > Report Suspicious > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK! > updqndalvOwRqgXOXDPJf9wy4vKojW68gavBCIsz5DlBLvSeawwT53qgFGcvIm0ULRBQkJv028AcR194Ei9ZDPp5ily-uAw$> > ZjQcmQRYFpfptBannerEnd > > On 4/2/25 2:37 PM, Malladi, Meghana wrote: >> On 4/2/2025 5:58 PM, Roger Quadros wrote: >>> On 28/03/2025 12:24, Meghana Malladi wrote: >>>> ICSS IEP driver has flags to check if perout or pps has been enabled >>>> at any given point of time. Whenever there is request to enable or >>>> disable the signal, the driver first checks its enabled or disabled >>>> and acts accordingly. >>>> >>>> After bringing the interface down and up, calling PPS/perout enable >>>> doesn't work as the driver believes PPS is already enabled, >>> >>> How? aren't we calling icss_iep_pps_enable(iep, false)? >>> wouldn't this disable the IEP and clear the iep->pps_enabled flag? >>> >> >> The whole purpose of calling icss_iep_pps_enable(iep, false) is to clear >> iep->pps_enabled flag, because if this flag is not cleared it hinders >> generating new pps signal (with the newly loaded firmware) once any of >> the interfaces are up (check icss_iep_perout_enable()), so instead of >> calling icss_iep_pps_enable(iep, false) I am just clearing the >> iep->pps_enabled flag. > > IDK what Roger thinks, but the above is not clear to me. I read it as > you are stating that icss_iep_pps_enable() indeed clears the flag, so i > don't see/follow the reasoning behind this change. > The reason behind this change is to fix the possible null pointer dereference which will occur when icss_iep_perout_enable(iep, NULL, false) is called during icss_iep_exit(), my bad for not mentioning it clearly in the commit message. > Skimmir over the code, icss_iep_pps_enable() could indeed avoid clearing > the flag under some circumstances is that the reason? > icss_iep_pps_enable() does indeed clear the flag, but icss_iep_perout_enable() doesn't due to the null pointer dereference. So instead of calling these functions for clearing the flag, we can simply just clear the flag directly. > Possibly a more describing commit message would help. > Yes agreed. I will update it for v4. >>> And, what if you brought 2 interfaces of the same ICSS instances up >>> but put only 1 interface down and up? >>> >> >> Then the flag need not be disabled if only one interface is brought down >> because the IEP is still alive and all the IEP configuration (including >> pps/perout) is still valid. > > I read the above as stating this fix is not correct in such scenario, > leading to the wrong final state. > No it is the correct scenario. When you bring down all the existing interfaces (be it one or two, when whatever is up goes down) you unload the existing firmware and clear the all the driver configuration (this flag also needs to be cleared) to ensure everything starts with a clean state. > I think it would be better to either give a better reasoning about this > change in the commit message or refactor it to handle even such scenario, > > Thanks, > > Paolo >
Hi Roger, On 4/4/2025 1:17 PM, Roger Quadros wrote: > > > On 03/04/2025 14:25, Paolo Abeni wrote: >> On 4/2/25 2:37 PM, Malladi, Meghana wrote: >>> On 4/2/2025 5:58 PM, Roger Quadros wrote: >>>> On 28/03/2025 12:24, Meghana Malladi wrote: >>>>> ICSS IEP driver has flags to check if perout or pps has been enabled >>>>> at any given point of time. Whenever there is request to enable or >>>>> disable the signal, the driver first checks its enabled or disabled >>>>> and acts accordingly. >>>>> >>>>> After bringing the interface down and up, calling PPS/perout enable >>>>> doesn't work as the driver believes PPS is already enabled, >>>> >>>> How? aren't we calling icss_iep_pps_enable(iep, false)? >>>> wouldn't this disable the IEP and clear the iep->pps_enabled flag? >>>> >>> >>> The whole purpose of calling icss_iep_pps_enable(iep, false) is to clear >>> iep->pps_enabled flag, because if this flag is not cleared it hinders >>> generating new pps signal (with the newly loaded firmware) once any of >>> the interfaces are up (check icss_iep_perout_enable()), so instead of >>> calling icss_iep_pps_enable(iep, false) I am just clearing the >>> iep->pps_enabled flag. >> >> IDK what Roger thinks, but the above is not clear to me. I read it as >> you are stating that icss_iep_pps_enable() indeed clears the flag, so i >> don't see/follow the reasoning behind this change. >> >> Skimmir over the code, icss_iep_pps_enable() could indeed avoid clearing >> the flag under some circumstances is that the reason? >> >> Possibly a more describing commit message would help. > > I would expect that modifying the xxx_enabled flag should be done only > in the icss_iep_xxx_enable() function. Doing it anywhere else will be difficult > to track/debug in the long term. > There is no problem with calling icss_iep_pps_enable() for clearing the pps_enable flag. Problem comes with icss_iep_perout_enable(), causing null pointer dereference for the NULL perout request argument we are passing just for clearing the perout_enable flag. > I don't see why the flag needs to be set anywhere else. Maye better to > improve logic inside icss_iep_pps_enable() like Paolo suggests. > Ok, one thing I can do is create a ptp_perout_request to disable perout instead of passing NULL to icss_iep_perout_enable(). What are your thoughts on this ? >> >>>> And, what if you brought 2 interfaces of the same ICSS instances up >>>> but put only 1 interface down and up? >>>> >>> >>> Then the flag need not be disabled if only one interface is brought down >>> because the IEP is still alive and all the IEP configuration (including >>> pps/perout) is still valid. >> >> I read the above as stating this fix is not correct in such scenario, >> leading to the wrong final state. >> >> I think it would be better to either give a better reasoning about this >> change in the commit message or refactor it to handle even such scenario, >> >> Thanks, >> >> Paolo >> >
diff --git a/drivers/net/ethernet/ti/icssg/icss_iep.c b/drivers/net/ethernet/ti/icssg/icss_iep.c index b4a34c57b7b4..b70e4c482d74 100644 --- a/drivers/net/ethernet/ti/icssg/icss_iep.c +++ b/drivers/net/ethernet/ti/icssg/icss_iep.c @@ -820,9 +820,9 @@ int icss_iep_exit(struct icss_iep *iep) icss_iep_disable(iep); if (iep->pps_enabled) - icss_iep_pps_enable(iep, false); + iep->pps_enabled = false; else if (iep->perout_enabled) - icss_iep_perout_enable(iep, NULL, false); + iep->perout_enabled = false; return 0; }
ICSS IEP driver has flags to check if perout or pps has been enabled at any given point of time. Whenever there is request to enable or disable the signal, the driver first checks its enabled or disabled and acts accordingly. After bringing the interface down and up, calling PPS/perout enable doesn't work as the driver believes PPS is already enabled, (iep->pps_enabled is not cleared during interface bring down) and driver will just return true even though there is no signal. Fix this by setting pps and perout flags to false instead of disabling perout to avoid possible null pointer dereference. Fixes: 9b115361248d ("net: ti: icssg-prueth: Fix clearing of IEP_CMP_CFG registers during iep_init") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/7b1c7c36-363a-4085-b26c-4f210bee1df6@stanley.mountain/ Signed-off-by: Meghana Malladi <m-malladi@ti.com> --- Changes from v2(v3-v2): - Add Reported-by tag and link to the bug reported by Dan Carpenter <dan.carpenter@linaro.org> - drop calling icss_iep_perout_enable() for disabling perout and set perout to false instead drivers/net/ethernet/ti/icssg/icss_iep.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)