mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

> 


  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®