| Message ID | 1433580066-1237-1-git-send-email-hofrat@osadl.org |
|---|---|
| State | Superseded, archived |
| Delegated to: | David Miller |
| Headers | show |
From: Nicholas Mc Guire <hofrat@osadl.org> Date: Sat, 6 Jun 2015 10:41:06 +0200 > API compliance scanning with coccinelle flagged: > ./drivers/net/wan/dscc4.c:1036:1-33: > WARNING: timeout (10) seems HZ dependent > ./drivers/net/wan/dscc4.c:554:2-34: > WARNING: timeout (10) seems HZ dependent > ./drivers/net/wan/dscc4.c:599:2-34: > WARNING: timeout (10) seems HZ dependent > > Numeric constants passed to schedule_timeout_*() make the effective > timeout HZ dependent which does not seem to be the intent here. > Fixed up by converting the constant to jiffies with msecs_to_jiffies() > > Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org> Whoever wrote these things probably wanted whatever this amounts to when HZ=100, so that is the only valid transformation you can make to fix this up here. Otherwise you seriously risk breaking the driver. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 07 Jun 2015, David Miller wrote: > From: Nicholas Mc Guire <hofrat@osadl.org> > Date: Sat, 6 Jun 2015 10:41:06 +0200 > > > API compliance scanning with coccinelle flagged: > > ./drivers/net/wan/dscc4.c:1036:1-33: > > WARNING: timeout (10) seems HZ dependent > > ./drivers/net/wan/dscc4.c:554:2-34: > > WARNING: timeout (10) seems HZ dependent > > ./drivers/net/wan/dscc4.c:599:2-34: > > WARNING: timeout (10) seems HZ dependent > > > > Numeric constants passed to schedule_timeout_*() make the effective > > timeout HZ dependent which does not seem to be the intent here. > > Fixed up by converting the constant to jiffies with msecs_to_jiffies() > > > > Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org> > > Whoever wrote these things probably wanted whatever this amounts > to when HZ=100, so that is the only valid transformation you can > make to fix this up here. > > Otherwise you seriously risk breaking the driver. I did not find dscc4 in the 2.2 series of kernels so it does not predate configurable HZ - or do you mean simply that increasing the timeout here should be side-effect free and thus the larger of the values should be taken ? - though that would imply that it is possibly now broken for HZ=1000. Will fix it up to 10 == 100ms and fix the patch documentation. thx! hofrat -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller <davem@davemloft.net> : [...] > Whoever wrote these things probably wanted whatever this amounts > to when HZ=100, so that is the only valid transformation you can > make to fix this up here. It's linux kernel illiterate style from 13 years ago but I commented dscc4_pci_reset. wait_ack_cec and xpr_ack are dumb busy loops that break on short integer sign change. Hackish hint. > Otherwise you seriously risk breaking the driver. How seriously is hard to tell. I've never tried it at really low line rates though. Please apply. Thanks.
diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c index 0822356..2ce5249 100644 --- a/drivers/net/wan/dscc4.c +++ b/drivers/net/wan/dscc4.c @@ -551,7 +551,7 @@ static int dscc4_wait_ack_cec(struct dscc4_dev_priv *dpriv, msg, i); goto done; } - schedule_timeout_uninterruptible(10); + schedule_timeout_uninterruptible(msecs_to_jiffies(10)); rmb(); } while (++i > 0); netdev_err(dev, "%s timeout\n", msg); @@ -596,7 +596,7 @@ static inline int dscc4_xpr_ack(struct dscc4_dev_priv *dpriv) (dpriv->iqtx[cur] & cpu_to_le32(Xpr))) break; smp_rmb(); - schedule_timeout_uninterruptible(10); + schedule_timeout_uninterruptible(msecs_to_jiffies(10)); } while (++i > 0); return (i >= 0 ) ? i : -EAGAIN; @@ -1033,7 +1033,7 @@ static void dscc4_pci_reset(struct pci_dev *pdev, void __iomem *ioaddr) /* Flush posted writes */ readl(ioaddr + GSTAR); - schedule_timeout_uninterruptible(10); + schedule_timeout_uninterruptible(msecs_to_jiffies(10)); for (i = 0; i < 16; i++) pci_write_config_dword(pdev, i << 2, dscc4_pci_config_store[i]);
API compliance scanning with coccinelle flagged: ./drivers/net/wan/dscc4.c:1036:1-33: WARNING: timeout (10) seems HZ dependent ./drivers/net/wan/dscc4.c:554:2-34: WARNING: timeout (10) seems HZ dependent ./drivers/net/wan/dscc4.c:599:2-34: WARNING: timeout (10) seems HZ dependent Numeric constants passed to schedule_timeout_*() make the effective timeout HZ dependent which does not seem to be the intent here. Fixed up by converting the constant to jiffies with msecs_to_jiffies() Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org> --- As the intended timeout is not documented and msecs_to_jiffies(10) may be a factor 10 off from constant 10, this needs to be checked by someone that knows the details of this driver, in any case it should be passed in a HZ independent way. Patch was compile tested with x86_64_defconfig + CONFIG_WAN=y CONFIG_HDLC=m, CONFIG_DSCC4=m Patch is against 4.1-rc6 (localversion-next is -next-20150605) drivers/net/wan/dscc4.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)