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: <e8f83833-940a-3542-5c68-3dc25a230383@huawei.com>
Date: Thu, 24 Oct 2024 17:38:09 +0800
From: "shenjian (K)" <shenjian15@...wei.com>
To: Paolo Abeni <pabeni@...hat.com>, Jijie Shao <shaojijie@...wei.com>,
	<davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<salil.mehta@...wei.com>
CC: <liuyonglong@...wei.com>, <wangpeiyang1@...wei.com>, <lanhao@...wei.com>,
	<chenhao418@...wei.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V2 net 2/9] net: hns3: add sync command to sync io-pgtable


在 2024/10/24 16:36, Paolo Abeni 写道:
> On 10/18/24 12:10, Jijie Shao wrote:
>> From: Jian Shen <shenjian15@...wei.com>
>>
>> To avoid errors in pgtable prefectch, add a sync command to sync
>> io-pagtable.
>>
>> In the case of large traffic, the TX bounce buffer may be used up.
> It's unclear to me what do you mean for large traffic. Is that large
> packets instead?
>
> Skimming over the previous patch, it looks like the for the bugger H/W
> driver will use the bounce buffer for all packets with len < 64K. As
> this driver does not support big tcp, such condition means all packets.
>
> So its not clear to me the 'may' part - it looks like the critical path
> will always happen on the bugged H/W

Sorry for the unclear commit log.

Yes, we don't support big tcp, so <64K is worked for all packets. The 
large traffic

here is just want to describe a case that tx bounce buffer is used up, 
and there is

no enough space for new tx packets.


>> At this point, we go to mapping/unmapping on TX path again.
>> So we added the sync command in driver to avoid hardware issue.
> I thought the goal of the previous patch was to avoid such sync-up.
>
> So I don't understand why it's there.
>
> A more verbose explanation will help.

This is a supplement for the previous patch. We want all the tx packet can

be handled with tx bounce buffer path. But it depends on the remain space

of the spare buffer, checked by the function hns3_can_use_tx_bounce(). In

most cases, maybe 99.99%, it returns true. But once it return false by no

available space, the packet will be handled with the former path, which

will map/unmap the skb buffer. Then we will face the smmu prefetch risk 
again.

So I add a sync command in this case to avoid smmu prefectch,

just protects corner scenes.


>> Signed-off-by: Jian Shen <shenjian15@...wei.com>
>> Signed-off-by: Peiyang Wang <wangpeiyang1@...wei.com>
>> Signed-off-by: Jijie Shao <shaojijie@...wei.com>
> Also we need a fixes tag.

We considered this issue, and since this is not a software defect, we 
were not too

sure which commit should be blamed.

It makes sense to choose the commit introducing the support for the 
buggy H/W, we will add

it.


Thanks!

Jian Shen


> Thanks,
>
> Paolo
>
>
> .
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ