From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: Andre Guedes <andre.guedes@intel.com>,
vladimir.oltean@nxp.com, kurt@linutronix.de,
anthony.l.nguyen@intel.com, kernel@pengutronix.de,
intel-wired-lan@lists.osuosl.org, jzi@pengutronix.de
Subject: Re: [Intel-wired-lan] [PATCH next-queue v1 1/3] igc: Fix race condition in PTP tx code
Date: Tue, 14 Mar 2023 12:19:38 -0700 [thread overview]
Message-ID: <875yb3i1it.fsf@intel.com> (raw)
In-Reply-To: <20230313095648.czf4so6qpkcotqq4@pengutronix.de>
Marc Kleine-Budde <mkl@pengutronix.de> writes:
> On 27.02.2023 21:45:32, Vinicius Costa Gomes wrote:
>> From: Andre Guedes <andre.guedes@intel.com>
>>
>> Currently, the igc driver supports timestamping only one tx packet at a
>> time. During the transmission flow, the skb that requires hardware
>> timestamping is saved in adapter->ptp_tx_skb. Once hardware has the
>> timestamp, an interrupt is delivered, and adapter->ptp_tx_work is
>> scheduled. In igc_ptp_tx_work(), we read the timestamp register, update
>> adapter->ptp_tx_skb, and notify the network stack.
>>
>> While the thread executing the transmission flow (the user process
>> running in kernel mode) and the thread executing ptp_tx_work don't
>> access adapter->ptp_tx_skb concurrently, there are two other places
>> where adapter->ptp_tx_skb is accessed: igc_ptp_tx_hang() and
>> igc_ptp_suspend().
>>
>> igc_ptp_tx_hang() is executed by the adapter->watchdog_task worker
>> thread which runs periodically so it is possible we have two threads
>> accessing ptp_tx_skb at the same time. Consider the following scenario:
>> right after __IGC_PTP_TX_IN_PROGRESS is set in igc_xmit_frame_ring(),
>> igc_ptp_tx_hang() is executed. Since adapter->ptp_tx_start hasn't been
>> written yet, this is considered a timeout and adapter->ptp_tx_skb is
>> cleaned up.
>>
>> This patch fixes the issue described above by adding the ptp_tx_lock to
>> protect access to ptp_tx_skb and ptp_tx_start fields from igc_adapter.
>> Since igc_xmit_frame_ring() called in atomic context by the networking
>> stack, ptp_tx_lock is defined as a spinlock.
>>
>> With the introduction of the ptp_tx_lock, the __IGC_PTP_TX_IN_PROGRESS
>> flag doesn't provide much of a use anymore so this patch gets rid of it.
>
> Since the igc PTP code is derived from igb, do we need this patch to be
> ported to the igb driver, too?
Yes, that would be good. Will add this to my todo, but I will be glad if
anyone beats me to it.
>
> regards,
> Marc
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Embedded Linux | https://www.pengutronix.de |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Cheers,
--
Vinicius
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
next prev parent reply other threads:[~2023-03-14 19:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-28 5:45 [Intel-wired-lan] [PATCH next-queue v1 0/3] igc: Add support for multiple TX tstamp requests Vinicius Costa Gomes
2023-02-28 5:45 ` [Intel-wired-lan] [PATCH next-queue v1 1/3] igc: Fix race condition in PTP tx code Vinicius Costa Gomes
2023-02-28 17:33 ` Vladimir Oltean
2023-03-09 21:33 ` Vinicius Costa Gomes
[not found] ` <20230313095648.czf4so6qpkcotqq4@pengutronix.de>
2023-03-14 19:19 ` Vinicius Costa Gomes [this message]
2023-02-28 5:45 ` [Intel-wired-lan] [PATCH next-queue v1 2/3] igc: Add support for multiple in-flight TX timestamps Vinicius Costa Gomes
2023-02-28 17:45 ` Vladimir Oltean
2023-03-09 21:39 ` Vinicius Costa Gomes
2023-02-28 5:45 ` [Intel-wired-lan] [PATCH next-queue v1 3/3] igc: Use ptp->aux_worker to retrieve " Vinicius Costa Gomes
2023-02-28 18:16 ` Vladimir Oltean
2023-03-09 21:58 ` Vinicius Costa Gomes
[not found] ` <20230313100207.ztxhu3cbxkb5c6iy@pengutronix.de>
2023-03-13 22:13 ` Vinicius Costa Gomes
2023-02-28 18:27 ` [Intel-wired-lan] [PATCH next-queue v1 0/3] igc: Add support for multiple TX tstamp requests Vladimir Oltean
2023-03-09 22:57 ` Vinicius Costa Gomes
2023-03-22 16:03 ` Miroslav Lichvar
2023-03-22 21:46 ` Vinicius Costa Gomes
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=875yb3i1it.fsf@intel.com \
--to=vinicius.gomes@intel.com \
--cc=andre.guedes@intel.com \
--cc=anthony.l.nguyen@intel.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jzi@pengutronix.de \
--cc=kernel@pengutronix.de \
--cc=kurt@linutronix.de \
--cc=mkl@pengutronix.de \
--cc=vladimir.oltean@nxp.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.