All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Parthiban.Veerasooran@microchip.com>
To: <Selvamani.Rajagopal@onsemi.com>
Cc: <netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<andrew@lunn.ch>, <andrew+netdev@lunn.ch>,
	<pier.beruto@onsemi.com>, <davem@davemloft.net>,
	<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>
Subject: Re: [PATCH net v2 0/2] Fix to possible skb leak due to race condtion in tx path
Date: Tue, 30 Jun 2026 05:38:12 +0000	[thread overview]
Message-ID: <d3d382c6-5ae4-486f-89a4-885584d863c4@microchip.com> (raw)
In-Reply-To: <20260626-fix-race-condition-and-crash-v2-0-b6c5c10e604f@onsemi.com>

Hi Selvamani,

On 26/06/26 9:05 pm, Selvamani Rajagopal via B4 Relay wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Now the traffic is handled in threaded IRQ, and the
> disable_traffic flag is checked before handling the
> data, new race condition is exposed, in which
> buffer may leak, if threaded IRQ interrupts the
> trasmit path midway.
> 
> With this change, disable_traffic and waiting_tx_skb
> pointer are protected by spin lock/unlock pair.
> 
> This is highlighted in Sashiko review
> https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260611-level-trigger-v5-0-4533a9e85ce2%40onsemi.com
> 
> Also on buffer overrun condition, probably due to loss of
> SPI data chunks, receive path doesn't see the expected
> data chunk with end_valid bit set. As a result, driver
> keeps adding data chunks to the skb before running out
> of space and kernel panic is seen.
> 
> With this change, before adding data to the skb, if there
> is no space, skb is freed and driver starts looking for
> new frame by looking for a data chunk with start_valid
> bit set.
> 
> [  705.405490] skbuff: skb_over_panic: text:ffffffd2eb72a264 len:1600 put:64 head:ffffff804e5cdc40 data:ffffff804e5cdc80 tail:0x680 end:0x640 dev:eth1
> [  705.405569] ------------[ cut here ]------------
> [  705.405575] kernel BUG at net/core/skbuff.c:214!
> [  705.405589] Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
> 
> [ 6703.427690] Call trace:
> [  705.925157]  skb_panic+0x58/0x68 (P)
> [  705.928726]  skb_put+0x74/0x80
> [  705.931772]  oa_tc6_update_rx_skb+0x44/0x98 [oa_tc6_mod]
> [  705.937084]  oa_tc6_macphy_threaded_irq+0x3f4/0x900 [oa_tc6_mod]
> [  705.943084]  irq_thread_fn+0x34/0xb8
> [  705.946654]  irq_thread+0x1a0/0x300
> [  705.950134]  kthread+0x138/0x150
> [  705.953356]  ret_from_fork+0x10/0x20
> 
> Signed-off-by: Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> ---
> Changes in v2:
> - Improvment to how error -EAGAIN is handled. Took care of
>    couple of use cases where start_bit and end_bit may be missing or
>    repeated due to lost data chunks.
> - Protected handling of waiting_tx_skb pointer with spin lock
> - Link to v1: https://lore.kernel.org/r/20260621-fix-race-condition-and-crash-v1-0-87e290d9357f@onsemi.com
I performed a one-hour quick test using two instances of the LAN8651 
MAC-PHY Click (Test Case 2), and it ran without any crashes. Thank you 
for the fixes.

Best regards,
Parthiban V
> 
> ---
> Selvamani Rajagopal (2):
>        net: ethernet: oa_tc6: Protect skb pointer used by two different kernel instances
>        net: ethernet: oa_tc6: Improvement in buffer overflow handling
> 
>   drivers/net/ethernet/oa_tc6.c | 91 ++++++++++++++++++++++++++++++-------------
>   1 file changed, 64 insertions(+), 27 deletions(-)
> ---
> base-commit: 805185b7c7a1069e407b6f7b3bc98e44d415f484
> change-id: 20260621-fix-race-condition-and-crash-94d055a665c4
> 
> Best regards,
> --
> Selvamani Rajagopal <Selvamani.Rajagopal@onsemi.com>
> 
> 


  parent reply	other threads:[~2026-06-30  5:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26 15:35 [PATCH net v2 0/2] Fix to possible skb leak due to race condtion in tx path Selvamani Rajagopal
2026-06-26 15:35 ` Selvamani Rajagopal via B4 Relay
2026-06-26 15:35 ` [PATCH net v2 1/2] net: ethernet: oa_tc6: Protect skb pointer used by two different kernel instances Selvamani Rajagopal
2026-06-26 15:35   ` Selvamani Rajagopal via B4 Relay
2026-06-30  2:15   ` Jakub Kicinski
2026-06-30  4:16     ` Selvamani Rajagopal
2026-06-30 22:46       ` Jakub Kicinski
2026-07-01  4:15         ` Selvamani Rajagopal
2026-06-26 15:35 ` [PATCH net v2 2/2] net: ethernet: oa_tc6: Improvement in buffer overflow handling Selvamani Rajagopal
2026-06-26 15:35   ` Selvamani Rajagopal via B4 Relay
2026-06-30  2:29   ` Jakub Kicinski
2026-06-30  4:41     ` Selvamani Rajagopal
2026-06-30  5:38 ` Parthiban.Veerasooran [this message]
2026-06-30  5:57   ` [PATCH net v2 0/2] Fix to possible skb leak due to race condtion in tx path Selvamani Rajagopal

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=d3d382c6-5ae4-486f-89a4-885584d863c4@microchip.com \
    --to=parthiban.veerasooran@microchip.com \
    --cc=Selvamani.Rajagopal@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=pier.beruto@onsemi.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.