Netdev List
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Yinhao Hu <dddddd@hust.edu.cn>
Cc: David Heidelberg <david@ixit.cz>, Kees Cook <kees@kernel.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	Dan Carpenter <error27@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Samuel Ortiz <sameo@linux.intel.com>,
	Michael Thalmeier <michael.thalmeier@hale.at>,
	netdev@vger.kernel.org, dzm91@hust.edu.cn,
	hust-os-kernel-patches@googlegroups.com
Subject: Re: [PATCH net] nfc: pn533: hold a reference to the request skb during send_frame
Date: Tue, 7 Jul 2026 13:55:11 +0100	[thread overview]
Message-ID: <20260707125511.GD1364329@horms.kernel.org> (raw)
In-Reply-To: <20260626073434.3977525-1-dddddd@hust.edu.cn>

On Fri, Jun 26, 2026 at 12:34:34AM -0700, Yinhao Hu wrote:
> __pn533_send_async() publishes the command and then calls
> dev->phy_ops->send_frame(). Once dev->cmd is set, an incoming frame
> can be matched to this command: the I2C threaded IRQ runs
> pn533_recv_frame(), which queues cmd_complete_work, and
> pn533_send_async_complete() frees cmd->req with consume_skb().
> 
> On the I2C transport, pn533_i2c_send_frame() still dereferences the same
> skb after i2c_master_send() returns, so a completion that races the
> send can free the skb while the transport is still using it.
> 
> The request skb is owned by the command object and may be freed by
> command completion at any time after dev->cmd is published, so the
> transport send path must not assume it stays alive. Hold a temporary
> reference to the request skb across the send_frame() call so the
> transport always sees a live skb even if completion races the send.
> Add a pn533_send_cmd_frame() helper and use it from all three send
> paths.
> 
> Fixes: 9815c7cf22da ("NFC: pn533: Separate physical layer from the core implementation")
> Signed-off-by: Yinhao Hu <dddddd@hust.edu.cn>

Reviewed-by: Simon Horman <horms@kernel.org>

There is an AI generated review of this patch available on sashiko.dev.
You may want to consider the issues raised there in the context
of possible follow-up. But I don't think that needs to impede the progress
of this patch.


      reply	other threads:[~2026-07-07 12:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26  7:34 [PATCH net] nfc: pn533: hold a reference to the request skb during send_frame Yinhao Hu
2026-07-07 12:55 ` Simon Horman [this message]

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=20260707125511.GD1364329@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=david@ixit.cz \
    --cc=dddddd@hust.edu.cn \
    --cc=dzm91@hust.edu.cn \
    --cc=error27@gmail.com \
    --cc=hust-os-kernel-patches@googlegroups.com \
    --cc=kees@kernel.org \
    --cc=krzk@kernel.org \
    --cc=kuba@kernel.org \
    --cc=michael.thalmeier@hale.at \
    --cc=netdev@vger.kernel.org \
    --cc=sameo@linux.intel.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