linux-kernel - Re: [PATCH] usbip: Fix the error limitation on max_hw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7e9db4d9-0a22-44b4-a981-0de25d6a2aa4@163.com>
Date: Thu, 13 Mar 2025 18:02:31 +0800
From: Zongmin Zhou <min_halo@....com>
To: Shuah Khan <skhan@...uxfoundation.org>
Cc: valentina.manea.m@...il.com, shuah@...nel.org, i@...ithal.me,
 gregkh@...uxfoundation.org, linux-usb@...r.kernel.org,
 linux-kernel@...r.kernel.org, Zongmin Zhou <zhouzongmin@...inos.cn>
Subject: Re: [PATCH] usbip: Fix the error limitation on max_hw_sectors for
 usbip device


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@...uxfoundation.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?

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.

>>>>
>>>>
>>>> If SWIOTLB disabled,dma_max_mapping_size() return SIZE_MAX.
>>>
>>> Right when CONFIG_HAS_DMA, if not it returns 0. Perhaps we
>>  >can ignore CONFIG_HAS_DMA=n for this for this discussion.
>> Yeah, let's ignore that.
>>>
>>>>
>>>> Only if SWIOTLB is active and dma addressing limited will return 
>>>> the swiotlb max mapping size.
>>>>
>>>>
>>>> The swiotlb config seems rely on many other config options like 
>>>> x86_64/IOMMU_SUPPORT and so on,
>>>>
>>>> and the configuration on host and client side only use the default 
>>>> at all,Like the default ubuntu release version.
>>>>
>>>> It seems that switlb is enabled by default on most platforms.
>>>
>>> If understand correctly the problem happens only when SWIOTLB
>>> is enabled on client or host?
>>>
>>> The following combinations are possible:
>>>
>>> SWILTLB enabled on client and disabled on host - rate limited?
>>> SWILTLB enabled on client and enabled on host - rate limited?
>>> SWILTLB disabled on client and enabled on host - rate limited?
>>> SWILTLB disabled on client and disabled on host - not a problem
>>  >
>> This problem happens only when SWIOTLB is enabled on client,have 
>> nothing to do with host setting. Because the USB xhci controller may 
>> set dma mask to 64bit if controllers support. The combinations may 
>> like below: SWILTLB enabled on client and enabled/disabled on host - 
>> rate limited SWILTLB disabled on client and enabled/disabled on host 
>> - not a problem
>
> Got it. So the problem happens only when SWILTLB enabled on client
>
Yes.
> thanks,
> -- Shuah