From: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
To: Paolo Abeni <pabeni@redhat.com>
Cc: "parthiban.veerasooran@microchip.com"
<parthiban.veerasooran@microchip.com>,
"andrew+netdev@lunn.ch" <andrew+netdev@lunn.ch>,
Piergiorgio Beruto <Pier.Beruto@onsemi.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"edumazet@google.com" <edumazet@google.com>,
"kuba@kernel.org" <kuba@kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"andrew@lunn.ch" <andrew@lunn.ch>,
"Parthiban.Veerasooran@microchip.com"
<Parthiban.Veerasooran@microchip.com>
Subject: RE: [PATCH net v5 1/4] net: ethernet: oa_tc6: Protect skb pointer used by two different kernel instances
Date: Wed, 12 Aug 2026 20:05:05 +0000 [thread overview]
Message-ID: <MWHPR02MB3375A1D6694AF69928D72D1083DC2@MWHPR02MB3375.namprd02.prod.outlook.com> (raw)
In-Reply-To: <20260806092055.101202-1-pabeni@redhat.com>
> -----Original Message-----
> From: Paolo Abeni <pabeni@redhat.com>
>
>
> [Severity: Medium]
> [Finding: main-1-1]
> [Sources: opus-5]
> Should the changelog mention the other behavioural changes that come with
> this fix? The message only describes adding mutual exclusion for
> waiting_tx_skb, but the patch also:
>
> The exact interleaving that leaks the skb is also not spelled out. Since
> this carries a Fixes: tag and will be picked up for stable, could the
> message describe the leaking sequence and the return-code change? The
> disable_traffic locking is only mentioned in the v3 changelog below the
> cut, which is dropped when the patch is applied.
Updated commit message with more info.
>
> In oa_tc6_exit() the store happens under the lock and disable_irq() only
> runs afterwards:
>
> spin_lock_bh(&tc6->tx_skb_lock);
> tc6->disable_traffic = true;
> spin_unlock_bh(&tc6->tx_skb_lock);
> disable_irq(tc6->spi->irq);
>
> Can a level triggered interrupt in that window make oa_tc6_macphy_isr()
> observe a stale false, set int_flag and wake the thread, which then takes
> the early return above without doing the data chunk transfer that
> deasserts INT?
Moving disable_irq call before setting the disable_traffic flag.
>
> > spin_lock_bh(&tc6->tx_skb_lock);
> > + if (tc6->waiting_tx_skb) {
> > + netif_stop_queue(tc6->netdev);
> > + spin_unlock_bh(&tc6->tx_skb_lock);
> > + return NETDEV_TX_BUSY;
> > + }
>
> [Severity: Low]
> [Finding: fable-5-1-5]
> [Sources: fable-5, opus-5]
> Does moving skb_linearize() in front of the waiting_tx_skb check change the
> back-pressure policy?
>
> Previously an xmit that hit the busy case returned NETDEV_TX_BUSY without
> touching the skb. Now every xmit linearizes first, so a transient
> skb_linearize() -ENOMEM during a busy period frees the frame and returns
> NETDEV_TX_OK, where before it would have been requeued and retried.
>
> The kernel-doc above oa_tc6_start_xmit() still says:
>
> * Return: NETDEV_TX_OK if the transmit ethernet frame skb added in the tx_skb_q
> * otherwise returns NETDEV_TX_BUSY.
>
> which no longer covers the drop cases. Should that be refreshed too?
Yes. Updating the comment to cover all the return conditions.
>
next prev parent reply other threads:[~2026-08-12 20:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 1:35 [PATCH net v5 0/4] Fix to possible skb leak due to race condtion in tx path Selvamani Rajagopal via B4 Relay
2026-07-30 1:35 ` [PATCH net v5 1/4] net: ethernet: oa_tc6: Protect skb pointer used by two different kernel instances Selvamani Rajagopal via B4 Relay
2026-08-06 9:20 ` Paolo Abeni
2026-08-12 20:05 ` Selvamani Rajagopal [this message]
2026-07-30 1:35 ` [PATCH net v5 2/4] net: ethernet: oa_tc6: Improve the error recovery Selvamani Rajagopal via B4 Relay
2026-08-06 10:43 ` Paolo Abeni
2026-08-12 19:50 ` Selvamani Rajagopal
2026-07-30 1:35 ` [PATCH net v5 3/4] net: ethernet: oa_tc6: Disable tx queues on fatal error Selvamani Rajagopal via B4 Relay
2026-08-06 10:43 ` Paolo Abeni
2026-08-12 19:58 ` Selvamani Rajagopal
2026-07-30 1:35 ` [PATCH net v5 4/4] net: ethernet: oa_tc6: Fix for the wrong data type Selvamani Rajagopal via B4 Relay
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=MWHPR02MB3375A1D6694AF69928D72D1083DC2@MWHPR02MB3375.namprd02.prod.outlook.com \
--to=selvamani.rajagopal@onsemi.com \
--cc=Pier.Beruto@onsemi.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=parthiban.veerasooran@microchip.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®