From: Shuah Khan <skhan@linuxfoundation.org>
To: Jason Colapietro <jasoncola1@gmail.com>,
shuah@kernel.org, valentina.manea.m@gmail.com
Cc: greg@kroah.com, i@zenithal.me, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH v7] usbip: make remote list honor parsable output
Date: Thu, 1 Oct 2026 06:53:52 -0600 [thread overview]
Message-ID: <05047d41-499a-4e96-ac64-bebdc0b330c9@linuxfoundation.org> (raw)
In-Reply-To: <1557ed70-d2da-424c-8ba6-10c898bbb81c@linuxfoundation.org>
On 10/1/26 06:49, Shuah Khan wrote:
> On 9/26/26 22:00, Jason Colapietro wrote:
>> Hi Shuah and all,
>>
>> The exact v7 patch has now been built and tested with a native Linux
>> USB/IP stack.
>>
>> Test setup: Alpine Linux 3.23.4 on aarch64, kernel 6.18.53-0-lts,
>> usbip-utils 2.0. A QEMU USB mass-storage device (46f4:0001, busid 2-1)
>> was bound to usbip-host and exported by usbipd. The client connected
>> to 127.0.0.1:3240.
>>
>> With the unpatched client, "usbip list -p -r 127.0.0.1" still printed
>> the human-readable "Exportable USB devices" report, reproducing the
>> bug. With the v7 client, the same command returned:
>>
>> busid=2-1#usbid=46f4:0001#
>>
>> "usbip list -r 127.0.0.1" retained its human-readable output,
>> including the device path and interface details. After unbinding the
>> device, the parsable command exited successfully with zero bytes on
>> stdout; rebinding restored the record.
>>
>> I also attached busid 2-1 through the v7 client. "usbip port" showed
>> it imported through vhci_hcd at port 08, and lsusb showed the device
>> on both the original and virtual host buses. Detach succeeded, leaving
>> no imported port. The build, list, attach, and detach commands all
>> exited successfully.
>>
>> This was one Linux VM with an emulated USB device and TCP loopback. I
>> have not tested physical USB hardware or two separate machines. The
>> existing option-order behavior is unchanged: -p must precede -r.
>
> Please test this with two systems hots running on one and client on the
> other. Send me before and after output that shows the bug and that it is
> fixed by your change.
Another thing. This needs to be reproduced and tested on the latest kenel,
Linux 7.3-rc5
thanks,
-- Shuah
next prev parent reply other threads:[~2026-10-01 12:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 8:36 Jason Colapietro
2026-09-14 17:43 ` Jason Colapietro
2026-09-23 8:44 ` Shuah Khan
2026-09-27 4:00 ` Jason Colapietro
2026-10-01 12:49 ` Shuah Khan
2026-10-01 12:53 ` Shuah Khan [this message]
2026-10-01 16:13 ` jasoncola1
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=05047d41-499a-4e96-ac64-bebdc0b330c9@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=greg@kroah.com \
--cc=i@zenithal.me \
--cc=jasoncola1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=shuah@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
all inboxes | Powered by JetHome®