From: Simon Horman <horms@kernel.org>
To: dddddd@hust.edu.cn
Cc: Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, david@ixit.cz, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
dzm91@hust.edu.cn, hust-os-kernel-patches@googlegroups.com
Subject: Re: [PATCH net] nfc: clear active_target when the target list is replaced
Date: Tue, 7 Jul 2026 11:01:05 +0100 [thread overview]
Message-ID: <20260707100105.1380119-1-horms@kernel.org> (raw)
In-Reply-To: <20260625111835.2411251-1-dddddd@hust.edu.cn>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://netdev-ai.bots.linux.dev/sashiko/
---
nfc: clear active_target when the target list is replaced
This patch updates nfc_targets_found() so that when the active target
points into the dev->targets array about to be freed, the cached pointer
is cleared and a partial teardown (presence-check timer stop, dep_link_up
cleared, rf_mode reset) is performed before kfree(dev->targets).
> diff --git a/net/nfc/core.c b/net/nfc/core.c
> index a92a6566e6a0..950807906645 100644
> --- a/net/nfc/core.c
> +++ b/net/nfc/core.c
> @@ -786,6 +786,21 @@ int nfc_targets_found(struct nfc_dev *dev,
>
> dev->targets_generation++;
>
> + if (dev->active_target && dev->targets) {
> + for (i = 0; i < dev->n_targets; i++) {
> + if (dev->active_target != &dev->targets[i])
> + continue;
> +
> + if (dev->ops->check_presence)
> + timer_delete_sync(&dev->check_pres_timer);
> +
> + dev->active_target = NULL;
> + dev->dep_link_up = false;
> + dev->rf_mode = NFC_RF_NONE;
> + break;
> + }
> + }
> +
[Medium]
The commit message says this teardown mirrors what nfc_deactivate_target()
does, but nfc_deactivate_target() does not touch dev->dep_link_up at all.
Forcing dep_link_up = false here when the active target was set up via
nfc_dep_link_up() introduces a state mutation that is not described in
the commit log.
Can this leave DEP/LLCP state only partially torn down?
Compared to nfc_dep_link_down(), this new branch skips:
rc = dev->ops->dep_link_down(dev);
...
nfc_llcp_mac_is_down(dev);
nfc_genl_dep_link_down_event(dev);
so the driver is never told to bring the DEP link down, LLCP sockets
bound to the local are not released via nfc_llcp_socket_release(), and
no NFC_EVENT_DEP_LINK_DOWN is sent to userspace.
A subsequent userspace nfc_dep_link_down() will then be rejected here:
net/nfc/core.c:nfc_dep_link_down() {
...
if (dev->dep_link_up == false) {
rc = -EALREADY;
goto error;
}
...
}
so the normal cleanup path that calls nfc_llcp_mac_is_down() is no
longer reachable from userspace until device unregister.
Does this risk leaking the LLCP sockets that were created while
dep_link_up was true?
If the goal is just to clear the dangling active_target pointer, would
it be enough to clear dev->active_target (and stop the presence-check
timer) without also forcing dep_link_up = false and rf_mode = NFC_RF_NONE?
Alternatively, if a full DEP teardown is intended, should this path call
dev->ops->dep_link_down(dev) and nfc_llcp_mac_is_down(dev) like
nfc_dep_link_down() does?
prev parent reply other threads:[~2026-07-07 10:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 11:18 [PATCH net] nfc: clear active_target when the target list is replaced Yinhao Hu
2026-07-07 10:00 ` Simon Horman
2026-07-07 10:01 ` 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=20260707100105.1380119-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=davem@davemloft.net \
--cc=david@ixit.cz \
--cc=dddddd@hust.edu.cn \
--cc=dzm91@hust.edu.cn \
--cc=edumazet@google.com \
--cc=hust-os-kernel-patches@googlegroups.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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