From: Simon Horman <horms@kernel.org>
To: Shuvam Pandey <shuvampandey1@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+5ec223ccb83b24ef982f@syzkaller.appspotmail.com
Subject: Re: [PATCH net] atm: mpoa: fix mpc->dev refcount across mpoad restart
Date: Fri, 10 Apr 2026 15:03:12 +0100 [thread overview]
Message-ID: <20260410140312.GW469338@kernel.org> (raw)
In-Reply-To: <177555091252.59118.13093904987038690781@gmail.com>
On Tue, Apr 07, 2026 at 02:20:12PM +0545, Shuvam Pandey wrote:
> atm: mpoa: fix mpc->dev refcount across mpoad restart
>
> mpoad_close() drops the reference held in mpc->dev with dev_put(), but
> the mpoa_client stays alive and keeps the same device pointer.
>
> A later mpoad attach reuses the existing mpoa_client without
> reacquiring that reference, so the next close can hit the netdevice
> refcount warning. Keep the LEC device reference with the mpoa_client
> until the device unregisters or the client is torn down.
Hi Shuvam,
Including the stack trace would be useful, IMHO.
>
> Reported-by: syzbot+5ec223ccb83b24ef982f@syzkaller.appspotmail.com
> Link: https://groups.google.com/g/syzkaller-bugs/c/qhZ5MJfLBOE/m/UnotmgRdAQAJ
A fixes tag should go here, indicating the commit which introduced
the bug - typically the commit where it first manifested.
> Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com>
> ---
> net/atm/mpc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/net/atm/mpc.c b/net/atm/mpc.c
> index ce8e9780373b..1e9b9c633e8b 100644
> --- a/net/atm/mpc.c
> +++ b/net/atm/mpc.c
> @@ -886,7 +886,6 @@ static void mpoad_close(struct atm_vcc *vcc)
> struct lec_priv *priv = netdev_priv(mpc->dev);
> priv->lane2_ops->associate_indicator = NULL;
> stop_mpc(mpc);
> - dev_put(mpc->dev);
> }
>
> mpc->in_ops->destroy_cache(mpc);
I'm not really familiar with the object life cycle here.
But it strikes me that the purpose of dev_put() in a close callback
is to indicate the device no longer needs to be held for the connection
being closed. And, if so, I wonder if the problem here is that
there is no corresponding dev_hold() in the (unimplemented) open callback.
(I am assuming there is a 1:1 symmetry between open and close.)
> @@ -1508,6 +1507,8 @@ static void __exit atm_mpoa_cleanup(void)
> priv = netdev_priv(mpc->dev);
> if (priv->lane2_ops != NULL)
> priv->lane2_ops->associate_indicator = NULL;
> + dev_put(mpc->dev);
> + mpc->dev = NULL;
> }
> ddprintk("about to clear caches\n");
> mpc->in_ops->destroy_cache(mpc);
AI generated review flags that atm_mpoa_cleanup() already calls
unregister_netdevice_notifier() which will trigger the
NETDEV_UNREGISTER handler in mpoa_event_listener() which already calls
dev_put.
This seems to duplicate that. Which I expect is undesirable.
prev parent reply other threads:[~2026-04-10 14:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 8:35 [PATCH net] atm: mpoa: fix mpc->dev refcount across mpoad restart Shuvam Pandey
2026-04-10 14:03 ` 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=20260410140312.GW469338@kernel.org \
--to=horms@kernel.org \
--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=shuvampandey1@gmail.com \
--cc=syzbot+5ec223ccb83b24ef982f@syzkaller.appspotmail.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