[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM0PR04MB6754E9A905834B1198760F1C964F9@AM0PR04MB6754.eurprd04.prod.outlook.com>
Date: Tue, 13 Apr 2021 14:00:29 +0000
From: Claudiu Manoil <claudiu.manoil@....com>
To: "Y.b. Lu" <yangbo.lu@....com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC: "Y.b. Lu" <yangbo.lu@....com>,
"David S . Miller" <davem@...emloft.net>,
Richard Cochran <richardcochran@...il.com>,
Jakub Kicinski <kuba@...nel.org>,
Vladimir Oltean <vladimir.oltean@....com>,
Russell King <linux@...linux.org.uk>
Subject: RE: [net-next] enetc: fix locking for one-step timestamping packet
transfer
>-----Original Message-----
>From: Yangbo Lu <yangbo.lu@....com>
>Sent: Tuesday, April 13, 2021 6:48 AM
[...]
>Subject: [net-next] enetc: fix locking for one-step timestamping packet
>transfer
>
>The previous patch to support PTP Sync packet one-step timestamping
>described one-step timestamping packet handling logic as below in
>commit message:
>
>- Trasmit packet immediately if no other one in transfer, or queue to
> skb queue if there is already one in transfer.
> The test_and_set_bit_lock() is used here to lock and check state.
>- Start a work when complete transfer on hardware, to release the bit
> lock and to send one skb in skb queue if has.
>
>There was not problem of the description, but there was a mistake in
>implementation. The locking/test_and_set_bit_lock() should be put in
>enetc_start_xmit() which may be called by worker, rather than in
>enetc_xmit(). Otherwise, the worker calling enetc_start_xmit() after
>bit lock released is not able to lock again for transfer.
>
>Fixes: 7294380c5211 ("enetc: support PTP Sync packet one-step
>timestamping")
>Signed-off-by: Yangbo Lu <yangbo.lu@....com>
>---
Reviewed-by: Claudiu Manoil <claudiu.manoil@....com>
Powered by blists - more mailing lists