Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp546584ybh; Tue, 21 Jul 2020 01:43:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxdr5eV0dfadIloqG042YtW0eRd7doaLgItSY46jIhCE5YJaIlBWcwR9VXr8IdETDhEYQX0 X-Received: by 2002:aa7:c656:: with SMTP id z22mr25825556edr.101.1595321003902; Tue, 21 Jul 2020 01:43:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595321003; cv=none; d=google.com; s=arc-20160816; b=YU+71atRxZpQmY6SHWCRKLh3TJRlri1ifFcpbqOlNjYmzqbCUvlFqM3TbdOvyhqR55 EeNf0S/hWo7/OIrOaeqwLug46+iJg9DveV+HW4M4qBDzKcL5qyBfKo8jO490tJ7B9lCX 8Kc+PfG1cDeS6OBVQYNE5X+HcBP/b6ZymFsgdc8aA0j/wqJum0ZzPLJl8EqCDOFtpFaN vu7nsq6KEiZm94PV9BRvTtqv0PoCeOq9RIRkLi9amI/vxV0dwSsSdGe3+o7663MHpAXn MCmTYad8ZS0/z1o/9GhXrM/c2BMaRbLX7np5UxAgQaaKB7Kot0qoMQ9LPk6IwvR5IDD0 7qdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=+hog6EawwpdWlxkf+2FCEG/kJYjyb4OaQKT1Wa53XQg=; b=EKDBaWKnafplUUXswbpj3R7TqOpR9ryVE2clPsUUhrqY6UThoEFWQ1IrAjUMnRNuSt kDkjlj4LBcXIqaUjEODGuRR7CTTVhFuxumzmeZvsHvEkCiFGV16pSbfvk7BIMmUE+6wG 3cKfEy0ouvlcBJGLIRKOkxtO1S341UA4nXraO1psgJCPruhUCaadj4cjd6AQynujZbLn Fkvt8wWyqG2fcuwAkVnGzME8nv+5QnqnjUXl6NDi5YG6VcfCi/F7a7HmG+Fz1/h5MVTU A1RMvDts9HDXtfrSKBOz/O7+TFRRvagZn0bnKgGe6jfVX4Fjn1dvdnRXdFMqInvzhecl iYdQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h25si13032479edv.231.2020.07.21.01.43.01; Tue, 21 Jul 2020 01:43:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728874AbgGUIjx (ORCPT + 99 others); Tue, 21 Jul 2020 04:39:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:44680 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728418AbgGUIjx (ORCPT ); Tue, 21 Jul 2020 04:39:53 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 080F5AC46; Tue, 21 Jul 2020 08:39:58 +0000 (UTC) Message-ID: <550b30a86c0785049d24c945e2c6628d491cee3a.camel@suse.de> Subject: Re: [PATCH] dma-pool: Do not allocate pool memory from CMA From: Nicolas Saenz Julienne To: Amit Pundir Cc: Christoph Hellwig , Marek Szyprowski , Robin Murphy , David Rientjes , linux-rpi-kernel@lists.infradead.org, jeremy.linton@arm.com, iommu@lists.linux-foundation.org, lkml , John Stultz , Sumit Semwal Date: Tue, 21 Jul 2020 10:39:49 +0200 In-Reply-To: References: <20200708164936.9340-1-nsaenzjulienne@suse.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.3-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Amit, On Tue, 2020-07-21 at 12:51 +0530, Amit Pundir wrote: > On Wed, 8 Jul 2020 at 22:43, Nicolas Saenz Julienne > wrote: > > There is no guarantee to CMA's placement, so allocating a zone > > specific > > atomic pool from CMA might return memory from a completely > > different > > memory zone. So stop using it. > > > > Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to > > map to gfp mask") > > Hi Nicolas, > > I see a boot regression with this commit d9765e41d8e9 "dma-pool: > Do not allocate pool memory from CMA" on my Xiaomi Poco F1 > (Qcom sdm845) phone running v5.8-rc6. I can't boot past the > bootloader splash screen with this patch. > > Phone boots fine if I revert this patch. I carry only one out of tree > dts patch https://lkml.org/lkml/2020/6/25/52. And since this is a > stock > phone, I don't have access to serial/dmesg logs until I boot to AOSP > (adb) shell. > > Any thoughts as to what might be going wrong here? I'd be happy to > help debug things. For what it's worth, I don't see this regression > on > other two sdm845 devices (db845c and Pixel 3) I tested on. Can you provide a boot log (even if without my patch) and the device- tree files? It'd help a lot figuring things out. Regards, Nicolas > Regards, > Amit Pundir > > > Reported-by: Jeremy Linton > > Signed-off-by: Nicolas Saenz Julienne > > --- > > > > An more costly alternative would be adding an option to > > dma_alloc_from_contiguous() so it fails when the allocation doesn't > > fall > > in a specific zone. > > > > kernel/dma/pool.c | 11 ++--------- > > 1 file changed, 2 insertions(+), 9 deletions(-) > > > > diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c > > index 8cfa01243ed2..4bc1c46ae6ef 100644 > > --- a/kernel/dma/pool.c > > +++ b/kernel/dma/pool.c > > @@ -6,7 +6,6 @@ > > #include > > #include > > #include > > -#include > > #include > > #include > > #include > > @@ -69,12 +68,7 @@ static int atomic_pool_expand(struct gen_pool > > *pool, size_t pool_size, > > > > do { > > pool_size = 1 << (PAGE_SHIFT + order); > > - > > - if (dev_get_cma_area(NULL)) > > - page = dma_alloc_from_contiguous(NULL, 1 << > > order, > > - order, > > false); > > - else > > - page = alloc_pages(gfp, order); > > + page = alloc_pages(gfp, order); > > } while (!page && order-- > 0); > > if (!page) > > goto out; > > @@ -118,8 +112,7 @@ static int atomic_pool_expand(struct gen_pool > > *pool, size_t pool_size, > > dma_common_free_remap(addr, pool_size); > > #endif > > free_page: __maybe_unused > > - if (!dma_release_from_contiguous(NULL, page, 1 << order)) > > - __free_pages(page, order); > > + __free_pages(page, order); > > out: > > return ret; > > } > > -- > > 2.27.0 > >