Linux kernel -stable discussions
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: raoxu <raoxu@uniontech.com>
Cc: brgl@kernel.org, gregkh@linuxfoundation.org, i@zenithal.me,
	ihadzic@research.bell-labs.com, linux-kernel@vger.kernel.org,
	linux-usb@vger.kernel.org, luiz.von.dentz@intel.com,
	pengpeng@iscas.ac.cn, pmenzel@molgen.mpg.de, shuah@kernel.org,
	stable@vger.kernel.org, valentina.manea.m@gmail.com,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] usbip: Close all listening sockets in request workers
Date: Fri, 13 Nov 2026 14:41:43 -0700	[thread overview]
Message-ID: <573f682d-47ee-4e39-80ed-0ddf0da96cdb@linuxfoundation.org> (raw)
In-Reply-To: <351AC939AD9B6359+20261113023710.1746483-1-raoxu@uniontech.com>

On 11/12/26 19:37, raoxu wrote:
> Hi Shuah,
> 
> Thanks for the review.
> 
> I found this while reviewing the listening socket handling across fork() in
> usbipd.c, and then reproduced the issue with the unmodified usbipd binary on
> two UOS test machines.
> 
> Both machines have usbip 2.0+6.5.10-2 installed, with usbipd located at
> /usr/sbin/usbipd. This package contains the original listener handling.
> 
> I used separate test ports to avoid interfering with the default USB/IP
> service.
> 
> On 10.20.12.188, the reproduction steps were:
> 
> 1. Start usbipd as root with both IPv4 and IPv6 listeners:
> 
>         sudo /usr/sbin/usbipd -d -4 -6 -t 43241
> 
> 2. From a client machine, establish an IPv4 TCP connection and keep it open
>     without sending a USB/IP request:
> 
>         python3 -c 'import socket,time; s=socket.create_connection(("10.20.12.188",43241)); time.sleep(300)'
> 
> 3. Terminate only the main usbipd process with SIGTERM, leaving the worker
>     running.

You removed all the context from the thread :(

In the following path in process_request(), child exits after
handling the pdu - all open fds get closed.

        childpid = fork();
         if (childpid == 0) {
                 close(listenfd);
                 recv_pdu(connfd);
                 exit(0);
         }

How does the problem you are describing happen in the normal
use-case when a child exits after handling the request. If
it doesn't there is no need for this change you are proposing.

thanks,
-- Shuah

      reply	other threads:[~2026-11-13 21:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-12 12:16 [PATCH] usbip: Close all listening sockets in request workers raoxu
2026-11-12 16:12 ` Shuah Khan
2026-11-13  2:37   ` raoxu
2026-11-13 21:41     ` Shuah Khan [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=573f682d-47ee-4e39-80ed-0ddf0da96cdb@linuxfoundation.org \
    --to=skhan@linuxfoundation.org \
    --cc=brgl@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=i@zenithal.me \
    --cc=ihadzic@research.bell-labs.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=luiz.von.dentz@intel.com \
    --cc=pengpeng@iscas.ac.cn \
    --cc=pmenzel@molgen.mpg.de \
    --cc=raoxu@uniontech.com \
    --cc=shuah@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=valentina.manea.m@gmail.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