From: Jakub Kicinski <kuba@kernel•org>
To: Stanislav Fomichev <stfomichev@gmail•com>
Cc: Mina Almasry <almasrymina@google•com>,
Taehee Yoo <ap420073@gmail•com>,
davem@davemloft•net, pabeni@redhat•com, edumazet@google•com,
andrew+netdev@lunn•ch, horms@kernel•org, asml.silence@gmail•com,
dw@davidwei•uk, sdf@fomichev•me, skhawaja@google•com,
simona.vetter@ffwll•ch, kaiyuanz@google•com,
netdev@vger•kernel.org
Subject: Re: [PATCH net] net: devmem: fix kernel panic when socket close after module unload
Date: Wed, 16 Apr 2025 17:15:55 -0700 [thread overview]
Message-ID: <20250416171555.11cf612c@kernel.org> (raw)
In-Reply-To: <Z__BRyblHNHhnui7@mini-arch>
On Wed, 16 Apr 2025 07:40:07 -0700 Stanislav Fomichev wrote:
> > The socket close path would probably need to lock the socket, look at
> > the first entry, if entry has ->dev call netdev_hold(), release the
> > socket, lock the netdev, lock the socket again, look at the ->dev, if
> > NULL we raced - done. If not NULL release the socket, call unbind.
> > netdev_put(). Restart this paragraph.
> >
> > I can't think of an easier way.
>
> An alternative might be to have a new extra lock to just protect
> the binding->bound_rxq? And we can move the netdev_lock/unlock inside
> the xa_for_each loop in net_devmem_unbind_dmabuf. This will make sure
> we don't touch the outdated 'dev'. But I think you're right, the same
> lock ordering issue is gonna happen in this case as well.
Yea, I was wondering about that but unless we're holding something that
prevents the netdev from going away - a lock or a ref - we'll just
circle back to the same race.
next prev parent reply other threads:[~2025-04-17 0:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 9:24 [PATCH net] net: devmem: fix kernel panic when socket close after module unload Taehee Yoo
2025-04-15 17:33 ` Stanislav Fomichev
2025-04-15 18:22 ` Mina Almasry
2025-04-15 18:59 ` Stanislav Fomichev
2025-04-16 2:59 ` Jakub Kicinski
2025-04-16 14:40 ` Stanislav Fomichev
2025-04-17 0:15 ` Jakub Kicinski [this message]
2025-04-16 15:01 ` Taehee Yoo
2025-04-17 0:35 ` Jakub Kicinski
2025-04-17 6:57 ` Taehee Yoo
2025-04-17 14:09 ` Jakub Kicinski
2025-04-18 10:46 ` Taehee Yoo
2025-04-16 15:47 ` Mina Almasry
2025-04-17 0:27 ` Jakub Kicinski
2025-04-17 21:07 ` Mina Almasry
2025-04-18 10:52 ` Taehee Yoo
2025-05-05 17:34 ` Jakub Kicinski
2025-05-06 11:41 ` Taehee Yoo
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=20250416171555.11cf612c@kernel.org \
--to=kuba@kernel$(echo .)org \
--cc=almasrymina@google$(echo .)com \
--cc=andrew+netdev@lunn$(echo .)ch \
--cc=ap420073@gmail$(echo .)com \
--cc=asml.silence@gmail$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=dw@davidwei$(echo .)uk \
--cc=edumazet@google$(echo .)com \
--cc=horms@kernel$(echo .)org \
--cc=kaiyuanz@google$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=pabeni@redhat$(echo .)com \
--cc=sdf@fomichev$(echo .)me \
--cc=simona.vetter@ffwll$(echo .)ch \
--cc=skhawaja@google$(echo .)com \
--cc=stfomichev@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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