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: 24+ 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-30 16:44 ` Shuah Khan
2026-03-31 9:58 ` [PATCH v3] usbip: tools: add hint when no exported devices are found Zongmin Zhou
2026-04-01 0:27 ` Shuah Khan
2026-04-01 2:47 ` Zongmin Zhou
2026-04-01 16:06 ` Shuah Khan
2026-04-02 8:32 ` [PATCH v4] " Zongmin Zhou
2026-04-06 21:12 ` Shuah Khan
2026-04-07 2:34 ` Zongmin Zhou
2026-04-09 17:25 ` Shuah Khan
2026-03-11 12:13 ` [PATCH] usbip: tools: Add usbip host driver availability check 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.