From: Shuah Khan <skhan@linuxfoundation.org>
To: Zongmin Zhou <min_halo@163.com>,
valentina.manea.m@gmail.com, shuah@kernel.org, i@zenithal.me,
Greg KH <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Zongmin Zhou <zhouzongmin@kylinos.cn>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] usbip: tools: Add usbip host driver availability check
Date: Mon, 23 Mar 2026 13:17:36 -0600 [thread overview]
Message-ID: <29c03d8b-c73b-4393-95ff-bbf5c31df86e@linuxfoundation.org> (raw)
In-Reply-To: <bf5faa3f-6b59-4977-a29f-811049289b14@163.com>
On 3/11/26 20:17, Zongmin Zhou wrote:
>
> On 2026/3/11 06:28, Shuah Khan wrote:
>> On 3/3/26 01:17, Zongmin Zhou wrote:
>>> From: Zongmin Zhou <zhouzongmin@kylinos.cn>
>>>
>>> Currently, usbip_generic_driver_open() doesn't verify that the required
>>> kernel module (usbip-host or usbip-vudc) is actually loaded.
>>> The function returns success even when no driver is present,
>>> leading to usbipd daemon run success without driver loaded.
>>
>> Doesn't usbip_generic_driver_open() try to refresh exported
>> device list and fail? It returns error if it can't find fetch
>> them.
>>
>> usbipd starts and the when usbip_host is loaded it works correctly.
>> Doesn't it?
> Actually, refresh_exported_devices() does not return an error
> when the driver is not loaded,it consistently returns 0.
> It only results in hdriver->ndevs being set to 0 if no exportable usbip devices are found.
> Consequently, if the driver is missing, usbipd will start successfully in silence,
> but subsequent usbip attach operations will fail.
> The lack of explicit error messages makes it difficult for users to troubleshoot the root cause.
> By adding a check to verify if the driver is loaded during the usbip daemon startup,
> we can prevent these silent exceptions and ensure users are alerted to
> the missing kernel module before they attempt to use the service.
>>>
>>> So add a check function to ensure usbip host driver has been loaded.
>>>
>>> Signed-off-by: Zongmin Zhou <zhouzongmin@kylinos.cn>
>>> ---
>>> tools/usb/usbip/libsrc/usbip_device_driver.c | 2 ++
>>> tools/usb/usbip/libsrc/usbip_host_common.c | 31 ++++++++++++++++++++
>>> tools/usb/usbip/libsrc/usbip_host_common.h | 2 ++
>>> tools/usb/usbip/libsrc/usbip_host_driver.c | 2 ++
>>> 4 files changed, 37 insertions(+)
>>>
>>> diff --git a/tools/usb/usbip/libsrc/usbip_device_driver.c b/tools/usb/usbip/libsrc/usbip_device_driver.c
>>> index 927a151fa9aa..6da000fab26d 100644
>>> --- a/tools/usb/usbip/libsrc/usbip_device_driver.c
>>> +++ b/tools/usb/usbip/libsrc/usbip_device_driver.c
>>> @@ -147,6 +147,8 @@ static int usbip_device_driver_open(struct usbip_host_driver *hdriver)
>>> struct usbip_host_driver device_driver = {
>>> .edev_list = LIST_HEAD_INIT(device_driver.edev_list),
>>> .udev_subsystem = "udc",
>>> + .bus_type = "platform",
>>
>> Why are we adding this here - user-space shouldn't need to
>> know what kind of driver this is?
> The reason I added the bus_type and drv_name fields is to
> construct the specific sysfs paths required for the availability check.
> Although usbip-host and usbip-vudc share the same usbip_generic_driver_open() interface ,
> they operate on different bus types and have different driver names.
> These fields allow the generic open function to dynamically verify
> the correct driver path in sysfs based on the specific driver type being initialized.
> If you prefer not to expose these in the this structure,
> I'm happy to adjust further based on your suggestions.
Have you tried a simple system() e.g below:
if (system("/usr/bin/lsmod | grep usbip")) instead of adding
all of this code?
Take a look at other examples of driver checks in cpupower
check_msr_driver() for example.
thanks,
-- Shuah
next prev parent reply other threads:[~2026-03-23 19:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-03 8:17 [PATCH] usbip: tools: Add usbip host driver availability check Zongmin Zhou
2026-03-10 22:28 ` Shuah Khan
2026-03-12 2:17 ` Zongmin Zhou
2026-03-23 19:17 ` Shuah Khan [this message]
2026-03-25 2:26 ` [PATCH v2] " Zongmin Zhou
2026-03-25 8:58 ` Greg KH
2026-03-26 3:10 ` Zongmin Zhou
2026-03-26 8:43 ` Greg KH
2026-03-26 18:43 ` Shuah Khan
2026-03-27 8:39 ` Zongmin Zhou
2026-03-27 17:51 ` Shuah Khan
2026-03-27 18:29 ` Shuah Khan
2026-03-30 3:10 ` Zongmin Zhou
2026-03-11 12:13 ` [PATCH] " Greg KH
2026-03-12 2:17 ` Zongmin Zhou
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=29c03d8b-c73b-4393-95ff-bbf5c31df86e@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=i@zenithal.me \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=min_halo@163.com \
--cc=shuah@kernel.org \
--cc=valentina.manea.m@gmail.com \
--cc=zhouzongmin@kylinos.cn \
/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