Re: [PATCH] powerpc/xive: Add missing null check after calling kmalloc
On 12/26/21 14:54, Ammar Faizi wrote:
Commit 930914b7d528fc ("powerpc/xive: Add a debugfs file to dump
internal XIVE state") forgot to add a null check.
Add it.
Cc: Cédric Le Goater
Cc: Michael Ellerman
Fixes: 930914b7d528fc6b0249bffc00564100bcf6ef75 ("powerpc/xive: Add a debugfs file
to dump internal XIVE state")
Signed-off-by: Ammar Faizi
Reviewed-by: Cédric Le Goater
Thanks,
C.
Re: [BUG] powerpc: test_progs -t for_each faults kernel
Hi Jiri, Jiri Olsa wrote: hi, when running 'test_progs -t for_each' on powerpc we are getting the fault below This looks to be the same issue reported by Yauheni: http://lkml.kernel.org/r/xunylf0o872l@redhat.com Can you please check if the patch I posted there fixes it for you? Thanks, Naveen
microwatt booting linux-5.7 under verilator
i am pleased to be able to announce the successful booting of microwatt-5.7 linux buildroot... under a veriilator simulation of the microwatt VHDL. from a hardware development and research perspective this is highly significant because unlike the FPGA boot which was previously reported, https://shenki.github.io/boot-linux-on-microwatt/ full memory read/write snooping and full Signal tracing (gtkwave) is possible. https://ftp.libre-soc.org/microwatt-linux-5.7-verilator-boot-buildroot.txt the branch of microwatt HDL which is being used is here https://git.libre-soc.org/?p=microwatt.git;a=shortlog;h=refs/heads/verilator_trace some minor strategic changes to microwatt HDL were required, including adding a new SYSCON parameter to specify a BRAM chain-boot address, and also it was necessary to turn sdram_init into a stand-alone "mini-BIOS" which performed the role of early-initialising the 16550 uart followed by chain-loading to the BRAM chain-boot memory location, at which the linux 5.7 dtbImage.microwatt had been loaded (0x60). microwatt-verilator.cpp itself needed some changes to add support for emulation in c++ of 512 mbyte of "Block" RAM. the interface for BRAM (aka SRAM) was far simpler than attempting to emulate DRAM, and also meant that much of the mini-BIOS could be entirely cut. i also had to further modify microwatt-verilator.cpp to allow it to load from files directly into memory, at run-time. this means it is possible to execute hello_world.bin, zephyr.bin, micropython.bin, dtbImage-microwatt all without recompiling the verilator binary. (not that you want to try compiling a 6 MB binary into VHDL like i did: it resulted in the creation of a 512 MB verilog file which, at 60 GB resident RAM by verilator attempting to compile that to c++, i decided that mayyybe doing that at runtime was a better approach?) i also had to fix a couple of things in the linux kernel source https://git.kernel.org/pub/scm/linux/kernel/git/joel/microwatt.git first attempts to boot a compressed image were quite hilarious: a quick back-of-the-envelope calculation by examining the rate at which LD/STs were being generated showed that the GZIP decompression would complete maybe some time in about 1 hour of real-world time. this led me to add support for CONFIG_KERNEL_UNCOMPRESSED and cut that time entirely, hence why you can see this in the console log: 0x5b0e10 bytes of uncompressed data copied secondly, the microwatt Makefile assumes that verilator clock rate runs at 50 mhz, where the microwatt.dts file says 100 mhz for both the UART clock as well as the system clock. it would be really nice to have microwatt-linux read the SYSCON parameter for the clock rate, and for that to be dynamically inserted into the dtb. however in the interim, the attached patch suffices by manually altering the clock in microwatt.dts to match that of the SYSCON parameter. the initial boots without sdram_init.bin did not go well. this is probably because the udbg0 (early ns16550.c) is not correctly initialised (critically relying on the use of the microwatt console_init() library). what was great - and this really is the whole point - i was able to track down the source of the problem... by examining the VCD trace wires of the 16550 Wishbone Bus and internal UART registers... from the HDL! :) if there had been such a problem on the FPGA side, that would have been outright impossible and impractical. for anyone thinking of following this and using it, please be under no illusion: it took *two hours* to get to that boot prompt on a 4.8ghz Intel i9. 1000 ns of "simulated" 50 mhz clock rate takes a stunning 15-20 seconds of real time. you can do the math on the number of instructions per second, there, but the huge advantage is: direct snoop access to the memory, and the entire signal tracing of the HDL - all of it: every single signal, for every single cycle. the other downside: running for even 30 seconds produces an astounding *10 gigabytes* of VCD trace log output. normally you would switch on command-line options in verilator to only enable the VCD tracing at certain ranges of clock cycles, so that you have access to the Signals that you are interested in. i have seen people enable that over a debug interface (from a separate program, communicating with the verilator executable) but that is outside the scope of this message. the next task will be to swap out the microwatt core and drop in the libresoc core. with the successful passing of 17/19 of the microwatt mmu.bin unit tests last week this is expected to be relatively straightforward, especially given that we already have microwatt-compatible XICS, microwatt-compatible DMI, exactly the same sized I and D wishbone buses, and a direct port of microwatt's MMU, L1 and D1 Caches. missing is a SYSCON device and the Wishbone Bus Arbiter. however once that (relatively straightforward) work is done, we will be able to boot the *exact* same linux buildroot image (and i
[BUG] powerpc: test_progs -t for_each faults kernel
hi, when running 'test_progs -t for_each' on powerpc we are getting the fault below it seems that for some reason the function callback address passed to bpf_for_each_array_elem is wrong.. I wonder it's the powerpc function pointers magic ;-) it's the latest bpf-next/master, I can send .config if needed thanks, jirka --- [ 114.362271] kernel tried to execute user page (1) - exploit attempt? (uid: 0) [ 114.362284] BUG: Unable to handle kernel instruction fetch [ 114.362288] Faulting instruction address: 0x1 [ 114.362294] Oops: Kernel access of bad area, sig: 11 [#1] [ 114.362299] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [ 114.362309] Modules linked in: bpf_testmod(OE) bonding tls rfkill pseries_rng ibmveth crct10dif_vpmsum drm fuse i2c_core drm_panel_orientation_quirks zram ip_tables ibmvscsi scsi_transport_srp vmx_crypto crc32c_vpmsum [ 114.362339] CPU: 5 PID: 935 Comm: test_progs Tainted: G OE 5.16.0-rc7+ #3 [ 114.362345] NIP: 0001 LR: c0378a24 CTR: 00010001 [ 114.362350] REGS: c00015ef36e0 TRAP: 0400 Tainted: G OE (5.16.0-rc7+) [ 114.362355] MSR: 80004280b033 CR: 88008248 XER: 2004 [ 114.362371] CFAR: c0378a20 IRQMASK: 0 GPR00: c03789bc c00015ef3980 c2890900 ccbb0200 GPR04: c00015ef39ec ccbb0310 c00015ef3a48 GPR08: 0001fd9a 0003 2000 GPR12: 00010001 c0001ecab080 GPR16: c00017a48400 GPR20: 0001 c00015ef3ac0 c00015ef3b7c GPR24: c00015ef3b78 c00802e4 c00802e40048 c00015ef3a48 GPR28: ccbb0310 00010001 ccbb0200 0001 [ 114.362431] NIP [0001] 0x1 [ 114.362436] LR [c0378a24] bpf_for_each_array_elem+0xc4/0x1c0 [ 114.362443] Call Trace: [ 114.362445] [c00015ef3980] [c03789bc] bpf_for_each_array_elem+0x5c/0x1c0 (unreliable) [ 114.362454] [c00015ef3a20] [c008032267dc] bpf_prog_21bfb2cd0ec79d94_F+0xac/0x98d0 [ 114.362461] [c00015ef3a90] [c0f54308] bpf_test_run+0x208/0x420 [ 114.362469] [c00015ef3b50] [c0f551b8] bpf_prog_test_run_skb+0x368/0x7a0 [ 114.362478] [c00015ef3bf0] [c034bf40] __sys_bpf+0xc20/0x2e20 [ 114.362486] [c00015ef3d90] [c034e1dc] sys_bpf+0x2c/0x40 [ 114.362495] [c00015ef3db0] [c002d478] system_call_exception+0x188/0x360 [ 114.362505] [c00015ef3e10] [c000bfe8] system_call_vectored_common+0xe8/0x278 [ 114.362514] --- interrupt: 3000 at 0x7fff813dc9fc [ 114.362520] NIP: 7fff813dc9fc LR: CTR: [ 114.362526] REGS: c00015ef3e80 TRAP: 3000 Tainted: G OE (5.16.0-rc7+) [ 114.362532] MSR: 8280f033 CR: 48002848 XER: [ 114.362552] IRQMASK: 0 GPR00: 0169 7fffe3429c10 7fff814e6f00 000a GPR04: 7fffe3429cb8 0090 0008 GPR08: 000a GPR12: 7fff8164b7d0 GPR16: GPR20: GPR24: 101baa4c 7fffe342a520 1056f5d8 7fff8163eb68 GPR28: 7fffe342a6a8 7fffe342a4f8 0004 7fffe3429c10 [ 114.362626] NIP [7fff813dc9fc] 0x7fff813dc9fc [ 114.362631] LR [] 0x0 [ 114.362636] --- interrupt: 3000 [ 114.362640] Instruction dump: [ 114.362646] [ 114.362661] [ 114.362675] ---[ end trace c044e1b381f36402 ]---
[PATCH] floppy: Remove usage of the deprecated "pci-dma-compat.h" API
In [1], Christoph Hellwig has proposed to remove the wrappers in
include/linux/pci-dma-compat.h.
Some reasons why this API should be removed have been given by Julia
Lawall in [2].
A coccinelle script has been used to perform the needed transformation
Only relevant parts are given below.
@@ @@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE
@@ @@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE
@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(>dev, e2, e3, e4)
@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(>dev, e2, e3, e4)
[1]:
https://lore.kernel.org/kernel-janitors/20200421081257.ga131...@infradead.org/
[2]:
https://lore.kernel.org/kernel-janitors/alpine.DEB.2.22.394.2007120902170.2424@hadrien/
Signed-off-by: Christophe JAILLET
---
arch/powerpc/include/asm/floppy.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/floppy.h
b/arch/powerpc/include/asm/floppy.h
index 7af9a68fd949..f8ce178b43b7 100644
--- a/arch/powerpc/include/asm/floppy.h
+++ b/arch/powerpc/include/asm/floppy.h
@@ -134,17 +134,19 @@ static int hard_dma_setup(char *addr, unsigned long size,
int mode, int io)
int dir;
doing_vdma = 0;
- dir = (mode == DMA_MODE_READ) ? PCI_DMA_FROMDEVICE : PCI_DMA_TODEVICE;
+ dir = (mode == DMA_MODE_READ) ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
if (bus_addr
&& (addr != prev_addr || size != prev_size || dir != prev_dir)) {
/* different from last time -- unmap prev */
- pci_unmap_single(isa_bridge_pcidev, bus_addr, prev_size,
prev_dir);
+ dma_unmap_single(_bridge_pcidev->dev, bus_addr, prev_size,
+prev_dir);
bus_addr = 0;
}
if (!bus_addr) /* need to map it */
- bus_addr = pci_map_single(isa_bridge_pcidev, addr, size, dir);
+ bus_addr = dma_map_single(_bridge_pcidev->dev, addr, size,
+ dir);
/* remember this one as prev */
prev_addr = addr;
--
2.32.0
