linux-kernel - Re: linux-next: Tree for May 3

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]

Date:   Fri, 13 May 2022 07:55:14 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <hch@....de>
CC:     <sfr@...b.auug.org.au>, <linux-next@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-riscv@...ts.infradead.org>,
        <rppt@...nel.org>
Subject: Re: linux-next: Tree for May 3

On 11/05/2022 13:37, Christoph Hellwig wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> On Wed, May 11, 2022 at 10:10:40AM +0000, Conor.Dooley@...rochip.com wrote:
>> Without even trying the patch, I double checked the boot log from
>> 3f70356edf56 and I get a "software IO TLB: Cannot allocate buffer"
>> With the patch its a "software IO TLB: swiotlb_init_remap: failed
>> to allocate tlb structure". So spot on & I feel like an idiot for
>> not spotting that before!
>>
>> Is failing being fatal valid, or should it fail gracefully like it
>> used to do? To me, blissfully unaware about swiotlb, the "current"
>> behaviour of failing gracefully makes more sense.
> 
> Given that we're at -rc6 I think the most important thing for now is to
> avoid a regression and restore the old behavior.  I'll send out a
> series with this and the nslab related fixes for Xen today.
> 
> But we should look into why allocating the memory fails for your
> plaforms.  Does it have very little memory?  I can't really think
> of why else the memblock allocation for swiotlb would fail.

My assumption would be that it is the complete lack of usable memory
at 32 bit bit addresses? Even though there is memory physically there
it is just being ignored as you can see in the boot log (because it's
below the entry point?).

My question is, does failing to even boot make sense if that buffer
can't be allocated? Can argue that SWIOTLB should'nt be enabled in the
first place if there is no DMA32, but if it is enabled in error would
it not be better to at least let the system boot & spit out an uglier
warning?
(Obviously I missed the current warning, hence the "uglier" bit.)

Thanks,
Conor.

(readding log for context)
[    0.000000] OF: fdt: Ignoring memory block 0x80000000 - 0xae000000
[    0.000000] OF: fdt: Ignoring memory range 0x1000000000 - 0x1000200000
[    0.000000] Machine model: Microchip PolarFire-SoC Icicle Kit
[    0.000000] efi: UEFI not found.
[    0.000000] Zone ranges:
[    0.000000]   DMA32    empty
[    0.000000]   Normal   [mem 0x0000001000200000-0x000000103fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000001000200000-0x000000103fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000001000200000-0x000000103fffffff]