pinctrl: starfive: improve register field documentation#34
Closed
pdp7 wants to merge 57 commits intoesmil:beaglev-pinctrlfrom
pdp7:beaglev-pinctrl-improve-naming
Closed
pinctrl: starfive: improve register field documentation#34pdp7 wants to merge 57 commits intoesmil:beaglev-pinctrlfrom pdp7:beaglev-pinctrl-improve-naming
pdp7 wants to merge 57 commits intoesmil:beaglev-pinctrlfrom
pdp7:beaglev-pinctrl-improve-naming
Conversation
Pin the task's stack before calling walk_stackframe() in get_wchan(). This can fix the panic as reported by Andreas when CONFIG_VMAP_STACK=y: [ 65.609696] Unable to handle kernel paging request at virtual address ffffffd0003bbde8 [ 65.610460] Oops [#1] [ 65.610626] Modules linked in: virtio_blk virtio_mmio rtc_goldfish btrfs blake2b_generic libcrc32c xor raid6_pq sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs [ 65.611670] CPU: 2 PID: 1 Comm: systemd Not tainted 5.14.0-rc1-1.g34fe32a-default #1 openSUSE Tumbleweed (unreleased) c62f7109153e5a0897ee58ba52393ad99b070fd2 [ 65.612334] Hardware name: riscv-virtio,qemu (DT) [ 65.613008] epc : get_wchan+0x5c/0x88 [ 65.613334] ra : get_wchan+0x42/0x88 [ 65.613625] epc : ffffffff800048a4 ra : ffffffff8000488a sp : ffffffd00021bb90 [ 65.614008] gp : ffffffff817709f8 tp : ffffffe07fe91b80 t0 : 00000000000001f8 [ 65.614411] t1 : 0000000000020000 t2 : 0000000000000000 s0 : ffffffd00021bbd0 [ 65.614818] s1 : ffffffd0003bbdf0 a0 : 0000000000000001 a1 : 0000000000000002 [ 65.615237] a2 : ffffffff81618008 a3 : 0000000000000000 a4 : 0000000000000000 [ 65.615637] a5 : ffffffd0003bc000 a6 : 0000000000000002 a7 : ffffffe27d370000 [ 65.616022] s2 : ffffffd0003bbd90 s3 : ffffffff8071a81e s4 : 0000000000003fff [ 65.616407] s5 : ffffffffffffc000 s6 : 0000000000000000 s7 : ffffffff81618008 [ 65.616845] s8 : 0000000000000001 s9 : 0000000180000040 s10: 0000000000000000 [ 65.617248] s11: 000000000000016b t3 : 000000ff00000000 t4 : 0c6aec92de5e3fd7 [ 65.617672] t5 : fff78f60608fcfff t6 : 0000000000000078 [ 65.618088] status: 0000000000000120 badaddr: ffffffd0003bbde8 cause: 000000000000000d [ 65.618621] [<ffffffff800048a4>] get_wchan+0x5c/0x88 [ 65.619008] [<ffffffff8022da88>] do_task_stat+0x7a2/0xa46 [ 65.619325] [<ffffffff8022e87e>] proc_tgid_stat+0xe/0x16 [ 65.619637] [<ffffffff80227dd6>] proc_single_show+0x46/0x96 [ 65.619979] [<ffffffff801ccb1e>] seq_read_iter+0x190/0x31e [ 65.620341] [<ffffffff801ccd70>] seq_read+0xc4/0x104 [ 65.620633] [<ffffffff801a6bfe>] vfs_read+0x6a/0x112 [ 65.620922] [<ffffffff801a701c>] ksys_read+0x54/0xbe [ 65.621206] [<ffffffff801a7094>] sys_read+0xe/0x16 [ 65.621474] [<ffffffff8000303e>] ret_from_syscall+0x0/0x2 [ 65.622169] ---[ end trace f24856ed2b8789c5 ]--- [ 65.622832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
There were two causes for the overrun memory access. The threshold size was too small. The aligning dst require one SZREG and unrolling word copy requires 8*SZREG, total have to be at least 9*SZREG. Inside the unrolling copy, the subtracting -(8*SZREG-1) would make iteration happening one extra loop. Proper value is -(8*SZREG). Signed-off-by: Akira Tsukamoto <akira.tsukamoto@gmail.com> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Qiu Wenbo <qiuwenbo@kylinos.com.cn>
Had a bug when converting bytes to bits when the cpu was rv32. The a3 contains the number of bytes and multiple of 8 would be the bits. The LGREG is holding 2 for RV32 and 3 for RV64, so to achieve multiple of 8 it must always be constant 3. The 2 was mistakenly used for rv32. Signed-off-by: Akira Tsukamoto <akira.tsukamoto@gmail.com> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Qiu Wenbo <qiuwenbo@kylinos.com.cn>
Clean up: The size of 0 will be evaluated in the next step. Not required here. Signed-off-by: Akira Tsukamoto <akira.tsukamoto@gmail.com> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Qiu Wenbo <qiuwenbo@kylinos.com.cn>
Fixing typos and grammar mistakes and using more intuitive label name. Signed-off-by: Akira Tsukamoto <akira.tsukamoto@gmail.com> Tested-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Qiu Wenbo <qiuwenbo@kylinos.com.cn>
Patch series "lib/string: optimized mem* functions", v2.
Rewrite the generic mem{cpy,move,set} so that memory is accessed with the
widest size possible, but without doing unaligned accesses.
This was originally posted as C string functions for RISC-V[1], but as
there was no specific RISC-V code, it was proposed for the generic
lib/string.c implementation.
Tested on RISC-V and on x86_64 by undefining __HAVE_ARCH_MEM{CPY,SET,MOVE}
and HAVE_EFFICIENT_UNALIGNED_ACCESS.
These are the performances of memcpy() and memset() of a RISC-V machine on
a 32 mbyte buffer:
memcpy:
original aligned: 75 Mb/s
original unaligned: 75 Mb/s
new aligned: 114 Mb/s
new unaligned: 107 Mb/s
memset:
original aligned: 140 Mb/s
original unaligned: 140 Mb/s
new aligned: 241 Mb/s
new unaligned: 241 Mb/s
The size increase is negligible:
$ scripts/bloat-o-meter vmlinux.orig vmlinux
add/remove: 0/0 grow/shrink: 4/1 up/down: 427/-6 (421)
Function old new delta
memcpy 29 351 +322
memset 29 117 +88
strlcat 68 78 +10
strlcpy 50 57 +7
memmove 56 50 -6
Total: Before=8556964, After=8557385, chg +0.00%
These functions will be used for RISC-V initially.
[1] https://lore.kernel.org/linux-riscv/20210617152754.17960-1-mcroce@linux.microsoft.com/
This patch (of 3):
Rewrite the generic memcpy() to copy a word at time, without generating
unaligned accesses.
The procedure is made of three steps: First copy data one byte at time
until the destination buffer is aligned to a long boundary. Then copy the
data one long at time shifting the current and the next long to compose a
long at every cycle. Finally, copy the remainder one byte at time.
This is the improvement on RISC-V:
original aligned: 75 Mb/s
original unaligned: 75 Mb/s
new aligned: 114 Mb/s
new unaligned: 107 Mb/s
and this the binary size increase according to bloat-o-meter:
Function old new delta
memcpy 36 324 +288
Link: https://lkml.kernel.org/r/20210702123153.14093-1-mcroce@linux.microsoft.com
Link: https://lkml.kernel.org/r/20210702123153.14093-2-mcroce@linux.microsoft.com
Signed-off-by: Matteo Croce <mcroce@microsoft.com>
Cc: Nick Kossifidis <mick@ics.forth.gr>
Cc: Guo Ren <guoren@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: David Laight <David.Laight@aculab.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Emil Renner Berthing <kernel@esmil.dk>
Cc: Drew Fustini <drew@beagleboard.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
When the destination buffer is before the source one, or when the buffers doesn't overlap, it's safe to use memcpy() instead, which is optimized to use a bigger data size possible. This "optimization" only covers a common case. In future, proper code which does the same thing as memcpy() does but backwards can be done. Link: https://lkml.kernel.org/r/20210702123153.14093-3-mcroce@linux.microsoft.com Signed-off-by: Matteo Croce <mcroce@microsoft.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: David Laight <David.Laight@aculab.com> Cc: Drew Fustini <drew@beagleboard.org> Cc: Emil Renner Berthing <kernel@esmil.dk> Cc: Guo Ren <guoren@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Nick Kossifidis <mick@ics.forth.gr> Cc: Palmer Dabbelt <palmer@dabbelt.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
The generic memset is defined as a byte at time write. This is always safe, but it's slower than a 4 byte or even 8 byte write. Write a generic memset which fills the data one byte at time until the destination is aligned, then fills using the largest size allowed, and finally fills the remaining data one byte at time. On a RISC-V machine the speed goes from 140 Mb/s to 241 Mb/s, and this the binary size increase according to bloat-o-meter: Function old new delta memset 32 148 +116 Link: https://lkml.kernel.org/r/20210702123153.14093-4-mcroce@linux.microsoft.com Signed-off-by: Matteo Croce <mcroce@microsoft.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: David Laight <David.Laight@aculab.com> Cc: Drew Fustini <drew@beagleboard.org> Cc: Emil Renner Berthing <kernel@esmil.dk> Cc: Guo Ren <guoren@kernel.org> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Nick Kossifidis <mick@ics.forth.gr> Cc: Palmer Dabbelt <palmer@dabbelt.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Use the generic routines which handle alignment properly. Signed-off-by: Matteo Croce <mcroce@microsoft.com> Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Add DT binding documentation for the StarFive JH7100 Soc [1] and the BeagleV Starlight JH7100 board [2]. [1] https://github.com/starfive-tech/beaglev_doc [2] https://github.com/beagleboard/beaglev-starlight Signed-off-by: Drew Fustini <drew@beagleboard.org>
Add all clock outputs for the StarFive JH7100 Clock Generator. Based on work by Ahmad Fatoum for Barebox, with "JH7100_" prefixes added to all definitions. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Add all resets for the StarFive JH7100 Reset Controller. Based on work by Ahmad Fatoum for Barebox, with "JH7100_" prefixes added to all definitions. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Add preliminary Device Tree bindings for the StarFive JH7100 Clock Generator. To be verified against documentation when it becomes available. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Make clk_ignore_unused public, so the StarFive JH7100 Clock Generator driver can set the flag. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Add a preliminary driver for the StarFive JH7100 Clock Generator,
based on work by Ahmad Fatoum for Barebox.
Functional differences compared to the Barebox driver:
- Addition of starfive_clk_pll_mult(), to make the PLL outputs
reasonable,
- Add temporary overrides for critical clocks (uart, i2c, spi) until
we get the clock tree right, so we don't have to keep dummy clocks
like uartclk and hs_uartclk in the DTS.
This driver sets clk_ignore_unused, else the system locks up when all
clocks deemed unused are disabled.
To be updated when the documentation becomes available.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Add bindings for the temperature sensor on the StarFive JH7100 SoC. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Reviewed-by: Rob Herring <robh@kernel.org>
Register definitions and conversion constants based on sfctemp driver by Samin in the StarFive 5.10 kernel. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Samin Guo <samin.guo@starfivetech.com>
This converts the tps65086.txt binding description to YAML schema so dts files can be verified automatically. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
The BeagleV Starlight v0.9 board[1] doesn't have the IRQB line routed to the SoC, but it is still useful to be able to reach the PMIC over I2C for the other functionality it provides such as GPIOs and regulator settings. [1] https://github.com/beagleboard/beaglev-starlight Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
The only way to reset the BeagleV Starlight v0.9 board[1] properly is to tell the PMIC to reset itself which will then assert the external reset lines of the SoC, USB hub and ethernet phy. This adds a driver to register a reset handler to do just that. [1] https://github.com/beagleboard/beaglev-starlight Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The only way to reset the BeagleV Starlight v0.9 board[1] properly is to tell the PMIC to reset itself which will then assert the external reset lines of the SoC, USB hub and ethernet phy. This adds an mfd cell entry for the reset driver doing just that. [1] https://github.com/beagleboard/beaglev-starlight Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
The first DMAC instance in the StarFive JH7100 SoC supports 16 DMA
channels.
FIXME Given there are more changes to the driver than just increasing
DMAC_MAX_CHANNELS, we probably need a new compatible value, too.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
This makes it easier to find out which driver passes a wrong address range. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
[Emil: fix suggested by Geert Uytterhoeven <geert@linux-m68k.org>] Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
1, add ov5640&sc2235 drivers, update stf_isp 2, add MIPI/CSI/DSI drivers for VIC7100
This macro was never implemented and completely removed upstream. Signed-off-by: TekkamanV <tekkamanv@starfivetech.com>
Fix sf_fb_map_video_memory in starfive_fb.c
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Signed-off-by: Stephen L Arnold <nerdboy@gentoo.org>
…_EMULATION riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L0 ': tda998x.c:(.text+0x51c): undefined reference to `drm_encoder_cleanup' riscv64-linux-gnu-ld: tda998x.c:(.text+0x534): undefined reference to `drm_encoder_cleanup' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L75': tda998x.c:(.text+0x564): undefined reference to `drm_of_find_possible_crtcs' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `tda998x_encoder_destroy': tda998x.c:(.text+0x58a): undefined reference to `drm_encoder_init' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `tda998x_bind': tda998x.c:(.text+0x5b2): undefined reference to `drm_bridge_attach' riscv64-linux-gnu-ld: tda998x.c:(.text+0x5c0): undefined reference to `drm_encoder_cleanup' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L0 ': tda998x.c:(.text+0x692): undefined reference to `drm_bridge_remove' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L124': tda998x.c:(.text+0x904): undefined reference to `hdmi_infoframe_pack' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L135': tda998x.c:(.text+0x9e8): undefined reference to `drm_connector_cleanup' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L0 ': tda998x.c:(.text+0xa00): undefined reference to `drm_connector_cleanup' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L143': tda998x.c:(.text+0xa56): undefined reference to `drm_connector_init' riscv64-linux-gnu-ld: tda998x.c:(.text+0xa66): undefined reference to `drm_connector_attach_encoder' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `tda998x_bridge_detach': tda998x.c:(.text+0xa8a): undefined reference to `__drm_err' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L189': tda998x.c:(.text+0xd16): undefined reference to `drm_do_get_edid' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L0 ': tda998x.c:(.text+0xd34): undefined reference to `drm_connector_update_edid_property' riscv64-linux-gnu-ld: tda998x.c:(.text+0xd4e): undefined reference to `drm_add_edid_modes' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L165': tda998x.c:(.text+0xd5a): undefined reference to `drm_detect_monitor_audio' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L0 ': tda998x.c:(.text+0xfb0): undefined reference to `__drm_dbg' riscv64-linux-gnu-ld: tda998x.c:(.text+0x108a): undefined reference to `drm_kms_helper_hotplug_event' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L283': tda998x.c:(.text+0x1844): undefined reference to `drm_hdmi_avi_infoframe_from_display_mode' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.L361': tda998x.c:(.text+0x2078): undefined reference to `drm_bridge_add' riscv64-linux-gnu-ld: drivers/video/fbdev/starfive/tda998x.o: in function `.LANCHOR0': tda998x.c:(.rodata+0x90): undefined reference to `drm_helper_connector_dpms' riscv64-linux-gnu-ld: tda998x.c:(.rodata+0x98): undefined reference to `drm_atomic_helper_connector_reset' riscv64-linux-gnu-ld: tda998x.c:(.rodata+0xb0): undefined reference to `drm_helper_probe_single_connector_modes' riscv64-linux-gnu-ld: tda998x.c:(.rodata+0xd8): undefined reference to `drm_atomic_helper_connector_duplicate_state' riscv64-linux-gnu-ld: tda998x.c:(.rodata+0xe0): undefined reference to `drm_atomic_helper_connector_destroy_state' Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
…flict
starfive,vpp-lcdc 12000000.sfivefb: can't request region for resource [mem 0xfb000000-0xfcffffff]
starfive,vpp-lcdc 12000000.sfivefb: Fail to allocate video RAM
starfive,vpp-lcdc 12000000.sfivefb: starfive fb init fail
starfive,vpp-lcdc 12000000.sfivefb: fb info init FAIL
starfive,vpp-lcdc: probe of 12000000.sfivefb failed with error -16
devm_ioremap_resource() calls devm_request_mem_region(), which fails as
the reserved memory for the frame buffer is already present in the
resource list, cfr. /proc/iomem:
fb000000-fcffffff : Reserved
Fix this by mapping the frame buffer memory using devm_ioremap().
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
_ALIGN_UP() is being removed by commit efcec32 ("riscv: Cleanup unused functions") in riscv/for-next: drivers/video/fbdev/starfive/starfive_displayer.c: In function ‘of_parse_wr_cmd’: drivers/video/fbdev/starfive/starfive_displayer.c:616:27: error: implicit declaration of function ‘_ALIGN_UP’ [-Werror=implic it-function-declaration] 616 | dev_cmds->cmds = kzalloc(_ALIGN_UP(alloc_bytes, 4), GFP_KERNEL); | ^~~~~~~~~ Just use roundup() instead. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Tested-by: Emil Renner Berthing <kernel@esmil.dk>
Additional update from Prashant Gaikwad <pgaikwad@nvidia.com> Adapted for Linux 5.13 and the BeagleV Starlight board by <cybergaszcz@gmail.com>
This IP is also used on the StarFive JH7100 riscv64 SoC and presumably also the upcoming JH7110 SoC. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
** Do not upstream ** This is hacky fix just for testing. The actual patch would read the RISCV_UNCACHED_OFFSET from the DT for only the non-coherent devices. All other devices on beagleV and all other platform should just set dma_default_coherent to true. [Emil: remove spurious whitespace and fix format string warning] Signed-off-by: Atish Patra <atish.patra@wdc.com> Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Based on the device tree in https://github.com/starfive-tech/u-boot/ with contributions from: yanhong.wang <yanhong.wang@starfivetech.com> Huan.Feng <huan.feng@starfivetech.com> ke.zhu <ke.zhu@starfivetech.com> yiming.li <yiming.li@starfivetech.com> jack.zhu <jack.zhu@starfivetech.com> Samin Guo <samin.guo@starfivetech.com> Chenjieqin <Jessica.Chen@starfivetech.com> bo.li <bo.li@starfivetech.com> Rearranged, cleanups, fixes and TPS65086 added by Emil. Cleanups, fixes, LED and clocks added by Geert. Cleanups and GPIO fixes from Drew. Thermal zone added by Stephen. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Stephen L Arnold <nerdboy@gentoo.org> Signed-off-by: Drew Fustini <drew@beagleboard.org>
Note: add POWER_RESET_TPS65086, disable PM for USB3 Signed-off-by: TekkamanV <tekkamanv@starfivetech.com>
For convenience this also adds a small beaglev_defconfig and the firmware needed for the brcmfmac driver along with the signed regulatory database. The firmware is from the linux-firmware repo and the regulatory database from the wireless-regdb Fedora package. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Drew Fustini <drew@beagleboard.org>
The GPIO code is adapted from the StarFive GPIO driver by Huan Feng <huan.feng@starfivetech.com> with cleanups by Drew and me. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Drew Fustini <drew@beagleboard.org>
Current u-boot doesn't seem to take into account that some GPIOs are configured as inputs/outputs of certain peripherals on power-up. This means it ends up configuring some GPIOs as inputs to more than one peripheral which the documentation explicitly says is illegal. Similarly it also ends up configuring more than one GPIO as output of the same peripheral. While not explicitly mentioned by the documentation this also seems like a bad idea. The easiest way to remedy this mess is to just disconnect all GPIOs from peripherals and have our pinmux configuration set everything up properly. This, however, means that there is a short window from we do this reset to the real serial driver initializes where the serial console is disconnected from its pins. Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Remove usage of starfive_from_irq_desc() from starfive_gpio_irq_handler() Signed-off-by: Drew Fustini <drew@pdp7.com>
This commit should eventually be squashed. Add information about the register offsets and field descriptions from the JH7100 datasheet in particular regarding the registers related to GPIO interrupt. I found the naming used in the original starfive code to be confusing and I had to keep flipping back and forth between the datasheet. I felt that this would make it easier for people to read and review the code if there was more inline documentation. I also renamed some of the defines and variables to make the intent more clear. NOTE: Table 12-9 in the JH7100 datasheet is incorrect regarding fields GPIOIE_0 and GPIOIE_1. An interrupt is enabled (unmasked) when the bit is set to 1 and it is disabled (masked) when set to 0. The datasheet incorrectly states the opposite. I think this is due to the datasheet author thinking of it as mask field which it is not, it is an enable field. I will raise an issue on the documentation repo. Signed-off-by: Drew Fustini <drew@pdp7.com>
Author
|
esmil has added this in the current branch |
esmil
pushed a commit
that referenced
this pull request
Nov 21, 2021
[ Upstream commit 8ef9dc0 ] We got the following lockdep splat while running fstests (specifically btrfs/003 and btrfs/020 in a row) with the new rc. This was uncovered by 87579e9 ("loop: use worker per cgroup instead of kworker") which converted loop to using workqueues, which comes with lockdep annotations that don't exist with kworkers. The lockdep splat is as follows: WARNING: possible circular locking dependency detected 5.14.0-rc2-custom+ #34 Not tainted ------------------------------------------------------ losetup/156417 is trying to acquire lock: ffff9c7645b02d38 ((wq_completion)loop0){+.+.}-{0:0}, at: flush_workqueue+0x84/0x600 but task is already holding lock: ffff9c7647395468 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x650 [loop] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #5 (&lo->lo_mutex){+.+.}-{3:3}: __mutex_lock+0xba/0x7c0 lo_open+0x28/0x60 [loop] blkdev_get_whole+0x28/0xf0 blkdev_get_by_dev.part.0+0x168/0x3c0 blkdev_open+0xd2/0xe0 do_dentry_open+0x163/0x3a0 path_openat+0x74d/0xa40 do_filp_open+0x9c/0x140 do_sys_openat2+0xb1/0x170 __x64_sys_openat+0x54/0x90 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #4 (&disk->open_mutex){+.+.}-{3:3}: __mutex_lock+0xba/0x7c0 blkdev_get_by_dev.part.0+0xd1/0x3c0 blkdev_get_by_path+0xc0/0xd0 btrfs_scan_one_device+0x52/0x1f0 [btrfs] btrfs_control_ioctl+0xac/0x170 [btrfs] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #3 (uuid_mutex){+.+.}-{3:3}: __mutex_lock+0xba/0x7c0 btrfs_rm_device+0x48/0x6a0 [btrfs] btrfs_ioctl+0x2d1c/0x3110 [btrfs] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #2 (sb_writers#11){.+.+}-{0:0}: lo_write_bvec+0x112/0x290 [loop] loop_process_work+0x25f/0xcb0 [loop] process_one_work+0x28f/0x5d0 worker_thread+0x55/0x3c0 kthread+0x140/0x170 ret_from_fork+0x22/0x30 -> #1 ((work_completion)(&lo->rootcg_work)){+.+.}-{0:0}: process_one_work+0x266/0x5d0 worker_thread+0x55/0x3c0 kthread+0x140/0x170 ret_from_fork+0x22/0x30 -> #0 ((wq_completion)loop0){+.+.}-{0:0}: __lock_acquire+0x1130/0x1dc0 lock_acquire+0xf5/0x320 flush_workqueue+0xae/0x600 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x650 [loop] lo_ioctl+0x29d/0x780 [loop] block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: (wq_completion)loop0 --> &disk->open_mutex --> &lo->lo_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&lo->lo_mutex); lock(&disk->open_mutex); lock(&lo->lo_mutex); lock((wq_completion)loop0); *** DEADLOCK *** 1 lock held by losetup/156417: #0: ffff9c7647395468 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x650 [loop] stack backtrace: CPU: 8 PID: 156417 Comm: losetup Not tainted 5.14.0-rc2-custom+ #34 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x57/0x72 check_noncircular+0x10a/0x120 __lock_acquire+0x1130/0x1dc0 lock_acquire+0xf5/0x320 ? flush_workqueue+0x84/0x600 flush_workqueue+0xae/0x600 ? flush_workqueue+0x84/0x600 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x650 [loop] lo_ioctl+0x29d/0x780 [loop] ? __lock_acquire+0x3a0/0x1dc0 ? update_dl_rq_load_avg+0x152/0x360 ? lock_is_held_type+0xa5/0x120 ? find_held_lock.constprop.0+0x2b/0x80 block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f645884de6b Usually the uuid_mutex exists to protect the fs_devices that map together all of the devices that match a specific uuid. In rm_device we're messing with the uuid of a device, so it makes sense to protect that here. However in doing that it pulls in a whole host of lockdep dependencies, as we call mnt_may_write() on the sb before we grab the uuid_mutex, thus we end up with the dependency chain under the uuid_mutex being added under the normal sb write dependency chain, which causes problems with loop devices. We don't need the uuid mutex here however. If we call btrfs_scan_one_device() before we scratch the super block we will find the fs_devices and not find the device itself and return EBUSY because the fs_devices is open. If we call it after the scratch happens it will not appear to be a valid btrfs file system. We do not need to worry about other fs_devices modifying operations here because we're protected by the exclusive operations locking. So drop the uuid_mutex here in order to fix the lockdep splat. A more detailed explanation from the discussion: We are worried about rm and scan racing with each other, before this change we'll zero the device out under the UUID mutex so when scan does run it'll make sure that it can go through the whole device scan thing without rm messing with us. We aren't worried if the scratch happens first, because the result is we don't think this is a btrfs device and we bail out. The only case we are concerned with is we scratch _after_ scan is able to read the superblock and gets a seemingly valid super block, so lets consider this case. Scan will call device_list_add() with the device we're removing. We'll call find_fsid_with_metadata_uuid() and get our fs_devices for this UUID. At this point we lock the fs_devices->device_list_mutex. This is what protects us in this case, but we have two cases here. 1. We aren't to the device removal part of the RM. We found our device, and device name matches our path, we go down and we set total_devices to our super number of devices, which doesn't affect anything because we haven't done the remove yet. 2. We are past the device removal part, which is protected by the device_list_mutex. Scan doesn't find the device, it goes down and does the if (fs_devices->opened) return -EBUSY; check and we bail out. Nothing about this situation is ideal, but the lockdep splat is real, and the fix is safe, tho admittedly a bit scary looking. Reviewed-by: Anand Jain <anand.jain@oracle.com> Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: David Sterba <dsterba@suse.com> [ copy more from the discussion ] Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
esmil
pushed a commit
that referenced
this pull request
Jan 2, 2022
The function obtain the next buffer without boundary check. We should return with I/O error code. The bug is found by fuzzing and the crash report is attached. It is an OOB bug although reported as use-after-free. [ 4.804724] BUG: KASAN: use-after-free in aq_ring_rx_clean+0x1e88/0x2730 [atlantic] [ 4.805661] Read of size 4 at addr ffff888034fe93a8 by task ksoftirqd/0/9 [ 4.806505] [ 4.806703] CPU: 0 PID: 9 Comm: ksoftirqd/0 Tainted: G W 5.6.0 #34 [ 4.809030] Call Trace: [ 4.809343] dump_stack+0x76/0xa0 [ 4.809755] print_address_description.constprop.0+0x16/0x200 [ 4.810455] ? aq_ring_rx_clean+0x1e88/0x2730 [atlantic] [ 4.811234] ? aq_ring_rx_clean+0x1e88/0x2730 [atlantic] [ 4.813183] __kasan_report.cold+0x37/0x7c [ 4.813715] ? aq_ring_rx_clean+0x1e88/0x2730 [atlantic] [ 4.814393] kasan_report+0xe/0x20 [ 4.814837] aq_ring_rx_clean+0x1e88/0x2730 [atlantic] [ 4.815499] ? hw_atl_b0_hw_ring_rx_receive+0x9a5/0xb90 [atlantic] [ 4.816290] aq_vec_poll+0x179/0x5d0 [atlantic] [ 4.816870] ? _GLOBAL__sub_I_65535_1_aq_pci_func_init+0x20/0x20 [atlantic] [ 4.817746] ? __next_timer_interrupt+0xba/0xf0 [ 4.818322] net_rx_action+0x363/0xbd0 [ 4.818803] ? call_timer_fn+0x240/0x240 [ 4.819302] ? __switch_to_asm+0x40/0x70 [ 4.819809] ? napi_busy_loop+0x520/0x520 [ 4.820324] __do_softirq+0x18c/0x634 [ 4.820797] ? takeover_tasklets+0x5f0/0x5f0 [ 4.821343] run_ksoftirqd+0x15/0x20 [ 4.821804] smpboot_thread_fn+0x2f1/0x6b0 [ 4.822331] ? smpboot_unregister_percpu_thread+0x160/0x160 [ 4.823041] ? __kthread_parkme+0x80/0x100 [ 4.823571] ? smpboot_unregister_percpu_thread+0x160/0x160 [ 4.824301] kthread+0x2b5/0x3b0 [ 4.824723] ? kthread_create_on_node+0xd0/0xd0 [ 4.825304] ret_from_fork+0x35/0x40 Signed-off-by: Zekun Shen <bruceshenzk@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
esmil
pushed a commit
that referenced
this pull request
Jan 18, 2022
commit 07edfec upstream. At CPU-hotplug time, unbind_worker() may preempt a worker while it is waking up. In that case the following scenario can happen: unbind_workers() wq_worker_running() -------------- ------------------- if (!(worker->flags & WORKER_NOT_RUNNING)) //PREEMPTED by unbind_workers worker->flags |= WORKER_UNBOUND; [...] atomic_set(&pool->nr_running, 0); //resume to worker atomic_inc(&worker->pool->nr_running); After unbind_worker() resets pool->nr_running, the value is expected to remain 0 until the pool ever gets rebound in case cpu_up() is called on the target CPU in the future. But here the race leaves pool->nr_running with a value of 1, triggering the following warning when the worker goes idle: WARNING: CPU: 3 PID: 34 at kernel/workqueue.c:1823 worker_enter_idle+0x95/0xc0 Modules linked in: CPU: 3 PID: 34 Comm: kworker/3:0 Not tainted 5.16.0-rc1+ #34 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (rcu_par_gp) RIP: 0010:worker_enter_idle+0x95/0xc0 Code: 04 85 f8 ff ff ff 39 c1 7f 09 48 8b 43 50 48 85 c0 74 1b 83 e2 04 75 99 8b 43 34 39 43 30 75 91 8b 83 00 03 00 00 85 c0 74 87 <0f> 0b 5b c3 48 8b 35 70 f1 37 01 48 8d 7b 48 48 81 c6 e0 93 0 RSP: 0000:ffff9b7680277ed0 EFLAGS: 00010086 RAX: 00000000ffffffff RBX: ffff93465eae9c00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9346418a0000 RDI: ffff934641057140 RBP: ffff934641057170 R08: 0000000000000001 R09: ffff9346418a0080 R10: ffff9b768027fdf0 R11: 0000000000002400 R12: ffff93465eae9c20 R13: ffff93465eae9c20 R14: ffff93465eae9c70 R15: ffff934641057140 FS: 0000000000000000(0000) GS:ffff93465eac0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000001cc0c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> worker_thread+0x89/0x3d0 ? process_one_work+0x400/0x400 kthread+0x162/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 </TASK> Also due to this incorrect "nr_running == 1", further queued work may end up not being served, because no worker is awaken at work insert time. This raises rcutorture writer stalls for example. Fix this with disabling preemption in the right place in wq_worker_running(). It's worth noting that if the worker migrates and runs concurrently with unbind_workers(), it is guaranteed to see the WORKER_UNBOUND flag update due to set_cpus_allowed_ptr() acquiring/releasing rq->lock. Fixes: 6d25be5 ("sched/core, workqueues: Distangle worker accounting from rq lock") Reviewed-by: Lai Jiangshan <jiangshanlai@gmail.com> Tested-by: Paul E. McKenney <paulmck@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Daniel Bristot de Oliveira <bristot@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
esmil
pushed a commit
that referenced
this pull request
Jan 18, 2022
commit 45c753f upstream. At CPU-hotplug time, unbind_workers() may preempt a worker while it is going to sleep. In that case the following scenario can happen: unbind_workers() wq_worker_sleeping() -------------- ------------------- if (worker->flags & WORKER_NOT_RUNNING) return; //PREEMPTED by unbind_workers worker->flags |= WORKER_UNBOUND; [...] atomic_set(&pool->nr_running, 0); //resume to worker atomic_dec_and_test(&pool->nr_running); After unbind_worker() resets pool->nr_running, the value is expected to remain 0 until the pool ever gets rebound in case cpu_up() is called on the target CPU in the future. But here the race leaves pool->nr_running with a value of -1, triggering the following warning when the worker goes idle: WARNING: CPU: 3 PID: 34 at kernel/workqueue.c:1823 worker_enter_idle+0x95/0xc0 Modules linked in: CPU: 3 PID: 34 Comm: kworker/3:0 Not tainted 5.16.0-rc1+ #34 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014 Workqueue: 0x0 (rcu_par_gp) RIP: 0010:worker_enter_idle+0x95/0xc0 Code: 04 85 f8 ff ff ff 39 c1 7f 09 48 8b 43 50 48 85 c0 74 1b 83 e2 04 75 99 8b 43 34 39 43 30 75 91 8b 83 00 03 00 00 85 c0 74 87 <0f> 0b 5b c3 48 8b 35 70 f1 37 01 48 8d 7b 48 48 81 c6 e0 93 0 RSP: 0000:ffff9b7680277ed0 EFLAGS: 00010086 RAX: 00000000ffffffff RBX: ffff93465eae9c00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9346418a0000 RDI: ffff934641057140 RBP: ffff934641057170 R08: 0000000000000001 R09: ffff9346418a0080 R10: ffff9b768027fdf0 R11: 0000000000002400 R12: ffff93465eae9c20 R13: ffff93465eae9c20 R14: ffff93465eae9c70 R15: ffff934641057140 FS: 0000000000000000(0000) GS:ffff93465eac0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000001cc0c000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> worker_thread+0x89/0x3d0 ? process_one_work+0x400/0x400 kthread+0x162/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 </TASK> Also due to this incorrect "nr_running == -1", all sorts of hazards can happen, starting with queued works being ignored because no workers are awaken at insert_work() time. Fix this with checking again the worker flags while pool->lock is locked. Fixes: b945efc ("sched: Remove pointless preemption disable in sched_submit_work()") Reviewed-by: Lai Jiangshan <jiangshanlai@gmail.com> Tested-by: Paul E. McKenney <paulmck@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Paul E. McKenney <paulmck@kernel.org> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Daniel Bristot de Oliveira <bristot@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
esmil
pushed a commit
that referenced
this pull request
Aug 7, 2023
The nexthop code expects a 31 bit hash, such as what is returned by
fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash
returned by skb_get_hash() can lead to problems related to the fact that
'int hash' is a negative number when the MSB is set.
In the case of hash threshold nexthop groups, nexthop_select_path_hthr()
will disproportionately select the first nexthop group entry. In the case
of resilient nexthop groups, nexthop_select_path_res() may do an out of
bounds access in nh_buckets[], for example:
hash = -912054133
num_nh_buckets = 2
bucket_index = 65535
which leads to the following panic:
BUG: unable to handle page fault for address: ffffc900025910c8
PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0
Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Workqueue: ipv6_addrconf addrconf_dad_work
RIP: 0010:nexthop_select_path+0x197/0xbf0
Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85
RSP: 0018:ffff88810c36f260 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8
RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219
R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0
R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900
FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0
PKRU: 55555554
Call Trace:
<TASK>
? __die+0x23/0x70
? page_fault_oops+0x1ee/0x5c0
? __pfx_is_prefetch.constprop.0+0x10/0x10
? __pfx_page_fault_oops+0x10/0x10
? search_bpf_extables+0xfe/0x1c0
? fixup_exception+0x3b/0x470
? exc_page_fault+0xf6/0x110
? asm_exc_page_fault+0x26/0x30
? nexthop_select_path+0x197/0xbf0
? nexthop_select_path+0x197/0xbf0
? lock_is_held_type+0xe7/0x140
vxlan_xmit+0x5b2/0x2340
? __lock_acquire+0x92b/0x3370
? __pfx_vxlan_xmit+0x10/0x10
? __pfx___lock_acquire+0x10/0x10
? __pfx_register_lock_class+0x10/0x10
? skb_network_protocol+0xce/0x2d0
? dev_hard_start_xmit+0xca/0x350
? __pfx_vxlan_xmit+0x10/0x10
dev_hard_start_xmit+0xca/0x350
__dev_queue_xmit+0x513/0x1e20
? __pfx___dev_queue_xmit+0x10/0x10
? __pfx_lock_release+0x10/0x10
? mark_held_locks+0x44/0x90
? skb_push+0x4c/0x80
? eth_header+0x81/0xe0
? __pfx_eth_header+0x10/0x10
? neigh_resolve_output+0x215/0x310
? ip6_finish_output2+0x2ba/0xc90
ip6_finish_output2+0x2ba/0xc90
? lock_release+0x236/0x3e0
? ip6_mtu+0xbb/0x240
? __pfx_ip6_finish_output2+0x10/0x10
? find_held_lock+0x83/0xa0
? lock_is_held_type+0xe7/0x140
ip6_finish_output+0x1ee/0x780
ip6_output+0x138/0x460
? __pfx_ip6_output+0x10/0x10
? __pfx___lock_acquire+0x10/0x10
? __pfx_ip6_finish_output+0x10/0x10
NF_HOOK.constprop.0+0xc0/0x420
? __pfx_NF_HOOK.constprop.0+0x10/0x10
? ndisc_send_skb+0x2c0/0x960
? __pfx_lock_release+0x10/0x10
? __local_bh_enable_ip+0x93/0x110
? lock_is_held_type+0xe7/0x140
ndisc_send_skb+0x4be/0x960
? __pfx_ndisc_send_skb+0x10/0x10
? mark_held_locks+0x65/0x90
? find_held_lock+0x83/0xa0
ndisc_send_ns+0xb0/0x110
? __pfx_ndisc_send_ns+0x10/0x10
addrconf_dad_work+0x631/0x8e0
? lock_acquire+0x180/0x3f0
? __pfx_addrconf_dad_work+0x10/0x10
? mark_held_locks+0x24/0x90
process_one_work+0x582/0x9c0
? __pfx_process_one_work+0x10/0x10
? __pfx_do_raw_spin_lock+0x10/0x10
? mark_held_locks+0x24/0x90
worker_thread+0x93/0x630
? __kthread_parkme+0xdc/0x100
? __pfx_worker_thread+0x10/0x10
kthread+0x1a5/0x1e0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x34/0x60
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1b/0x30
RIP: 0000:0x0
Code: Unable to access opcode bytes at 0xffffffffffffffd6.
RSP: 0000:0000000000000000 EFLAGS: 00000000 ORIG_RAX: 0000000000000000
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>
Modules linked in:
CR2: ffffc900025910c8
---[ end trace 0000000000000000 ]---
RIP: 0010:nexthop_select_path+0x197/0xbf0
Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85
RSP: 0018:ffff88810c36f260 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8
RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219
R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0
R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900
FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 0000000129d00000 CR4: 0000000000750ee0
PKRU: 55555554
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: 0x2ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
Fix this problem by ensuring the MSB of hash is 0 using a right shift - the
same approach used in fib_multipath_hash() and rt6_multipath_hash().
Fixes: 1274e1c ("vxlan: ecmp support for mac fdb entries")
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
esmil
pushed a commit
that referenced
this pull request
Oct 29, 2024
Fix a shift-out-of-bounds bug reported by UBSAN when running VM with MTE enabled host kernel. UBSAN: shift-out-of-bounds in arch/arm64/kvm/sys_regs.c:1988:14 shift exponent 33 is too large for 32-bit type 'int' CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34 Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024 Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x74/0x90 dump_stack+0x18/0x28 __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0 reset_clidr+0x10c/0x1c8 kvm_reset_sys_regs+0x50/0x1c8 kvm_reset_vcpu+0xec/0x2b0 __kvm_vcpu_set_target+0x84/0x158 kvm_vcpu_set_target+0x138/0x168 kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0 kvm_arch_vcpu_ioctl+0x28c/0x4b8 kvm_vcpu_ioctl+0x4bc/0x7a8 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x70/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198 Fixes: 7af0c25 ("KVM: arm64: Normalize cache configuration") Cc: stable@vger.kernel.org Reviewed-by: Gavin Shan <gshan@redhat.com> Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com> Link: https://lore.kernel.org/r/20241017025701.67936-1-ilkka@os.amperecomputing.com Signed-off-by: Marc Zyngier <maz@kernel.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add information about the register offsets and field descriptions from the JH7100 datasheet in particular regarding the registers related to GPIO interrupt. I found the naming used in the original starfive code to be confusing and I had to keep flipping back and forth between the datasheet. I felt that this would make it easier for people to read and review the code if there was more inline documentation. I also renamed some of the defines and variables to make the intent more clear.
The irq fix is in this PR too, but I figure you would cherry pick what you want.