public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: Zongmin Zhou <min_halo@163.com>
Cc: valentina.manea.m@gmail.com, shuah@kernel.org, i@zenithal.me,
	gregkh@linuxfoundation.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Zongmin Zhou <zhouzongmin@kylinos.cn>,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] usbip: Fix the error limitation on max_hw_sectors for usbip device
Date: Fri, 28 Mar 2025 15:14:31 -0600	[thread overview]
Message-ID: <99a8b726-726a-4e26-bafc-9ff2b1e4d7be@linuxfoundation.org> (raw)
In-Reply-To: <7e9db4d9-0a22-44b4-a981-0de25d6a2aa4@163.com>

On 3/13/25 04:02, Zongmin Zhou wrote:
> 
> On 2025/3/11 00:49, Shuah Khan wrote:
>> On 3/5/25 03:03, Zongmin Zhou wrote:
>>> At 2025-03-05 03:45:28, "Shuah Khan" <skhan@linuxfoundation.org> wrote:
>>>
>>>> On 3/2/25 05:37, Zongmin Zhou wrote:
>>>>> Dear shuah,
>>>>>
>>>>>
>>>>> Yes, I agree with you.It would be better if there have a more simpler fixes than This patch.
>>>>>
>>>>> I can just think of the two possible solutions that mentioned before.
>>>>
>>>  >What are the two possible solutions?
>>> 1. The patch we are discussing now,have to change the API between the kernel and user-space.
>>
>> 2. Simply set vhci-hcd dma mask to 64 by default,just modify the vhci-hcd driver. Then dma_max_mapping_size() will always return SIZE_MAX.
>>
>> I prefer option #2 - What are the downsides if any with this option?
>>
> If set vhci-hcd dma mask to 64 by default,I can't predict what will happen when the real USB controller support less than 64bit?
> 
> After all, the data flows from vhci-hcd to usbip-host and finally to the USB controller to which the device is actually connected.
> 
> the data is ultimately processed through the real USB controller?

Sorry for the delay.

That is the case. I have to check the code to see what the host
would do if it receives larger buffers from the client (vhci)
> 
> However, the default setting to 64-bit is equivalent to eliminating the impact of
> 
> the patch(commit d74ffae8b8dd) on usbip protocol devices, sounds feasible?
> 
> I am not very professional in this field, waiting for your evaluation.

We can give this a try. Send me the patch with default testing the
following cases:

Host - swiotlb enabled and disabled in your environment to see what
happens when there is a mismatch swiotlb enabled case and client
side doesn't limit the size.

thanks,
-- Shuah

  reply	other threads:[~2025-03-28 21:14 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-19  9:25 [PATCH] usbip: Fix the error limitation on max_hw_sectors for usbip device Zongmin Zhou
2025-02-21 16:37 ` Shuah Khan
     [not found]   ` <5a41d6c3.8c78.195371996e0.Coremail.min_halo@163.com>
2025-02-27 22:23     ` Shuah Khan
     [not found]       ` <4d4035bf.26b9.19556dcc23d.Coremail.min_halo@163.com>
2025-03-04 19:45         ` Shuah Khan
     [not found]           ` <6d47fef6.9eef.19565c308e5.Coremail.min_halo@163.com>
2025-03-10 16:49             ` Shuah Khan
2025-03-13 10:02               ` Zongmin Zhou
2025-03-28 21:14                 ` Shuah Khan [this message]
2025-04-02  8:34                   ` Zongmin Zhou
2025-04-08 22:54                     ` Shuah Khan
2025-04-22  6:34                       ` [PATCH] usbip: set the dma mask to 64bit default for vhci-driver Zongmin Zhou
2025-04-22  6:40                         ` Greg KH
2025-04-22  7:24                         ` Christoph Hellwig
2025-04-25  8:08                           ` Zongmin Zhou
2025-04-25  8:28                             ` Greg KH
2025-04-28  9:51                               ` Zongmin Zhou
2025-04-28 10:04                                 ` Greg KH
2025-04-28 23:07                                   ` Shuah Khan
2025-04-30  5:24                                     ` Zongmin Zhou
2025-04-30  7:31                                       ` Greg KH
2025-04-23  1:02                         ` kernel test robot
2025-04-23  7:50                         ` kernel test robot

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=99a8b726-726a-4e26-bafc-9ff2b1e4d7be@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