All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Chwee-Lin Choong <chwee.lin.choong@intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Richard Cochran <richardcochran@gmail.com>,
	Vinicius Costa Gomes <vinicius.gomes@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Avi Shalev <avi.shalev@intel.com>,
	Song Yoong Siang <yoong.siang.song@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net v1] igc: fix race condition in TX timestamp read for register 0
Date: Thu, 18 Sep 2025 21:47:33 +0100	[thread overview]
Message-ID: <0fc877a5-4b35-4802-9cda-e4eca561c5d1@linux.dev> (raw)
In-Reply-To: <20250918183811.31270-1-chwee.lin.choong@intel.com>

On 18/09/2025 19:38, Chwee-Lin Choong wrote:
> The current HW bug workaround checks the TXTT_0 ready bit first,
> then reads LOW -> HIGH -> LOW from register 0 to detect if a
> timestamp was captured.
> 
> This sequence has a race: if a new timestamp is latched after
> reading the TXTT mask but before the first LOW read, both old
> and new timestamp match, causing the driver to drop a valid
> timestamp.
> 
> Fix by reading the LOW register first, then the TXTT mask,
> so a newly latched timestamp will always be detected.
> 
> This fix also prevents TX unit hangs observed under heavy
> timestamping load.
> 
> Fixes: c789ad7cbebc ("igc: Work around HW bug causing missing timestamps")
> Suggested-by: Avi Shalev <avi.shalev@intel.com>
> Signed-off-by: Song Yoong Siang <yoong.siang.song@intel.com>
> Signed-off-by: Chwee-Lin Choong <chwee.lin.choong@intel.com>
> ---
>   drivers/net/ethernet/intel/igc/igc_ptp.c | 10 ++++++++--
>   1 file changed, 8 insertions(+), 2 deletions(-)
> 

[...]

>   		 * timestamp was captured, we can read the "high"
>   		 * register again.
>   		 */

This comment begins with 'read the "high" register (to latch a new 
timestamp)' ...

> -		u32 txstmpl_old, txstmpl_new;
> +		u32 txstmpl_new;
>   
> -		txstmpl_old = rd32(IGC_TXSTMPL);
>   		rd32(IGC_TXSTMPH);
>   		txstmpl_new = rd32(IGC_TXSTMPL);

and a couple of lines later in this function you have

		regval = txstmpl_new;
		regval |= (u64)rd32(IGC_TXSTMPH) << 32;

According to the comment above, the value in the register will be
latched after reading IGC_TXSTMPH. As there will be no read of "low"
part of the register, it will stay latched with old value until the
next call to the same function. Could it be the reason of unit hangs?

It looks like the value of previous read of IGC_TXSTMPH should be stored
and used to construct new timestamp, right?


WARNING: multiple messages have this Message-ID (diff)
From: Vadim Fedorenko <vadim.fedorenko@linux.dev>
To: Chwee-Lin Choong <chwee.lin.choong@intel.com>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	Przemek Kitszel <przemyslaw.kitszel@intel.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Richard Cochran <richardcochran@gmail.com>,
	Vinicius Costa Gomes <vinicius.gomes@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, Avi Shalev <avi.shalev@intel.com>,
	Song Yoong Siang <yoong.siang.song@intel.com>
Subject: Re: [PATCH iwl-net v1] igc: fix race condition in TX timestamp read for register 0
Date: Thu, 18 Sep 2025 21:47:33 +0100	[thread overview]
Message-ID: <0fc877a5-4b35-4802-9cda-e4eca561c5d1@linux.dev> (raw)
In-Reply-To: <20250918183811.31270-1-chwee.lin.choong@intel.com>

On 18/09/2025 19:38, Chwee-Lin Choong wrote:
> The current HW bug workaround checks the TXTT_0 ready bit first,
> then reads LOW -> HIGH -> LOW from register 0 to detect if a
> timestamp was captured.
> 
> This sequence has a race: if a new timestamp is latched after
> reading the TXTT mask but before the first LOW read, both old
> and new timestamp match, causing the driver to drop a valid
> timestamp.
> 
> Fix by reading the LOW register first, then the TXTT mask,
> so a newly latched timestamp will always be detected.
> 
> This fix also prevents TX unit hangs observed under heavy
> timestamping load.
> 
> Fixes: c789ad7cbebc ("igc: Work around HW bug causing missing timestamps")
> Suggested-by: Avi Shalev <avi.shalev@intel.com>
> Signed-off-by: Song Yoong Siang <yoong.siang.song@intel.com>
> Signed-off-by: Chwee-Lin Choong <chwee.lin.choong@intel.com>
> ---
>   drivers/net/ethernet/intel/igc/igc_ptp.c | 10 ++++++++--
>   1 file changed, 8 insertions(+), 2 deletions(-)
> 

[...]

>   		 * timestamp was captured, we can read the "high"
>   		 * register again.
>   		 */

This comment begins with 'read the "high" register (to latch a new 
timestamp)' ...

> -		u32 txstmpl_old, txstmpl_new;
> +		u32 txstmpl_new;
>   
> -		txstmpl_old = rd32(IGC_TXSTMPL);
>   		rd32(IGC_TXSTMPH);
>   		txstmpl_new = rd32(IGC_TXSTMPL);

and a couple of lines later in this function you have

		regval = txstmpl_new;
		regval |= (u64)rd32(IGC_TXSTMPH) << 32;

According to the comment above, the value in the register will be
latched after reading IGC_TXSTMPH. As there will be no read of "low"
part of the register, it will stay latched with old value until the
next call to the same function. Could it be the reason of unit hangs?

It looks like the value of previous read of IGC_TXSTMPH should be stored
and used to construct new timestamp, right?


  parent reply	other threads:[~2025-09-18 20:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-18 18:38 [Intel-wired-lan] [PATCH iwl-net v1] igc: fix race condition in TX timestamp read for register 0 Chwee-Lin Choong
2025-09-18 18:38 ` Chwee-Lin Choong
2025-09-18 16:03 ` [Intel-wired-lan] " Paul Menzel
2025-09-19  6:16   ` Choong, Chwee Lin
2025-09-19  6:16     ` Choong, Chwee Lin
2025-09-18 20:47 ` Vadim Fedorenko [this message]
2025-09-18 20:47   ` Vadim Fedorenko
2025-09-18 22:10   ` [Intel-wired-lan] " Jacob Keller
2025-09-19  7:17     ` Choong, Chwee Lin
2025-09-19  7:17       ` Choong, Chwee Lin
2025-09-19 10:55       ` Vadim Fedorenko
2025-09-19 12:57         ` Shalev, Avi
2025-09-19 12:57           ` Shalev, Avi
2025-09-19 10:52     ` Vadim Fedorenko
2025-09-19 19:34 ` Loktionov, Aleksandr
2025-09-19 19:34   ` Loktionov, Aleksandr
2025-10-13 14:04 ` Bouska, Zdenek
2025-10-13 14:04   ` Bouska, Zdenek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0fc877a5-4b35-4802-9cda-e4eca561c5d1@linux.dev \
    --to=vadim.fedorenko@linux.dev \
    --cc=andrew+netdev@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=avi.shalev@intel.com \
    --cc=chwee.lin.choong@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=richardcochran@gmail.com \
    --cc=vinicius.gomes@intel.com \
    --cc=yoong.siang.song@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.