[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250904075531.gcovqmarfan4vx7w@DEN-DL-M31836.microchip.com>
Date: Thu, 4 Sep 2025 09:55:31 +0200
From: Horatiu Vultur <horatiu.vultur@...rochip.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <andrew@...n.ch>, <hkallweit1@...il.com>, <linux@...linux.org.uk>,
<davem@...emloft.net>, <edumazet@...gle.com>, <pabeni@...hat.com>,
<richardcochran@...il.com>, <vadim.fedorenko@...ux.dev>,
<vladimir.oltean@....com>, <viro@...iv.linux.org.uk>,
<quentin.schulz@...tlin.com>, <atenart@...nel.org>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net v3] phy: mscc: Stop taking ts_lock for tx_queue and
use its own lock
The 09/03/2025 17:05, Jakub Kicinski wrote:
Hi Jakub,
>
> On Tue, 2 Sep 2025 14:12:59 +0200 Horatiu Vultur wrote:
> > - len = skb_queue_len(&ptp->tx_queue);
> > + len = skb_queue_len_lockless(&ptp->tx_queue);
> > if (len < 1)
> > return;
> >
> > while (len--) {
> > - skb = __skb_dequeue(&ptp->tx_queue);
> > + skb = skb_dequeue(&ptp->tx_queue);
> > if (!skb)
> > return;
>
> Isn't checking len completely unnecessary? skb_dequeue() will return
> null if the list is empty, which you are already handling.
I don't think so, because if the skb doesn't match the sig then the skb
is added back to the tx_queue.
/* Valid signature but does not match the one of the
* packet in the FIFO right now, reschedule it for later
* packets.
*/
skb_queue_tail(&ptp->tx_queue, skb);
Then if we change to check until skb_dequeue returns NULL we might be in
an infinite loop.
> --
> pw-bot: cr
--
/Horatiu
Powered by blists - more mailing lists