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: <2c0e2fbe-4e45-4acc-c2a7-4f4dcf9161a3@microchip.com>
Date:   Wed, 11 May 2022 10:10:40 +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>
Subject: Re: linux-next: Tree for May 3

On 11/05/2022 07:48, Christoph Hellwig wrote:
> On Wed, May 11, 2022 at 06:44:22AM +0000, Conor.Dooley@...rochip.com wrote:
>> On 11/05/2022 07:22, Christoph Hellwig wrote:
>>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>>
>>> Can you try this patch?
>>
>> Hey Christoph, gave it a try but nfortunately, no joy!
> 
> Yes, while it is a real fix, the problem it fixes can only happen
> with Xen, which is not relevant to riscv.  The only other thing I
> can think off is that the allocations were always failing on your
> board, and the patch makes that failure fatal.  For that try the
> patch below.  I'd also be really curious by now about the kernel
> logs from a successful boot.

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.

Thanks,
Conor.

Here's the start of a boot log from v5.18-rc6:
[    0.000000] Linux version 5.18.0-rc6-dirty (conor@...dy) (riscv64-unknown-linux-gnu-gcc (GCC) 10.2.0, GNU ld (GNU B
inutils) 2.36.1) #1 SMP Tue May 10 08:25:21 IST 2022
[    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]
[    0.000000] SBI specification v0.3 detected
[    0.000000] SBI implementation ID=0x1 Version=0x9
[    0.000000] SBI TIME extension detected
[    0.000000] SBI IPI extension detected
[    0.000000] SBI RFENCE extension detected
[    0.000000] SBI HSM extension detected
[    0.000000] CPU with hartid=0 is not available
[    0.000000] CPU with hartid=0 is not available
[    0.000000] riscv: base ISA extensions acdfim
[    0.000000] riscv: ELF capabilities acdfim
[    0.000000] percpu: Embedded 18 pages/cpu s34040 r8192 d31496 u73728
[    0.000000] pcpu-alloc: s34040 r8192 d31496 u73728 alloc=18*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 258055
[    0.000000] Kernel command line: earlycon=sbi debug
[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] software IO TLB: Cannot allocate buffer
[    0.000000] Virtual kernel memory layout:
[    0.000000]       fixmap : 0xffffffc6fee00000 - 0xffffffc6ff000000   (2048 kB)
[    0.000000]       pci io : 0xffffffc6ff000000 - 0xffffffc700000000   (  16 MB)
[    0.000000]      vmemmap : 0xffffffc700000000 - 0xffffffc800000000   (4096 MB)
[    0.000000]      vmalloc : 0xffffffc800000000 - 0xffffffd800000000   (65536 MB)
[    0.000000]       lowmem : 0xffffffd800000000 - 0xffffffd83fe00000   (1022 MB)
[    0.000000]       kernel : 0xffffffff80000000 - 0xffffffffffffffff   (2047 MB)
[    0.000000] Memory: 991276K/1046528K available (6534K kernel code, 4865K rwdata, 2048K rodata, 2165K init, 334K bss
, 55252K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
--8<--

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ