[Intel-wired-lan] [PATCH] i40e: fix i40e_ptp_adjtime when given a negative delta

[Intel-wired-lan] [PATCH] i40e: fix i40e_ptp_adjtime when given a negative delta

[Jacob Keller]

Commit 0ac30ce43323 ("i40e: fix up 32 bit timespec references",
2017-07-26) claims to be cleaning up references to 32-bit timespecs.

The actual contents of the commit make no sense, as it converts a call
to timespec64_add into timespec64_add_ns. This would seem ok, if (a) the
change was documented in the commit message, and (b) timespec64_add_ns
supported negative numbers.

timespec64_add_ns doesn't work with signed deltas, because the
implementation is based around iter_div_u64_rem. This change resulted in
a regression where i40e_ptp_adjtime would interpret small negative
adjustments as large positive additions, resulting in incorrect
behavior.

This commit doesn't appear to fix anything, is not well explained, and
introduces a bug, so lets just revert it.

Reverts: 0ac30ce43323 ("i40e: fix up 32 bit timespec references", 2017-07-26)
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
 drivers/net/ethernet/intel/i40e/i40e_ptp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_ptp.c b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
index 66147c3f5f2c..439c35f0c581 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ptp.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ptp.c
@@ -146,12 +146,13 @@ static int i40e_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
 static int i40e_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
 {
 	struct i40e_pf *pf = container_of(ptp, struct i40e_pf, ptp_caps);
-	struct timespec64 now;
+	struct timespec64 now, then;
 
+	then = ns_to_timespec64(delta);
 	mutex_lock(&pf->tmreg_lock);
 
 	i40e_ptp_read(pf, &now, NULL);
-	timespec64_add_ns(&now, delta);
+	now = timespec64_add(now, then);
 	i40e_ptp_write(pf, (const struct timespec64 *)&now);
 
 	mutex_unlock(&pf->tmreg_lock);
-- 
2.18.0.219.gaf81d287a9da

[Intel-wired-lan] [PATCH] i40e: fix i40e_ptp_adjtime when given a negative delta

[Arnd Bergmann]

On Mon, Feb 25, 2019 at 8:20 PM Jacob Keller <jacob.e.keller@intel.com> wrote:
>
> Commit 0ac30ce43323 ("i40e: fix up 32 bit timespec references",
> 2017-07-26) claims to be cleaning up references to 32-bit timespecs.
>
> The actual contents of the commit make no sense, as it converts a call
> to timespec64_add into timespec64_add_ns. This would seem ok, if (a) the
> change was documented in the commit message, and (b) timespec64_add_ns
> supported negative numbers.
>
> timespec64_add_ns doesn't work with signed deltas, because the
> implementation is based around iter_div_u64_rem. This change resulted in
> a regression where i40e_ptp_adjtime would interpret small negative
> adjustments as large positive additions, resulting in incorrect
> behavior.
>
> This commit doesn't appear to fix anything, is not well explained, and
> introduces a bug, so lets just revert it.

Ah, this is not the bug I was referring to but actually worse.
I was only worried about hogging the CPU while doing billions
of additions in a loop, and had not realized it also changes
the result.

> Reverts: 0ac30ce43323 ("i40e: fix up 32 bit timespec references", 2017-07-26)
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

[Intel-wired-lan] [PATCH] i40e: fix i40e_ptp_adjtime when given a negative delta

[Keller, Jacob E]

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Monday, February 25, 2019 11:47 AM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>
> Subject: Re: [PATCH] i40e: fix i40e_ptp_adjtime when given a negative delta
> 
> On Mon, Feb 25, 2019 at 8:20 PM Jacob Keller <jacob.e.keller@intel.com> wrote:
> >
> > Commit 0ac30ce43323 ("i40e: fix up 32 bit timespec references",
> > 2017-07-26) claims to be cleaning up references to 32-bit timespecs.
> >
> > The actual contents of the commit make no sense, as it converts a call
> > to timespec64_add into timespec64_add_ns. This would seem ok, if (a) the
> > change was documented in the commit message, and (b) timespec64_add_ns
> > supported negative numbers.
> >
> > timespec64_add_ns doesn't work with signed deltas, because the
> > implementation is based around iter_div_u64_rem. This change resulted in
> > a regression where i40e_ptp_adjtime would interpret small negative
> > adjustments as large positive additions, resulting in incorrect
> > behavior.
> >
> > This commit doesn't appear to fix anything, is not well explained, and
> > introduces a bug, so lets just revert it.
> 
> Ah, this is not the bug I was referring to but actually worse.
> I was only worried about hogging the CPU while doing billions
> of additions in a loop, and had not realized it also changes
> the result.
> 

Yep. That's what I figured out last Friday.

Regards,
Jake

> > Reverts: 0ac30ce43323 ("i40e: fix up 32 bit timespec references", 2017-07-26)
> > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> 
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>

[Intel-wired-lan] [PATCH] i40e: fix i40e_ptp_adjtime when given a negative delta

[Bowers, AndrewX]

> -----Original Message-----
> From: Intel-wired-lan [mailto:intel-wired-lan-bounces at osuosl.org] On
> Behalf Of Jacob Keller
> Sent: Monday, February 25, 2019 11:20 AM
> To: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Subject: [Intel-wired-lan] [PATCH] i40e: fix i40e_ptp_adjtime when given a
> negative delta
> 
> Commit 0ac30ce43323 ("i40e: fix up 32 bit timespec references",
> 2017-07-26) claims to be cleaning up references to 32-bit timespecs.
> 
> The actual contents of the commit make no sense, as it converts a call to
> timespec64_add into timespec64_add_ns. This would seem ok, if (a) the
> change was documented in the commit message, and (b)
> timespec64_add_ns supported negative numbers.
> 
> timespec64_add_ns doesn't work with signed deltas, because the
> implementation is based around iter_div_u64_rem. This change resulted in a
> regression where i40e_ptp_adjtime would interpret small negative
> adjustments as large positive additions, resulting in incorrect behavior.
> 
> This commit doesn't appear to fix anything, is not well explained, and
> introduces a bug, so lets just revert it.
> 
> Reverts: 0ac30ce43323 ("i40e: fix up 32 bit timespec references", 2017-07-26)
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
>  drivers/net/ethernet/intel/i40e/i40e_ptp.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Tested-by: Andrew Bowers <andrewx.bowers@intel.com>

[Intel-wired-lan] [PATCH] i40e: fix i40e_ptp_adjtime when given a negative delta

[Arnd Bergmann]

On Mon, Feb 25, 2019 at 8:46 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Feb 25, 2019 at 8:20 PM Jacob Keller <jacob.e.keller@intel.com> wrote:
> >
> > Commit 0ac30ce43323 ("i40e: fix up 32 bit timespec references",
> > 2017-07-26) claims to be cleaning up references to 32-bit timespecs.
> >
> > The actual contents of the commit make no sense, as it converts a call
> > to timespec64_add into timespec64_add_ns. This would seem ok, if (a) the
> > change was documented in the commit message, and (b) timespec64_add_ns
> > supported negative numbers.
> >
> > timespec64_add_ns doesn't work with signed deltas, because the
> > implementation is based around iter_div_u64_rem. This change resulted in
> > a regression where i40e_ptp_adjtime would interpret small negative
> > adjustments as large positive additions, resulting in incorrect
> > behavior.
> >
> > This commit doesn't appear to fix anything, is not well explained, and
> > introduces a bug, so lets just revert it.
>
> Ah, this is not the bug I was referring to but actually worse.
> I was only worried about hogging the CPU while doing billions
> of additions in a loop, and had not realized it also changes
> the result.
>
> > Reverts: 0ac30ce43323 ("i40e: fix up 32 bit timespec references", 2017-07-26)
> > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Any update on this? Your patch doesn't seem to have made it in as
a bugfix, or into linux-next yet.

       Arnd

[Intel-wired-lan] [PATCH] i40e: fix i40e_ptp_adjtime when given a negative delta

[Keller, Jacob E]

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Monday, March 25, 2019 9:45 AM
> To: Keller, Jacob E <jacob.e.keller@intel.com>
> Cc: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>
> Subject: Re: [PATCH] i40e: fix i40e_ptp_adjtime when given a negative delta
> 
> On Mon, Feb 25, 2019 at 8:46 PM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Mon, Feb 25, 2019 at 8:20 PM Jacob Keller <jacob.e.keller@intel.com> wrote:
> > >
> > > Commit 0ac30ce43323 ("i40e: fix up 32 bit timespec references",
> > > 2017-07-26) claims to be cleaning up references to 32-bit timespecs.
> > >
> > > The actual contents of the commit make no sense, as it converts a call
> > > to timespec64_add into timespec64_add_ns. This would seem ok, if (a) the
> > > change was documented in the commit message, and (b) timespec64_add_ns
> > > supported negative numbers.
> > >
> > > timespec64_add_ns doesn't work with signed deltas, because the
> > > implementation is based around iter_div_u64_rem. This change resulted in
> > > a regression where i40e_ptp_adjtime would interpret small negative
> > > adjustments as large positive additions, resulting in incorrect
> > > behavior.
> > >
> > > This commit doesn't appear to fix anything, is not well explained, and
> > > introduces a bug, so lets just revert it.
> >
> > Ah, this is not the bug I was referring to but actually worse.
> > I was only worried about hogging the CPU while doing billions
> > of additions in a loop, and had not realized it also changes
> > the result.
> >
> > > Reverts: 0ac30ce43323 ("i40e: fix up 32 bit timespec references", 2017-07-26)
> > > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> >
> > Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> 
> Any update on this? Your patch doesn't seem to have made it in as
> a bugfix, or into linux-next yet.
> 
>        Arnd

It's still marked as under review on patchworks. It was marked as tested by Andrew Bowers, so I am not sure what else holdup is.

Jeff?

I think this patch could/should go through net because it's a bug fix.

Thanks,
Jake

[Intel-wired-lan] [PATCH] i40e: fix i40e_ptp_adjtime when given a negative delta

[Jeff Kirsher]

On Mon, 2019-03-25 at 10:23 -0700, Keller, Jacob E wrote:
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: Monday, March 25, 2019 9:45 AM
> > To: Keller, Jacob E <jacob.e.keller@intel.com>
> > Cc: Intel Wired LAN <intel-wired-lan@lists.osuosl.org>; Kirsher,
> > Jeffrey T
> > <jeffrey.t.kirsher@intel.com>
> > Subject: Re: [PATCH] i40e: fix i40e_ptp_adjtime when given a
> > negative delta
> > 
> > On Mon, Feb 25, 2019 at 8:46 PM Arnd Bergmann <arnd@arndb.de>
> > wrote:
> > > On Mon, Feb 25, 2019 at 8:20 PM Jacob Keller <
> > > jacob.e.keller at intel.com> wrote:
> > > > Commit 0ac30ce43323 ("i40e: fix up 32 bit timespec references",
> > > > 2017-07-26) claims to be cleaning up references to 32-bit
> > > > timespecs.
> > > > 
> > > > The actual contents of the commit make no sense, as it converts
> > > > a call
> > > > to timespec64_add into timespec64_add_ns. This would seem ok,
> > > > if (a) the
> > > > change was documented in the commit message, and (b)
> > > > timespec64_add_ns
> > > > supported negative numbers.
> > > > 
> > > > timespec64_add_ns doesn't work with signed deltas, because the
> > > > implementation is based around iter_div_u64_rem. This change
> > > > resulted in
> > > > a regression where i40e_ptp_adjtime would interpret small
> > > > negative
> > > > adjustments as large positive additions, resulting in incorrect
> > > > behavior.
> > > > 
> > > > This commit doesn't appear to fix anything, is not well
> > > > explained, and
> > > > introduces a bug, so lets just revert it.
> > > 
> > > Ah, this is not the bug I was referring to but actually worse.
> > > I was only worried about hogging the CPU while doing billions
> > > of additions in a loop, and had not realized it also changes
> > > the result.
> > > 
> > > > Reverts: 0ac30ce43323 ("i40e: fix up 32 bit timespec
> > > > references", 2017-07-26)
> > > > Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
> > > 
> > > Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> > 
> > Any update on this? Your patch doesn't seem to have made it in as
> > a bugfix, or into linux-next yet.
> > 
> >         Arnd
> 
> It's still marked as under review on patchworks. It was marked as
> tested by Andrew Bowers, so I am not sure what else holdup is.
> 
> Jeff?
> 
> I think this patch could/should go through net because it's a bug
> fix.

I apologize, I got bogged down with ice driver patches.  I will push
the fix to Dave's net tree now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20190326/c5a8fc4f/attachment.asc>