Re: [PATCH] net: llc: clean up unaccepted child sockets in llc_ui_release()

[Simon Horman <horms@kernel.org>]

On Wed, Sep 23, 2026 at 09:36:38PM +0000, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 6 potential
> issue(s) to consider.
> 
> Critical: 1 · High: 3 · Medium: 1 · Low: 1
> 
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
> 
> - [Critical] Type confusion in the new TCP_LISTEN drain loop in
>   llc_ui_release(): the loop assumes every skb on sk->sk_receive_queue…
> - [High] The drain of the listener's sk_receive_queue is placed at the
>   very start of llc_ui_release() (net/llc/af_llc.c:207-225), before…
> - [High] The new child teardown in llc_ui_release()
>   (net/llc/af_llc.c:213-222) removes the child from the SAP hash, drops…
> - [High] Incomplete fix: the new release-time drain can only reclaim
>   children whose skb reached the listener's sk_receive_queue, i.e.…
> - [Medium] Reference-tracker acquire/release mismatch: the new code
>   releases the child's netdev reference with netdev_put(child_llc->dev,…
> - [Low] The commit message cites a non-existent symbol: "llc_ui_release()
>   calls skb_queue_purge(&sk->sk_receive_queue) in llc_sk_Component /…
> 
> --
> 
> net: llc: clean up unaccepted child sockets in llc_ui_release()
> 
> The patch adds a drain of the listener's sk_receive_queue at the top of
> llc_ui_release() when sk_state is TCP_LISTEN.  For every queued skb it
> takes skb->sk as an unaccepted child, removes it from its SAP, drops the
> device reference and frees it with llc_sk_free().  A few questions about
> the new block and the changelog below.
> 
> Commit message:
> 
> > If the listening socket is closed without calling `accept()`,
> > `llc_ui_release()` calls `skb_queue_purge(&sk->sk_receive_queue)` in
> > `llc_sk_Component` / `llc_sk_free()`, which frees the queued `skb`s
> 
> [Severity: Low]
> Where does llc_sk_Component come from?  A grep for that string over the
> tree at this commit returns nothing, and the only skb_queue_purge() of
> sk->sk_receive_queue in net/llc is the one in llc_sk_free() in
> net/llc/llc_conn.c.  Could the changelog name only the function that
> actually exists?

In this case I am just going to stop right here.

It's a low severity issue. But at a minimum it seems to imply something has
slipped through. And looking at the long list of issues flagged above,
combined with the long list of patches from you in my inbox (~66) I don't
think it is wise to spend more time on this one in it's current form.

-- 
pw-bot: changes-requested