linux-kernel - Re: [PATCH] riscv: make ZONE

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:
 <VI1PR09MB233391A7544336FBD06303CE946E2@VI1PR09MB2333.eurprd09.prod.outlook.com>
Date: Sun, 22 Sep 2024 10:06:59 +0000
From: Vladimir Kondratiev <Vladimir.Kondratiev@...ileye.com>
To: Christoph Hellwig <hch@...radead.org>
CC: Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt
	<palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>, Andrew Morton
	<akpm@...ux-foundation.org>, "linux-riscv@...ts.infradead.org"
	<linux-riscv@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>
Subject: Re: [PATCH] riscv: make ZONE_DMA32 optional

>On Tue, Aug 27, 2024 at 02:36:11PM +0300, Vladimir Kondratiev wrote:
>> It is not necessary any RISCV platform has ZONE_DMA32.

>That is an odd statement.  The point of ZONE_DMA32 is to make sure
>that drivers can always allocate 32-bit DMAable memory, and without
>ZONE_DMA32 that is very hard to provide unless you always have an
>IOMMU.

This is the whole point - there are platforms where you can't allocate 32-bit
dma-able memory.
Unless there's IOMMU or some platform specific tricks,
DMA address is same as physical address.
In my example, platform has DRAM installed at address 32Gbytes.
32-bit devices would not work on such platform, and attempt to allocate
ZONE_DMA32 memory fails and kernel prints warning as in my original post

>ZONE_DMA32 is supposed to contain the 32-bit dma addressable memory,
>not 32-bit physical.

>Take a look at the changes that just went into Linus' tree for that.

I re-evaluated with Linus's tree as of now (commit 88264981f208), same error reported if I don't apply my patch:

[    0.191514] DMA: preallocated 512 KiB GFP_KERNEL pool for atomic allocations
[    0.191524] swapper/0: page allocation failure: order:7, mode:0xcc4(GFP_KERNEL|GFP_DMA32), nodemask=(null),cpuset=/,mem
s_allowed=0
[    0.191546] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0 #2
[    0.191553] Hardware name: ????  (DT)
[    0.191556] Call Trace:
[    0.191560] [<ffffffff800059bc>] dump_backtrace+0x1c/0x24
[    0.191571] [<ffffffff805d1a3c>] show_stack+0x2c/0x38
[    0.191578] [<ffffffff805dc1e6>] dump_stack_lvl+0x52/0x74
[    0.191584] [<ffffffff805dc21c>] dump_stack+0x14/0x1c
[    0.191589] [<ffffffff801a8eec>] warn_alloc+0xf4/0x180
[    0.191598] [<ffffffff801a98e8>] __alloc_pages_noprof+0x970/0xd94
[    0.191605] [<ffffffff8008d2ae>] atomic_pool_expand+0x62/0x1f8
[    0.191615] [<ffffffff8060d6ae>] __dma_atomic_pool_init+0x46/0x9e
[    0.191620] [<ffffffff8060d79c>] dma_atomic_pool_init+0x96/0x11c
[    0.191626] [<ffffffff80002146>] do_one_initcall+0x5c/0x1b2
[    0.191631] [<ffffffff8060127c>] kernel_init_freeable+0x214/0x274
[    0.191636] [<ffffffff805dd9e4>] kernel_init+0x1e/0x10a
[    0.191644] [<ffffffff805e6eba>] ret_from_fork+0xe/0x1c
[    0.191709] Mem-Info:
[    0.191714] active_anon:0 inactive_anon:0 isolated_anon:0
[    0.191714]  active_file:0 inactive_file:0 isolated_file:0
[    0.191714]  unevictable:0 dirty:0 writeback:0
[    0.191714]  slab_reclaimable:26 slab_unreclaimable:742
[    0.191714]  mapped:0 shmem:0 pagetables:65
[    0.191714]  sec_pagetables:0 bounce:0
[    0.191714]  kernel_misc_reclaimable:0
[    0.191714]  free:1014355 free_pcp:0 free_cma:0
[    0.191727] 0 total pagecache pages
[    0.191730] 1048576 pages RAM
[    0.191733] 0 pages HighMem/MovableOnly
[    0.191735] 30264 pages reserved
[    0.191743] DMA: failed to allocate 496 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocation