aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-10-29drm/rockchip: dsi: Fix VOP selection on SoCs that support itOndrej Jirman1-3/+1
lcdsel_grf_reg is defined as u32, so "< 0" comaprison is always false, which breaks VOP selection on eg. RK3399. Compare against 0. Fixes: f3aaa6125b6f ("drm/rockchip: dsi: add rk3568 support") Signed-off-by: Ondrej Jirman <[email protected]> Tested-by: Chris Morgan <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-29drm/rockchip: fix fbdev on non-IOMMU devicesJohn Keeping1-1/+4
When switching to the generic fbdev infrastructure, it was missed that framebuffers were created with the alloc_kmap parameter to rockchip_gem_create_object() set to true. The generic infrastructure calls this via the .dumb_create() driver operation and thus creates a buffer without an associated kmap. alloc_kmap only makes a difference on devices without an IOMMU, but when it is missing rockchip_gem_prime_vmap() fails and the framebuffer cannot be used. Detect the case where a buffer is being allocated for the framebuffer and ensure a kernel mapping is created in this case. Fixes: 24af7c34b290 ("drm/rockchip: use generic fbdev setup") Reported-by: Johan Jonker <[email protected]> Cc: Thomas Zimmermann <[email protected]> Signed-off-by: John Keeping <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-29drm/rockchip: dsi: Force synchronous probeBrian Norris1-0/+6
We can't safely probe a dual-DSI display asynchronously (driver_async_probe='*' or driver_async_probe='dw-mipi-dsi-rockchip' cmdline), because dw_mipi_dsi_rockchip_find_second() pokes one DSI device's drvdata from the other device without any locking. Request synchronous probe, at least until this driver learns some appropriate locking for dual-DSI initialization. Cc: <[email protected]> Signed-off-by: Brian Norris <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20221019170255.2.I6b985b0ca372b7e35c6d9ea970b24bcb262d4fc1@changeid
2022-10-29drm/rockchip: dsi: Clean up 'usage_mode' when failing to attachBrian Norris1-4/+12
If we fail to attach the first time (especially: EPROBE_DEFER), we fail to clean up 'usage_mode', and thus will fail to attach on any subsequent attempts, with "dsi controller already in use". Re-set to DW_DSI_USAGE_IDLE on attach failure. This is especially common to hit when enabling asynchronous probe on a duel-DSI system (such as RK3399 Gru/Scarlet), such that we're more likely to fail dw_mipi_dsi_rockchip_find_second() the first time. Fixes: 71f68fe7f121 ("drm/rockchip: dsi: add ability to work as a phy instead of full dsi") Cc: <[email protected]> Signed-off-by: Brian Norris <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20221019170255.1.Ia68dfb27b835d31d22bfe23812baf366ee1c6eac@changeid
2022-10-29drm/rockchip: dw_hdmi: filter regulator -EPROBE_DEFER error messagesAurelien Jarno1-1/+2
When the avdd-0v9 or avdd-1v8 supply are not yet available, EPROBE_DEFER is returned by rockchip_hdmi_parse_dt(). This causes the following error message to be printed multiple times: dwhdmi-rockchip fe0a0000.hdmi: [drm:dw_hdmi_rockchip_bind [rockchipdrm]] *ERROR* Unable to parse OF data Fix that by not printing the message when rockchip_hdmi_parse_dt() returns -EPROBE_DEFER. Fixes: ca80c4eb4b01 ("drm/rockchip: dw_hdmi: add regulator support") Signed-off-by: Aurelien Jarno <[email protected]> Reviewed-by: Dmitry Osipenko <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-29arm64: dts: ls208xa: specify clock frequencies for the MDIO controllersIoana Ciornei1-0/+6
Up until now, the external MDIO controller frequency values relied either on the default ones out of reset or on those setup by u-boot. Let's just properly specify the MDC frequency in the DTS so that even without u-boot's intervention Linux can drive the MDIO bus. Fixes: 0420dde30a90 ("arm64: dts: ls208xa: add the external MDIO nodes") Signed-off-by: Ioana Ciornei <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29arm64: dts: ls1088a: specify clock frequencies for the MDIO controllersIoana Ciornei1-0/+6
Up until now, the external MDIO controller frequency values relied either on the default ones out of reset or on those setup by u-boot. Let's just properly specify the MDC frequency in the DTS so that even without u-boot's intervention Linux can drive the MDIO bus. Fixes: bbe75af7b092 ("arm64: dts: ls1088a: add external MDIO device nodes") Signed-off-by: Ioana Ciornei <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29arm64: dts: lx2160a: specify clock frequencies for the MDIO controllersIoana Ciornei1-0/+6
Up until now, the external MDIO controller frequency values relied either on the default ones out of reset or on those setup by u-boot. Let's just properly specify the MDC frequency in the DTS so that even without u-boot's intervention Linux can drive the MDIO bus. Fixes: 6e1b8fae892d ("arm64: dts: lx2160a: add emdio1 node") Fixes: 5705b9dcda57 ("arm64: dts: lx2160a: add emdio2 node") Signed-off-by: Ioana Ciornei <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29platform/loongarch: laptop: Fix possible UAF and simplify ↵Yang Yingliang1-3/+7
generic_acpi_laptop_init() Currently the return value of 'sub_driver->init' is not checked. If sparse_keymap_setup() called in the init function fails, 'generic_ inputdev' is freed, then it will lead a UAF when using it in generic_ acpi_laptop_init(). Fix it by checking the return value and setting generic_inputdev to NULL after free, so as to avoid double free it. The error code in generic_subdriver_init() is always negative, so the return of generic_subdriver_init() can be simplified. Fixes: 6246ed09111f ("LoongArch: Add ACPI-based generic laptop driver") Signed-off-by: Yang Yingliang <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-10-29platform/loongarch: laptop: Adjust resume order for loongson_hotkey_resume()Huacai Chen1-7/+7
Some laptops don't support SW_LID, but still have backlight control, move backlight resuming before SW_LID event handling so as to avoid backlight mistake due to early return. Signed-off-by: Huacai Chen <[email protected]>
2022-10-29LoongArch: BPF: Avoid declare variables in switch-caseHuacai Chen1-18/+13
Not all compilers support declare variables in switch-case, so move declarations to the beginning of a function. Otherwise we may get such build errors: arch/loongarch/net/bpf_jit.c: In function ‘emit_atomic’: arch/loongarch/net/bpf_jit.c:362:3: error: a label can only be part of a statement and a declaration is not a statement u8 r0 = regmap[BPF_REG_0]; ^~ arch/loongarch/net/bpf_jit.c: In function ‘build_insn’: arch/loongarch/net/bpf_jit.c:727:3: error: a label can only be part of a statement and a declaration is not a statement u8 t7 = -1; ^~ arch/loongarch/net/bpf_jit.c:778:3: error: a label can only be part of a statement and a declaration is not a statement int ret; ^~~ arch/loongarch/net/bpf_jit.c:779:3: error: expected expression before ‘u64’ u64 func_addr; ^~~ arch/loongarch/net/bpf_jit.c:780:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] bool func_addr_fixed; ^~~~ arch/loongarch/net/bpf_jit.c:784:11: error: ‘func_addr’ undeclared (first use in this function); did you mean ‘in_addr’? &func_addr, &func_addr_fixed); ^~~~~~~~~ in_addr arch/loongarch/net/bpf_jit.c:784:11: note: each undeclared identifier is reported only once for each function it appears in arch/loongarch/net/bpf_jit.c:814:3: error: a label can only be part of a statement and a declaration is not a statement u64 imm64 = (u64)(insn + 1)->imm << 32 | (u32)insn->imm; ^~~ Signed-off-by: Huacai Chen <[email protected]>
2022-10-29LoongArch: Use flexible-array member instead of zero-length arrayYushan Zhou1-1/+1
Eliminate the following coccicheck warning: ./arch/loongarch/include/asm/ptrace.h:32:15-21: WARNING use flexible-array member instead Reviewed-by: WANG Xuerui <[email protected]> Signed-off-by: Yushan Zhou <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-10-29LoongArch: Remove unused kernel stack paddingJinyang He5-7/+6
The current LoongArch kernel stack is padded as if obeying the MIPS o32 calling convention (32 bytes), signifying the port's MIPS lineage but no longer making sense. Remove the padding for clarity. Reviewed-by: WANG Xuerui <[email protected]> Signed-off-by: Jinyang He <[email protected]> Signed-off-by: Huacai Chen <[email protected]>
2022-10-29soc: imx: imx93-pd: Fix the error handling path of imx93_pd_probe()Christophe JAILLET1-2/+15
In imx93_pd_probe(); if an error occurs, some resources need to be released as done in the remove function. Fixes: 0a0f7cc25d4a ("soc: imx: add i.MX93 SRC power domain driver") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29arm64: dts: imx93: correct gpio-rangesPeng Fan1-4/+5
Per imx93-pinfunc.h and pinctrl-imx93.c, correct gpio-ranges. Fixes: ec8b5b5058ea ("arm64: dts: freescale: Add i.MX93 dtsi support") Reported-by: David Wolfe <[email protected]> Reviewed-by: Haibo Chen <[email protected]> Reviewed-by: Jacky Bai <[email protected]> Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29arm64: dts: imx93: correct s4mu interrupt namesPeng Fan1-1/+1
Per binding doc, interrupt names should be tx and rx. Fixes: 0dfb380d2492 ("arm64: dts: imx93: add s4 mu node") Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29dt-bindings: power: gpcv2: add power-domains propertyPeng Fan1-0/+3
Some pgc power-domain requires a parent power domain, so add an optional power-domains property, otherwise there will be dt check warning: gpc@303a0000: pgc:power-domain@1: 'power-domains' does not match any of the regexes: 'pinctrl-[0-9]+' Fixes: 30af8513bdb5 ("dt-bindings: power: add defines for i.MX8MM power domains") Signed-off-by: Peng Fan <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29arm64: dts: imx8: correct clock orderPeng Fan1-9/+9
Per bindings/mmc/fsl-imx-esdhc.yaml, the clock order is ipg, ahb, per, otherwise warning: " mmc@5b020000: clock-names:1: 'ahb' was expected mmc@5b020000: clock-names:2: 'per' was expected " Fixes: 16c4ea7501b1 ("arm64: dts: imx8: switch to new lpcg clock binding") Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29ARM: dts: imx6dl-yapp4: Do not allow PM to switch PU regulator off on Q/QPPetr Benes2-0/+8
Fix our design flaw in supply voltage distribution on the Quad and QuadPlus based boards. The problem is that we supply the SoC cache (VDD_CACHE_CAP) from VDD_PU instead of VDD_SOC. The VDD_PU internal regulator can be disabled by PM if VPU or GPU is not used. If that happens the system freezes. To prevent that configure the reg_pu regulator to be always on. Fixes: 0de4ab81ab26 ("ARM: dts: imx6dl-yapp4: Add Y Soft IOTA Crux/Crux+ board") Cc: [email protected] Cc: [email protected] Signed-off-by: Petr Benes <[email protected]> Signed-off-by: Michal Vokáč <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29ARM: dts: imx6qdl-gw59{10,13}: fix user pushbutton GPIO offsetTim Harvey2-2/+2
The GW5910 and GW5913 have a user pushbutton that is tied to the Gateworks System Controller GPIO offset 2. Fix the invalid offset of 0. Fixes: 64bf0a0af18d ("ARM: dts: imx6qdl-gw: add Gateworks System Controller support") Signed-off-by: Tim Harvey <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29arm64: dts: imx8mn: Correct the usb power domainLi Jun1-1/+2
pgc_otg1 is actual the power domain of usb PHY, usb controller is in hsio power domain, and pgc_otg1 is required to be powered up to detect usb remote wakeup, so move the pgc_otg1 power domain to the usb phy node. Fixes: ea2b5af58ab2 ("arm64: dts: imx8mn: put USB controller into power-domains") Signed-off-by: Li Jun <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29arm64: dts: imx8mn: remove otg1 power domain dependency on hsioLi Jun1-1/+0
pgc_otg1 is an independent power domain of hsio, it's for usb phy, so remove hsio power domain from its node. Fixes: 8b8ebec67360 ("arm64: dts: imx8mn: add GPC node") Signed-off-by: Li Jun <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29arm64: dts: imx8mm: correct usb power domainsLi Jun1-2/+4
pgc_otg1/2 is actual the power domain of usb PHY, usb controller is in hsio power domain, and pgc_otg1/2 is required to be powered up to detect usb remote wakeup, so move the pgc_otg1/2 power domain to the usb phy node. Fixes: 01df28d80859 ("arm64: dts: imx8mm: put USB controllers into power-domains") Signed-off-by: Li Jun <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29arm64: dts: imx8mm: remove otg1/2 power domain dependency on hsioLi Jun1-2/+0
pgc_otg1/2 are independent power domain of hsio, they for usb phy, so remove hsio power domain dependency from its node. Fixes: d39d4bb15310 ("arm64: dts: imx8mm: add GPC node") Signed-off-by: Li Jun <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-29arm64: dts: verdin-imx8mp: fix ctrl_sleep_mociMax Krummenacher1-10/+10
The GPIO signaling ctrl_sleep_moci is currently handled as a gpio hog. But the gpio-hog node is made a child of the wrong gpio controller. Move it to the node representing gpio4 so that it actually works. Without this carrier board components jumpered to use the signal are unconditionally switched off. Fixes: a39ed23bdf6e ("arm64: dts: freescale: add initial support for verdin imx8m plus") Signed-off-by: Max Krummenacher <[email protected]> Signed-off-by: Marcel Ziswiler <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2022-10-28net: dsa: fall back to default tagger if we can't load the one from DTVladimir Oltean1-3/+10
DSA tagging protocol drivers can be changed at runtime through sysfs and at probe time through the device tree (support for the latter was added later). When changing through sysfs, it is assumed that the module for the new tagging protocol was already loaded into the kernel (in fact this is only a concern for Ocelot/Felix switches, where we have tag_ocelot.ko and tag_ocelot_8021q.ko; for every other switch, the default and alternative protocols are compiled within the same .ko, so there is nothing for the user to load). The kernel cannot currently call request_module(), because it has no way of constructing the modalias name of the tagging protocol driver ("dsa_tag-%d", where the number is one of DSA_TAG_PROTO_*_VALUE). The device tree only contains the string name of the tagging protocol ("ocelot-8021q"), and the only mapping between the string and the DSA_TAG_PROTO_OCELOT_8021Q_VALUE is present in tag_ocelot_8021q.ko. So this is a chicken-and-egg situation and dsa_core.ko has nothing based on which it can automatically request the insertion of the module. As a consequence, if CONFIG_NET_DSA_TAG_OCELOT_8021Q is built as module, the switch will forever defer probing. The long-term solution is to make DSA call request_module() somehow, but that probably needs some refactoring. What we can do to keep operating with existing device tree blobs is to cancel the attempt to change the tagging protocol with the one specified there, and to remain operating with the default one. Depending on the situation, the default protocol might still allow some functionality (in the case of ocelot, it does), and it's better to have that than to fail to probe. Fixes: deff710703d8 ("net: dsa: Allow default tag protocol to be overridden from DT") Link: https://lore.kernel.org/lkml/[email protected]/ Reported-by: Heiko Thiery <[email protected]> Reported-by: Michael Walle <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Tested-by: Michael Walle <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28net: ethernet: adi: adin1110: Fix notifiersAlexandru Tachici1-9/+29
ADIN1110 was registering netdev_notifiers on each device probe. This leads to warnings/probe failures because of double registration of the same notifier when to adin1110/2111 devices are connected to the same system. Move the registration of netdev_notifiers in module init call, in this way multiple driver instances can use the same notifiers. Fixes: bc93e19d088b ("net: ethernet: adi: Add ADIN1110 support") Signed-off-by: Alexandru Tachici <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28Merge branch 'a-few-corrections-for-sock_support_zc'Jakub Kicinski7-8/+21
Pavel Begunkov says: ==================== a few corrections for SOCK_SUPPORT_ZC There are several places/cases that got overlooked in regards to SOCK_SUPPORT_ZC. We're lacking the flag for IPv6 UDP sockets and accepted TCP sockets. We also should clear the flag when someone tries to hijack a socket by replacing the ->sk_prot callbacks. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28net: also flag accepted sockets supporting msghdr originated zerocopyStefan Metzmacher1-0/+2
Without this only the client initiated tcp sockets have SOCK_SUPPORT_ZC. The listening socket on the server also has it, but the accepted connections didn't, which meant IORING_OP_SEND[MSG]_ZC will always fails with -EOPNOTSUPP. Fixes: e993ffe3da4b ("net: flag sockets supporting msghdr originated zerocopy") Cc: <[email protected]> # 6.0 CC: Jens Axboe <[email protected]> Link: https://lore.kernel.org/io-uring/[email protected]/T/#m38aa19b0b825758fb97860a38ad13122051f9dda Signed-off-by: Stefan Metzmacher <[email protected]> Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28net/ulp: remove SOCK_SUPPORT_ZC from tls socketsPavel Begunkov1-0/+3
Remove SOCK_SUPPORT_ZC when we're setting ulp as it might not support msghdr::ubuf_info, e.g. like TLS replacing ->sk_prot with a new set of handlers. Cc: <[email protected]> # 6.0 Reported-by: Jakub Kicinski <[email protected]> Fixes: e993ffe3da4bc ("net: flag sockets supporting msghdr originated zerocopy") Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28net: remove SOCK_SUPPORT_ZC from sockmapPavel Begunkov4-8/+15
sockmap replaces ->sk_prot with its own callbacks, we should remove SOCK_SUPPORT_ZC as the new proto doesn't support msghdr::ubuf_info. Cc: <[email protected]> # 6.0 Reported-by: Jakub Kicinski <[email protected]> Fixes: e993ffe3da4bc ("net: flag sockets supporting msghdr originated zerocopy") Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28udp: advertise ipv6 udp support for msghdr::ubuf_infoPavel Begunkov1-0/+1
Mark udp ipv6 as supporting msghdr::ubuf_info. In the original commit SOCK_SUPPORT_ZC was supposed to be set by a udp_init_sock() call from udp6_init_sock(), but d38afeec26ed4 ("tcp/udp: Call inet6_destroy_sock() in IPv6 ...") removed it and so ipv6 udp misses the flag. Cc: <[email protected]> # 6.0 Fixes: e993ffe3da4bc ("net: flag sockets supporting msghdr originated zerocopy") Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28enic: MAINTAINERS: Update enic maintainersGovindarajulu Varadarajan1-1/+1
Update enic maintainers. Signed-off-by: Govindarajulu Varadarajan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28net: openvswitch: add missing .resv_start_opJakub Kicinski1-0/+1
I missed one of the families in OvS when annotating .resv_start_op. This triggers the warning added in commit ce48ebdd5651 ("genetlink: limit the use of validation workarounds to old ops"). Reported-by: [email protected] Fixes: 9c5d03d36251 ("genetlink: start to validate reserved header bytes") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28netlink: hide validation union fields from kdocJakub Kicinski1-13/+18
Mark the validation fields as private, users shouldn't set them directly and they are too complicated to explain in a more succinct way (there's already a long explanation in the comment above). The strict_start_type field is set directly and has a dedicated comment so move that above the "private" section. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-10-28Merge tag 's390-6.1-3' of ↵Linus Torvalds8-29/+24
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 fixes from Vasily Gorbik: - Remove outdated linux390 link from MAINTAINERS - Add few missing EX_TABLE entries to inline assemblies - Fix raw data collection for pai_ext PMU - Add kernel image secure boot trailer for future firmware versions - Fix out-of-bounds access on cio_ignore free - Fix memory allocation of mdev_types array in vfio-ap * tag 's390-6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/vfio-ap: Fix memory allocation for mdev_types array s390/cio: fix out-of-bounds access on cio_ignore free s390/pai: fix raw data collection for PMU pai_ext s390/boot: add secure boot trailer s390/pci: add missing EX_TABLE entries to __pcistg_mio_inuser()/__pcilg_mio_inuser() s390/futex: add missing EX_TABLE entry to __futex_atomic_op() s390/uaccess: add missing EX_TABLE entries to __clear_user() MAINTAINERS: remove outdated linux390 link
2022-10-28Merge tag 'riscv-for-linus-6.1-rc3' of ↵Linus Torvalds7-15/+30
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - A fix for a build warning in the jump_label code - One of the git://github -> https://github cleanups, for the SiFive drivers - A fix for the kasan initialization code, this still likely warrants some cleanups but that's a bigger problem and at least this fixes the crashes in the short term - A pair of fixes for extension support detection on mixed LLVM/GNU toolchains - A fix for a runtime warning in the /proc/cpuinfo code * tag 'riscv-for-linus-6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: RISC-V: Fix /proc/cpuinfo cpumask warning riscv: fix detection of toolchain Zihintpause support riscv: fix detection of toolchain Zicbom support riscv: mm: add missing memcpy in kasan_init MAINTAINERS: git://github.com -> https://github.com for sifive riscv: jump_label: mark arguments as const to satisfy asm constraints
2022-10-28Merge tag 'acpi-6.1-rc3' of ↵Linus Torvalds4-3/+11
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and device properties fixes from Rafael Wysocki: "These fix device properties documentation and the ACPI PCC code, add a new IRQ override quirk for resource handling and add one more item to the list of device IDs to be ignored when returned by _DEP. Specifics: - Fix the documentation of the *_match_string() family of functions to properly cover the return value (Andy Shevchenko) - Fix a possible integer overflow during multiplication in the ACPI PCC code (Manank Patel) - Make the ACPI device resources code skip IRQ override on Asus Vivobook S5602ZA (Tamim Khan) - Add LATT2021 to the list of device IDs that are ignored when returned by _DEP, because there are no drivers for them in the kernel and no plans to add such drivers (Hans de Goede)" * tag 'acpi-6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI: scan: Add LATT2021 to acpi_ignore_dep_ids[] ACPI: resource: Skip IRQ override on Asus Vivobook S5602ZA ACPI: PCC: Fix unintentional integer overflow device property: Fix documentation for *_match_string() APIs
2022-10-28Merge tag 'pm-6.1-rc3' of ↵Linus Torvalds6-209/+170
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fixes from Rafael Wysocki: "These make the intel_pstate driver work as expected on all hybrid platforms to date (regardless of possible platform firmware issues), fix hybrid sleep on systems using suspend-to-idle by default, make the generic power domains code handle disabled idle states properly and update pm-graph. Specifics: - Make intel_pstate use what is known about the hardware instead of relying on information from the platform firmware (ACPI CPPC in particular) to establish the relationship between the HWP CPU performance levels and frequencies on all hybrid platforms available to date (Rafael Wysocki) - Allow hybrid sleep to use suspend-to-idle as a system suspend method if it is the current suspend method of choice (Mario Limonciello) - Fix handling of unavailable/disabled idle states in the generic power domains code (Sudeep Holla) - Update the pm-graph suite of utilities to version 5.10 which is fixes-mostly and does not add any new features (Todd Brandt)" * tag 'pm-6.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM: domains: Fix handling of unavailable/disabled idle states pm-graph v5.10 cpufreq: intel_pstate: hybrid: Use known scaling factor for P-cores cpufreq: intel_pstate: Read all MSRs on the target CPU PM: hibernate: Allow hybrid sleep to work with s2idle
2022-10-28fortify: Capture __bos() results in const temp varsKees Cook1-4/+9
In two recent run-time memcpy() bound checking bug reports (NFS[1] and JFS[2]), the _detection_ was working correctly (in the sense that the requested copy size was larger than the destination field size), but the _warning text_ was showing the destination field size as SIZE_MAX ("unknown size"). This should be impossible, since the detection function will explicitly give up if the destination field size is unknown. For example, the JFS warning was: memcpy: detected field-spanning write (size 132) of single field "ip->i_link" at fs/jfs/namei.c:950 (size 18446744073709551615) Other cases of this warning (e.g.[3]) have reported correctly, and the reproducer only happens under GCC (at least 10.2 and 12.1), so this currently appears to be a GCC bug. Explicitly capturing the __builtin_object_size() results in const temporary variables fixes the report. For example, the JFS reproducer now correctly reports the field size (128): memcpy: detected field-spanning write (size 132) of single field "ip->i_link" at fs/jfs/namei.c:950 (size 128) Examination of the .text delta (which is otherwise identical), shows the literal value used in the report changing: - mov $0xffffffffffffffff,%rcx + mov $0x80,%ecx [1] https://lore.kernel.org/lkml/[email protected]/ [2] https://syzkaller.appspot.com/bug?id=23d613df5259b977dac1696bec77f61a85890e3d [3] https://lore.kernel.org/all/[email protected]/ Cc: "Dr. David Alan Gilbert" <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Kees Cook <[email protected]>
2022-10-29random: use arch_get_random*_early() in random_init()Jean-Philippe Brucker1-2/+2
While reworking the archrandom handling, commit d349ab99eec7 ("random: handle archrandom with multiple longs") switched to the non-early archrandom helpers in random_init(), which broke initialization of the entropy pool from the arm64 random generator. Indeed at that point the arm64 CPU features, which verify that all CPUs have compatible capabilities, are not finalized so arch_get_random_seed_longs() is unsuccessful. Instead random_init() should use the _early functions, which check only the boot CPU on arm64. On other architectures the _early functions directly call the normal ones. Fixes: d349ab99eec7 ("random: handle archrandom with multiple longs") Cc: [email protected] Signed-off-by: Jean-Philippe Brucker <[email protected]> Signed-off-by: Jason A. Donenfeld <[email protected]>
2022-10-28tools/nolibc/string: Fix memcmp() implementationRasmus Villemoes1-2/+2
The C standard says that memcmp() must treat the buffers as consisting of "unsigned chars". If char happens to be unsigned, the casts are ok, but then obviously the c1 variable can never contain a negative value. And when char is signed, the casts are wrong, and there's still a problem with using an 8-bit quantity to hold the difference, because that can range from -255 to +255. For example, assuming char is signed, comparing two 1-byte buffers, one containing 0x00 and another 0x80, the current implementation would return -128 for both memcmp(a, b, 1) and memcmp(b, a, 1), whereas one of those should of course return something positive. Signed-off-by: Rasmus Villemoes <[email protected]> Fixes: 66b6f755ad45 ("rcutorture: Import a copy of nolibc") Cc: [email protected] # v5.0+ Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2022-10-28tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12Willy Tarreau1-5/+8
When built at -Os, gcc-12 recognizes an strlen() pattern in nolibc_strlen() and replaces it with a jump to strlen(), which is not defined as a symbol and breaks compilation. Worse, when the function is called strlen(), the function is simply replaced with a jump to itself, hence becomes an infinite loop. One way to avoid this is to always set -ffreestanding, but the calling code doesn't know this and there's no way (either via attributes or pragmas) to globally enable it from include files, effectively leaving a painful situation for the caller. Alexey suggested to place an empty asm() statement inside the loop to stop gcc from recognizing a well-known pattern, which happens to work pretty fine. At least it allows us to make sure our local definition is not replaced with a self jump. The function only needs to be renamed back to strlen() so that the symbol exists, which implies that nolibc_strlen() which is used on variable strings has to be declared as a macro that points back to it before the strlen() macro is redifined. It was verified to produce valid code with gcc 3.4 to 12.1 at different optimization levels, and both with constant and variable strings. In case this problem surfaces again in the future, an alternate approach consisting in adding an optimize("no-tree-loop-distribute-patterns") function attribute for gcc>=12 worked as well but is less pretty. Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 66b6f755ad45 ("rcutorture: Import a copy of nolibc") Fixes: 96980b833a21 ("tools/nolibc/string: do not use __builtin_strlen() at -O0") Cc: "Paul E. McKenney" <[email protected]> Cc: Alexey Dobriyan <[email protected]> Signed-off-by: Willy Tarreau <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2022-10-28mm: multi-gen LRU: move lru_gen_add_mm() out of IRQ-off regionSebastian Andrzej Siewior1-1/+1
lru_gen_add_mm() has been added within an IRQ-off region in the commit mentioned below. The other invocations of lru_gen_add_mm() are not within an IRQ-off region. The invocation within IRQ-off region is problematic on PREEMPT_RT because the function is using a spin_lock_t which must not be used within IRQ-disabled regions. The other invocations of lru_gen_add_mm() occur while task_struct::alloc_lock is acquired. Move lru_gen_add_mm() after interrupts are enabled and before task_unlock(). Link: https://lkml.kernel.org/r/[email protected] Fixes: bd74fdaea1460 ("mm: multi-gen LRU: support page table walks") Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Acked-by: Yu Zhao <[email protected]> Cc: Al Viro <[email protected]> Cc: "Eric W . Biederman" <[email protected]> Cc: Kees Cook <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28lib: maple_tree: remove unneeded initialization in mtree_range_walk()Lukas Bulwahn1-2/+2
Before the do-while loop in mtree_range_walk(), the variables next, min, max need to be initialized. The variables last, prev_min and prev_max are set within the loop body before they are eventually used after exiting the loop body. As it is a do-while loop, the loop body is executed at least once, so the variables last, prev_min and prev_max do not need to be initialized before the loop body. Remove unneeded initialization of last and prev_min. The needless initialization was reported by clang-analyzer as Dead Stores. As the compiler already identifies these assignments as unneeded, it optimizes the assignments away. Hence: No functional change. No change in object code. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Lukas Bulwahn <[email protected]> Reviewed-by: Liam R. Howlett <[email protected]> Cc: Matthew Wilcox <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mmap: fix remap_file_pages() regressionLiam Howlett1-0/+3
When using the VMA iterator, the final execution will set the variable 'next' to NULL which causes the function to fail out. Restore the break in the loop to exit the VMA iterator early without clearing NULL fixes the issue. Link: https://lore.kernel.org/lkml/29344.1666681759@jrobl/ Link: https://lkml.kernel.org/r/[email protected] Fixes: 763ecb035029 (mm: remove the vma linked list) Signed-off-by: Liam R. Howlett <[email protected]> Reported-by: "J. R. Okajima" <[email protected]> Tested-by: "J. R. Okajima" <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mm/shmem: ensure proper fallback if page faultsIra Weiny1-0/+17
The kernel test robot flagged a recursive lock as a result of a conversion from kmap_atomic() to kmap_local_folio()[Link] The cause was due to the code depending on the kmap_atomic() side effect of disabling page faults. In that case the code expects the fault to fail and take the fallback case. git archaeology implied that the recursion may not be an actual bug.[1] However, depending on the implementation of the mmap_lock and the condition of the call there may still be a deadlock.[2] So this is not purely a lockdep issue. Considering a single threaded call stack there are 3 options. 1) Different mm's are in play (no issue) 2) Readlock implementation is recursive and same mm is in play (no issue) 3) Readlock implementation is _not_ recursive (issue) The mmap_lock is recursive so with a single thread there is no issue. However, Matthew pointed out a deadlock scenario when you consider additional process' and threads thusly. "The readlock implementation is only recursive if nobody else has taken a write lock. If you have a multithreaded process, one of the other threads can call mmap() and that will prevent recursion (due to fairness). Even if it's a different process that you're trying to acquire the mmap read lock on, you can still get into a deadly embrace. eg: process A thread 1 takes read lock on own mmap_lock process A thread 2 calls mmap, blocks taking write lock process B thread 1 takes page fault, read lock on own mmap lock process B thread 2 calls mmap, blocks taking write lock process A thread 1 blocks taking read lock on process B process B thread 1 blocks taking read lock on process A Now all four threads are blocked waiting for each other." Regardless using pagefault_disable() ensures that no matter what locking implementation is used a deadlock will not occur. Add an explicit pagefault_disable() and a big comment to explain this for future souls looking at this code. [1] https://lore.kernel.org/all/Y1MymJ%2FINb45AdaY@iweiny-desk3/ [2] https://lore.kernel.org/lkml/Y1bXBtGTCym77%[email protected]/ Link: https://lkml.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Fixes: 7a7256d5f512 ("shmem: convert shmem_mfill_atomic_pte() to use a folio") Signed-off-by: Ira Weiny <[email protected]> Reported-by: Matthew Wilcox (Oracle) <[email protected]> Reported-by: kernel test robot <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Peter Xu <[email protected]> Cc: Andrea Arcangeli <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28mm/userfaultfd: replace kmap/kmap_atomic() with kmap_local_page()Ira Weiny1-4/+21
kmap() and kmap_atomic() are being deprecated in favor of kmap_local_page() which is appropriate for any thread local context.[1] A recent locking bug report with userfaultfd showed that the conversion of the kmap_atomic()'s in those code flows requires care with regard to the prevention of deadlock.[2] git archaeology implied that the recursion may not be an actual bug.[3] However, depending on the implementation of the mmap_lock and the condition of the call there may still be a deadlock.[4] So this is not purely a lockdep issue. Considering a single threaded call stack there are 3 options. 1) Different mm's are in play (no issue) 2) Readlock implementation is recursive and same mm is in play (no issue) 3) Readlock implementation is _not_ recursive (issue) The mmap_lock is recursive so with a single thread there is no issue. However, Matthew pointed out a deadlock scenario when you consider additional process' and threads thusly. "The readlock implementation is only recursive if nobody else has taken a write lock. If you have a multithreaded process, one of the other threads can call mmap() and that will prevent recursion (due to fairness). Even if it's a different process that you're trying to acquire the mmap read lock on, you can still get into a deadly embrace. eg: process A thread 1 takes read lock on own mmap_lock process A thread 2 calls mmap, blocks taking write lock process B thread 1 takes page fault, read lock on own mmap lock process B thread 2 calls mmap, blocks taking write lock process A thread 1 blocks taking read lock on process B process B thread 1 blocks taking read lock on process A Now all four threads are blocked waiting for each other." Regardless using pagefault_disable() ensures that no matter what locking implementation is used a deadlock will not occur. Complete kmap conversion in userfaultfd by replacing the kmap() and kmap_atomic() calls with kmap_local_page(). When replacing the kmap_atomic() call ensure page faults continue to be disabled to support the correct fall back behavior and add a comment to inform future souls of the requirement. [1] https://lore.kernel.org/all/[email protected]/ [2] https://lore.kernel.org/all/Y1Mh2S7fUGQ%2FiKFR@iweiny-desk3/ [3] https://lore.kernel.org/all/Y1MymJ%2FINb45AdaY@iweiny-desk3/ [4] https://lore.kernel.org/lkml/Y1bXBtGTCym77%[email protected]/ [[email protected]: v2] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ira Weiny <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Peter Xu <[email protected]> Cc: Axel Rasmussen <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28x86: fortify: kmsan: fix KMSAN fortify buildsAlexander Potapenko4-6/+44
Ensure that KMSAN builds replace memset/memcpy/memmove calls with the respective __msan_XXX functions, and that none of the macros are redefined twice. This should allow building kernel with both CONFIG_KMSAN and CONFIG_FORTIFY_SOURCE. Link: https://lkml.kernel.org/r/[email protected] Link: https://github.com/google/kmsan/issues/89 Signed-off-by: Alexander Potapenko <[email protected]> Reported-by: Tamas K Lengyel <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2022-10-28x86: asm: make sure __put_user_size() evaluates pointer onceAlexander Potapenko1-6/+7
User access macros must ensure their arguments are evaluated only once if they are used more than once in the macro body. Adding instrument_put_user() to __put_user_size() resulted in double evaluation of the `ptr` argument, which led to correctness issues when performing e.g. unsafe_put_user(..., p++, ...). To fix those issues, evaluate the `ptr` argument of __put_user_size() at the beginning of the macro. Link: https://lkml.kernel.org/r/[email protected] Fixes: 888f84a6da4d ("x86: asm: instrument usercopy in get_user() and put_user()") Signed-off-by: Alexander Potapenko <[email protected]> Reported-by: youling257 <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.