| 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
| ||
|
Date: Thu, 26 Mar 2015 00:09:37 +0530
From: Ritesh Harjani <ritesh.list@...il.com>
To: Tomasz Figa <tfiga@...omium.org>
Cc: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
Laura Abbott <lauraa@...eaurora.org>,
David Rientjes <rientjes@...gle.com>,
Will Deacon <will.deacon@....com>,
LKML <linux-kernel@...r.kernel.org>,
Douglas Anderson <dianders@...omium.org>,
Carlo Caione <carlo@...one.org>,
Russell King <linux@....linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
Sonny Rao <sonnyrao@...omium.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Ritesh Harjani <ritesh.harjani@...il.com>
Subject: Re: [PATCH v2] ARM: mm: Do not invoke OOM for higher order IOMMU DMA allocations
Hi
On Mon, Mar 23, 2015 at 12:57 PM, Tomasz Figa <tfiga@...omium.org> wrote:
> IOMMU should be able to use single pages as well as bigger blocks, so if
> higher order allocations fail, we should not affect state of the system,
> with events such as OOM killer, but rather fall back to order 0
> allocations.
>
> This patch changes the behavior of ARM IOMMU DMA allocator to use
> __GFP_NORETRY, which bypasses OOM invocation, for orders higher than
> zero and, only if that fails, fall back to normal order 0 allocation
> which might invoke OOM killer.
Logical thing to do in IOMMU case :)
>
> Signed-off-by: Tomasz Figa <tfiga@...omium.org>
> ---
> arch/arm/mm/dma-mapping.c | 27 +++++++++++++++++++++------
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> Changes since v1:
> (https://patchwork.kernel.org/patch/6015921/)
> - do not clear __GFP_NORETRY, as it might come from the caller,
> - s/positive order/order higher than 0/.
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 83cd5ac..3f1ac51 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -1150,13 +1150,28 @@ static struct page **__iommu_alloc_buffer(struct device *dev, size_t size,
> gfp |= __GFP_NOWARN | __GFP_HIGHMEM;
>
> while (count) {
> - int j, order = __fls(count);
> + int j, order;
> +
> + for (order = __fls(count); order > 0; --order) {
> + /*
> + * We do not want OOM killer to be invoked as long
> + * as we can fall back to single pages, so we force
> + * __GFP_NORETRY for orders higher than zero.
> + */
> + pages[i] = alloc_pages(gfp | __GFP_NORETRY, order);
> + if (pages[i])
> + break;
> + }
>
> - pages[i] = alloc_pages(gfp, order);
> - while (!pages[i] && order)
> - pages[i] = alloc_pages(gfp, --order);
> - if (!pages[i])
> - goto error;
> + if (!pages[i]) {
> + /*
> + * Fall back to single page allocation.
> + * Might invoke OOM killer as last resort.
> + */
> + pages[i] = alloc_pages(gfp, 0);
I think down the code in this while loop, i & count is being
calculated based on the "order" of allocation in the current
iteration.
Since value of order will be automatically 0 here if (!pages[i]) is
true then, why hard code order to value of 0 here.
Comment clearly says what this code is doing right?
I know it is just a minor thing. Don't know if it is relevant.
> + if (!pages[i])
> + goto error;
> + }
>
> if (order) {
> split_page(pages[i], order);
> --
> 2.2.0.rc0.207.ga3a616c
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Thanks
Ritesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists