linux-kernel - Re: bisected crash due to "x86: Move swiotlb initialization before dma32_free

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: <20091215175439V.fujita.tomonori@lab.ntt.co.jp>
Date:	Tue, 15 Dec 2009 17:55:14 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	rdreier@...co.com
Cc:	linux-kernel@...r.kernel.org, fujita.tomonori@....ntt.co.jp,
	mingo@...e.hu, yinghai@...nel.org
Subject: Re: bisected crash due to "x86: Move swiotlb initialization before
 dma32_free_bootmem"

On Mon, 14 Dec 2009 23:47:07 -0800
Roland Dreier <rdreier@...co.com> wrote:

> I have a big box (64 threads, 256GB memory) that is crashing early in
> boot as below.  I bisected it down to f4780ca0 ("x86: Move swiotlb
> initialization before dma32_free_bootmem"); reverting just this commit
> from the latest git (3ea6b3d0 is what I tested) fixes things.

Ah, really sorry about that.


> I haven't tried to debug this yet, but I guess on such a huge box there
> is not enough memory below 4GB for swiotlb if we don't free the 

Yeah, Yinghai also hit this (his box has more memory than yours).


> stuff allocated earlier?  I don't know why that would be, since the
> bootmem is grabbing 512MB and I have pretty close to 4GB below 4GB.
> Anyway, I'm going to go to bed soon, but if you need more information or
> have anything you want me to try, I will do it tomorrow morning.

http://www.kernel.org/pub/linux/kernel/people/tomo/misc/0001-x86-two-stage-swiotlb-initialization.patch

It makes the swiotlb initialization into two stages. I don't like it
much since I like to avoid complicating the initialization.

dma32_reserve_bootmem() allocates 128MB for broken GART IOMMU but I
think 64MB should be enough since broken GART IOMMU allocates
64MB. The following simple patch might work too because swiotlb uses
64MB.

With coming huge memory boxes, we might need to work on ZONE_DMA32
shortage issue anyway (sparse-vmemmap, anything else)?


diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 75e14e2..fbe7154 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -67,7 +67,7 @@ EXPORT_SYMBOL(dma_set_mask);
 
 #ifdef CONFIG_X86_64
 static __initdata void *dma32_bootmem_ptr;
-static unsigned long dma32_bootmem_size __initdata = (128ULL<<20);
+static unsigned long dma32_bootmem_size __initdata = (64ULL<<20);
 
 static int __init parse_dma32_size_opt(char *p)
 {
--
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/