public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
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



  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