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
prev parent 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