linux-kernel - Re: [PATCH 1/1] Revert "iommu/iova: Retry from last rb tree node if iova search fails"

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] [day] [month] [year] [list]

Message-ID: <8b526177-758e-eee4-74ee-6aa855072e70@huawei.com>
Date:   Wed, 10 Mar 2021 17:50:34 +0000
From:   John Garry <john.garry@...wei.com>
To:     Robin Murphy <robin.murphy@....com>,
        "Leizhen (ThunderTown)" <thunder.leizhen@...wei.com>,
        Will Deacon <will@...nel.org>, Joerg Roedel <joro@...tes.org>,
        iommu <iommu@...ts.linux-foundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
CC:     Vijayanand Jitta <vjitta@...eaurora.org>,
        Linuxarm <linuxarm@...wei.com>
Subject: Re: [PATCH 1/1] Revert "iommu/iova: Retry from last rb tree node if
 iova search fails"

On 08/03/2021 16:22, John Garry wrote:
> 
>>
>>>> While max32_alloc_size indirectly tracks the largest*contiguous* 
>>>> available space, one of the ideas from which it grew was to simply keep
>>>> count of the total number of free PFNs. If you're really spending
>>>> significant time determining that the tree is full, as opposed to just
>>>> taking longer to eventually succeed, then it might be relatively
>>>> innocuous to tack on that semi-redundant extra accounting as a
>>>> self-contained quick fix for that worst case.
>>>>
> 
> ...

So since the retry means that we search through the complete pfn range 
most of the time (due to poor success rate quoted), we should be able to 
do a better job at maintaining an accurate max alloc size, by 
calculating it during the failed search, and not relying on max alloc 
failed or resetting it frequently. Hopefully that would mean that we're 
smarter about quickly failing the allocation.

I'll further look at that.

Thanks,
John