linux-kernel - Re: [PATCH v2] iommu/iova: Optimize alloc_iova with rbtree

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: <4a62a93c-683a-0515-2033-26c59b3b6f20@bytedance.com>
Date:   Fri, 2 Sep 2022 11:30:53 +0800
From:   Peng Zhang <zhangpeng.00@...edance.com>
To:     John Garry <john.garry@...wei.com>, joro@...tes.org,
        will@...nel.org
Cc:     iommu@...ts.linux.dev, linux-kernel@...r.kernel.org,
        robin.murphy@....com, xieyongji@...edance.com,
        Ethan Zhao <haifeng.zhao@...ux.intel.com>
Subject: Re: [PATCH v2] iommu/iova: Optimize alloc_iova with rbtree_augmented


> If you really have a performance issue with alloc_iova_fast() -> 
> alloc_iova() then I suggest that you consider trying to use 
> dma_opt_mapping_size() to teach the DMA engine driver to not create 
> requests whose overall size exceeds to the rcache limit.

Yes. But I don't think it essentially solves the problem.
A library for users should run stably ant it shouldn't hold
the spinlock for a long time in some cases. It can even be
said to be a bug.

Like this:
[Wed May 25 05:27:59 2022] watchdog: BUG: soft lockup - CPU#58
stuck for 23s!
[Wed May 25 05:27:59 2022] Call Trace:
[Wed May 25 05:27:59 2022]  alloc_iova+0xf2/0x140
[Wed May 25 05:27:59 2022]  alloc_iova_fast+0x56/0x251

Now we avoid this problem with iommu=pt, but it didn't solve the problem.

Thanks,
Peng