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
| ||
|
Message-ID: <20220301232953.17331-1-miles.chen@mediatek.com> Date: Wed, 2 Mar 2022 07:29:53 +0800 From: Miles Chen <miles.chen@...iatek.com> To: <robin.murphy@....com> CC: <Libo.Kang@...iatek.com>, <Ning.Li@...iatek.com>, <iommu@...ts.linux-foundation.org>, <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>, <linux-mediatek@...ts.infradead.org>, <matthias.bgg@...il.com>, <stable@...r.kernel.org>, <will@...nel.org>, <wsd_upstream@...iatek.com>, <yf.wang@...iatek.com> Subject: Re: [PATCH v2] iommu/iova: Reset max32_alloc_size after cleaning Hi Yunfei, >> Since __alloc_and_insert_iova_range fail will set the current alloc >> iova size to max32_alloc_size (iovad->max32_alloc_size = size), >> when the retry is executed into the __alloc_and_insert_iova_range >> function, the retry action will be blocked by the check condition >> (size >= iovad->max32_alloc_size) and goto iova32_full directly, >> causes the action of retry regular alloc iova in >> __alloc_and_insert_iova_range to not actually be executed. >> >> Based on the above, so need reset max32_alloc_size before retry alloc >> iova when alloc iova fail, that is set the initial dma_32bit_pfn value >> of iovad to max32_alloc_size, so that the action of retry alloc iova >> in __alloc_and_insert_iova_range can be executed. > > Have you observed this making any difference in practice? > > Given that both free_cpu_cached_iovas() and free_global_cached_iovas() > call iova_magazine_free_pfns(), which calls remove_iova(), which calls > __cached_rbnode_delete_update(), I'm thinking no... > > Robin. > Like Robin pointed out, if some cached iovas are freed by free_global_cached_iovas()/free_cpu_cached_iovas(), the max32_alloc_size should be reset to iovad->dma_32bit_pfn. If no cached iova is freed, resetting max32_alloc_size before the retry allocation only give us a retry. Is it possible that other users free their iovas during the additional retry? alloc_iova_fast() retry: alloc_iova() // failed, iovad->max32_alloc_size = size free_cpu_cached_iovas() iova_magazine_free_pfns() remove_iova() __cached_rbnode_delete_update() iovad->max32_alloc_size = iovad->dma_32bit_pfn // reset free_global_cached_iovas() iova_magazine_free_pfns() remove_iova() __cached_rbnode_delete_update() iovad->max32_alloc_size = iovad->dma_32bit_pfn // reset goto retry; thanks, Miles
Powered by blists - more mailing lists