From: Stewart Smith <trawets(a)amazon.com>
For both IPv4 and IPv6 incoming TCP connections are tracked in a hash
table with a hash over the source & destination addresses and ports.
However, the IPv6 hash is insufficient and can lead to a high rate of
collisions.
The IPv6 hash used an XOR to fit everything into the 96 bits for the
fast jenkins hash, meaning it is possible for an external entity to
ensure the hash collides, thus falling back to a linear search in the
bucket, which is slow.
We take the approach of hash half the data; hash the other half; and
then hash them together. We do this with 3x jenkins hashes rather than
2x to calculate the hashing value for the connection covering the full
length of the addresses and ports.
While this may look like it adds overhead, the reality of modern CPUs
means that this is unmeasurable in real world scenarios.
In simulating with llvm-mca, the increase in cycles for the hashing code
was ~5 cycles on Skylake (from a base of ~50), and an extra ~9 on
Nehalem (base of ~62).
In commit dd6d2910c5e0 ("netfilter: conntrack: switch to siphash")
netfilter switched from a jenkins hash to a siphash, but even the faster
hsiphash is a more significant overhead (~20-30%) in some preliminary
testing. So, in this patch, we keep to the more conservative approach to
ensure we don't add much overhead per SYN.
In testing, this results in a consistently even spread across the
connection buckets. In both testing and real-world scenarios, we have
not found any measurable performance impact.
Cc: stable(a)vger.kernel.org
Fixes: 08dcdbf6a7b9 ("ipv6: use a stronger hash for tcp")
Fixes: b3da2cf37c5c ("[INET]: Use jhash + random secret for ehash.")
Signed-off-by: Stewart Smith <trawets(a)amazon.com>
Signed-off-by: Samuel Mendoza-Jonas <samjonas(a)amazon.com>
---
include/net/ipv6.h | 4 +---
net/ipv6/inet6_hashtables.c | 5 ++++-
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 7332296eca44..f9bb54869d82 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -752,9 +752,7 @@ static inline u32 ipv6_addr_hash(const struct in6_addr *a)
/* more secured version of ipv6_addr_hash() */
static inline u32 __ipv6_addr_jhash(const struct in6_addr *a, const u32 initval)
{
- u32 v = (__force u32)a->s6_addr32[0] ^ (__force u32)a->s6_addr32[1];
-
- return jhash_3words(v,
+ return jhash_3words((__force u32)a->s6_addr32[1],
(__force u32)a->s6_addr32[2],
(__force u32)a->s6_addr32[3],
initval);
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index b64b49012655..bb7198081974 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -33,7 +33,10 @@ u32 inet6_ehashfn(const struct net *net,
net_get_random_once(&inet6_ehash_secret, sizeof(inet6_ehash_secret));
net_get_random_once(&ipv6_hash_secret, sizeof(ipv6_hash_secret));
- lhash = (__force u32)laddr->s6_addr32[3];
+ lhash = jhash_3words((__force u32)laddr->s6_addr32[3],
+ (((u32)lport) << 16) | (__force u32)fport,
+ (__force u32)faddr->s6_addr32[0],
+ ipv6_hash_secret);
fhash = __ipv6_addr_jhash(faddr, ipv6_hash_secret);
return __inet6_ehashfn(lhash, lport, fhash, fport,
--
2.25.1
When calling device_add in the registration of typec_port, it will do
the NULL check on usb_power_delivery handle in typec_port for the
visibility of the device attributes. It is always NULL because port->pd
is set in typec_port_set_usb_power_delivery which is later than the
device_add call.
Set port->pd before device_add and only link the device after that.
Fixes: a7cff92f0635 ("usb: typec: USB Power Delivery helpers for ports and partners")
Cc: stable(a)vger.kernel.org
Signed-off-by: Kyle Tso <kyletso(a)google.com>
---
update v2:
- Add "Cc: stable(a)vger.kernel.org"
drivers/usb/typec/class.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index faa184ae3dac..3b30948bf4b0 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -2288,6 +2288,8 @@ struct typec_port *typec_register_port(struct device *parent,
return ERR_PTR(ret);
}
+ port->pd = cap->pd;
+
ret = device_add(&port->dev);
if (ret) {
dev_err(parent, "failed to register port (%d)\n", ret);
@@ -2295,7 +2297,7 @@ struct typec_port *typec_register_port(struct device *parent,
return ERR_PTR(ret);
}
- ret = typec_port_set_usb_power_delivery(port, cap->pd);
+ ret = usb_power_delivery_link_device(port->pd, &port->dev);
if (ret) {
dev_err(&port->dev, "failed to link pd\n");
device_unregister(&port->dev);
--
2.41.0.162.gfafddb0af9-goog
This is the start of the stable review cycle for the 6.1.37 release.
There are 31 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun, 02 Jul 2023 05:56:20 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.37-rc2…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 6.1.37-rc2
Linus Torvalds <torvalds(a)linux-foundation.org>
sparc32: fix lock_mm_and_find_vma() conversion
Ricardo Cañuelo <ricardo.canuelo(a)collabora.com>
Revert "thermal/drivers/mediatek: Use devm_of_iomap to avoid resource leak in mtk_thermal_probe"
Mike Hommey <mh(a)glandium.org>
HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651.
Jason Gerecke <jason.gerecke(a)wacom.com>
HID: wacom: Use ktime_t rather than int when dealing with timestamps
Ludvig Michaelsson <ludvig.michaelsson(a)yubico.com>
HID: hidraw: fix data race on device refcount
Zhang Shurong <zhang_shurong(a)foxmail.com>
fbdev: fix potential OOB read in fast_imageblit()
Linus Torvalds <torvalds(a)linux-foundation.org>
mm: always expand the stack with the mmap write lock held
Linus Torvalds <torvalds(a)linux-foundation.org>
execve: expand new process stack manually ahead of time
Liam R. Howlett <Liam.Howlett(a)oracle.com>
mm: make find_extend_vma() fail if write lock not held
Linus Torvalds <torvalds(a)linux-foundation.org>
powerpc/mm: convert coprocessor fault to lock_mm_and_find_vma()
Linus Torvalds <torvalds(a)linux-foundation.org>
mm/fault: convert remaining simple cases to lock_mm_and_find_vma()
Ben Hutchings <ben(a)decadent.org.uk>
arm/mm: Convert to using lock_mm_and_find_vma()
Ben Hutchings <ben(a)decadent.org.uk>
riscv/mm: Convert to using lock_mm_and_find_vma()
Ben Hutchings <ben(a)decadent.org.uk>
mips/mm: Convert to using lock_mm_and_find_vma()
Michael Ellerman <mpe(a)ellerman.id.au>
powerpc/mm: Convert to using lock_mm_and_find_vma()
Linus Torvalds <torvalds(a)linux-foundation.org>
arm64/mm: Convert to using lock_mm_and_find_vma()
Linus Torvalds <torvalds(a)linux-foundation.org>
mm: make the page fault mmap locking killable
Linus Torvalds <torvalds(a)linux-foundation.org>
mm: introduce new 'lock_mm_and_find_vma()' page fault helper
Peng Zhang <zhangpeng.00(a)bytedance.com>
maple_tree: fix potential out-of-bounds access in mas_wr_end_piv()
Oliver Hartkopp <socketcan(a)hartkopp.net>
can: isotp: isotp_sendmsg(): fix return error fix on TX path
Thomas Gleixner <tglx(a)linutronix.de>
x86/smp: Cure kexec() vs. mwait_play_dead() breakage
Thomas Gleixner <tglx(a)linutronix.de>
x86/smp: Use dedicated cache-line for mwait_play_dead()
Thomas Gleixner <tglx(a)linutronix.de>
x86/smp: Remove pointless wmb()s from native_stop_other_cpus()
Tony Battersby <tonyb(a)cybernetics.com>
x86/smp: Dont access non-existing CPUID leaf
Thomas Gleixner <tglx(a)linutronix.de>
x86/smp: Make stop_other_cpus() more robust
Borislav Petkov (AMD) <bp(a)alien8.de>
x86/microcode/AMD: Load late on both threads too
Tony Luck <tony.luck(a)intel.com>
mm, hwpoison: when copy-on-write hits poison, take page offline
Tony Luck <tony.luck(a)intel.com>
mm, hwpoison: try to recover from copy-on write faults
Paolo Abeni <pabeni(a)redhat.com>
mptcp: ensure listener is unhashed before updating the sk status
David Woodhouse <dwmw(a)amazon.co.uk>
mm/mmap: Fix error return in do_vmi_align_munmap()
Liam R. Howlett <Liam.Howlett(a)oracle.com>
mm/mmap: Fix error path in do_vmi_align_munmap()
-------------
Diffstat:
Makefile | 4 +-
arch/alpha/Kconfig | 1 +
arch/alpha/mm/fault.c | 13 +--
arch/arc/Kconfig | 1 +
arch/arc/mm/fault.c | 11 +--
arch/arm/Kconfig | 1 +
arch/arm/mm/fault.c | 63 +++-----------
arch/arm64/Kconfig | 1 +
arch/arm64/mm/fault.c | 46 ++--------
arch/csky/Kconfig | 1 +
arch/csky/mm/fault.c | 22 ++---
arch/hexagon/Kconfig | 1 +
arch/hexagon/mm/vm_fault.c | 18 +---
arch/ia64/mm/fault.c | 36 ++------
arch/loongarch/Kconfig | 1 +
arch/loongarch/mm/fault.c | 16 ++--
arch/m68k/mm/fault.c | 9 +-
arch/microblaze/mm/fault.c | 5 +-
arch/mips/Kconfig | 1 +
arch/mips/mm/fault.c | 12 +--
arch/nios2/Kconfig | 1 +
arch/nios2/mm/fault.c | 17 +---
arch/openrisc/mm/fault.c | 5 +-
arch/parisc/mm/fault.c | 23 +++--
arch/powerpc/Kconfig | 1 +
arch/powerpc/mm/copro_fault.c | 14 +--
arch/powerpc/mm/fault.c | 39 +--------
arch/riscv/Kconfig | 1 +
arch/riscv/mm/fault.c | 31 +++----
arch/s390/mm/fault.c | 5 +-
arch/sh/Kconfig | 1 +
arch/sh/mm/fault.c | 17 +---
arch/sparc/Kconfig | 1 +
arch/sparc/mm/fault_32.c | 32 ++-----
arch/sparc/mm/fault_64.c | 8 +-
arch/um/kernel/trap.c | 11 +--
arch/x86/Kconfig | 1 +
arch/x86/include/asm/cpu.h | 2 +
arch/x86/include/asm/smp.h | 2 +
arch/x86/kernel/cpu/microcode/amd.c | 2 +-
arch/x86/kernel/process.c | 28 +++++-
arch/x86/kernel/smp.c | 73 ++++++++++------
arch/x86/kernel/smpboot.c | 81 ++++++++++++++++--
arch/x86/mm/fault.c | 52 +-----------
arch/xtensa/Kconfig | 1 +
arch/xtensa/mm/fault.c | 14 +--
drivers/hid/hid-logitech-hidpp.c | 2 +-
drivers/hid/hidraw.c | 9 +-
drivers/hid/wacom_wac.c | 6 +-
drivers/hid/wacom_wac.h | 2 +-
drivers/iommu/amd/iommu_v2.c | 4 +-
drivers/iommu/io-pgfault.c | 2 +-
drivers/thermal/mtk_thermal.c | 14 +--
drivers/video/fbdev/core/sysimgblt.c | 2 +-
fs/binfmt_elf.c | 6 +-
fs/exec.c | 38 +++++----
include/linux/highmem.h | 26 ++++++
include/linux/mm.h | 21 ++---
lib/maple_tree.c | 11 +--
mm/Kconfig | 4 +
mm/gup.c | 6 +-
mm/memory.c | 159 ++++++++++++++++++++++++++++++++---
mm/mmap.c | 154 +++++++++++++++++++++++++--------
mm/nommu.c | 17 ++--
net/can/isotp.c | 5 +-
net/mptcp/pm_netlink.c | 1 +
net/mptcp/protocol.c | 26 ++++--
67 files changed, 682 insertions(+), 559 deletions(-)
This is the start of the stable review cycle for the 6.1.37 release.
There are 30 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat, 01 Jul 2023 18:41:39 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.37-rc1…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 6.1.37-rc1
Ricardo Cañuelo <ricardo.canuelo(a)collabora.com>
Revert "thermal/drivers/mediatek: Use devm_of_iomap to avoid resource leak in mtk_thermal_probe"
Mike Hommey <mh(a)glandium.org>
HID: logitech-hidpp: add HIDPP_QUIRK_DELAYED_INIT for the T651.
Jason Gerecke <jason.gerecke(a)wacom.com>
HID: wacom: Use ktime_t rather than int when dealing with timestamps
Ludvig Michaelsson <ludvig.michaelsson(a)yubico.com>
HID: hidraw: fix data race on device refcount
Zhang Shurong <zhang_shurong(a)foxmail.com>
fbdev: fix potential OOB read in fast_imageblit()
Linus Torvalds <torvalds(a)linux-foundation.org>
mm: always expand the stack with the mmap write lock held
Linus Torvalds <torvalds(a)linux-foundation.org>
execve: expand new process stack manually ahead of time
Liam R. Howlett <Liam.Howlett(a)oracle.com>
mm: make find_extend_vma() fail if write lock not held
Linus Torvalds <torvalds(a)linux-foundation.org>
powerpc/mm: convert coprocessor fault to lock_mm_and_find_vma()
Linus Torvalds <torvalds(a)linux-foundation.org>
mm/fault: convert remaining simple cases to lock_mm_and_find_vma()
Ben Hutchings <ben(a)decadent.org.uk>
arm/mm: Convert to using lock_mm_and_find_vma()
Ben Hutchings <ben(a)decadent.org.uk>
riscv/mm: Convert to using lock_mm_and_find_vma()
Ben Hutchings <ben(a)decadent.org.uk>
mips/mm: Convert to using lock_mm_and_find_vma()
Michael Ellerman <mpe(a)ellerman.id.au>
powerpc/mm: Convert to using lock_mm_and_find_vma()
Linus Torvalds <torvalds(a)linux-foundation.org>
arm64/mm: Convert to using lock_mm_and_find_vma()
Linus Torvalds <torvalds(a)linux-foundation.org>
mm: make the page fault mmap locking killable
Linus Torvalds <torvalds(a)linux-foundation.org>
mm: introduce new 'lock_mm_and_find_vma()' page fault helper
Peng Zhang <zhangpeng.00(a)bytedance.com>
maple_tree: fix potential out-of-bounds access in mas_wr_end_piv()
Oliver Hartkopp <socketcan(a)hartkopp.net>
can: isotp: isotp_sendmsg(): fix return error fix on TX path
Thomas Gleixner <tglx(a)linutronix.de>
x86/smp: Cure kexec() vs. mwait_play_dead() breakage
Thomas Gleixner <tglx(a)linutronix.de>
x86/smp: Use dedicated cache-line for mwait_play_dead()
Thomas Gleixner <tglx(a)linutronix.de>
x86/smp: Remove pointless wmb()s from native_stop_other_cpus()
Tony Battersby <tonyb(a)cybernetics.com>
x86/smp: Dont access non-existing CPUID leaf
Thomas Gleixner <tglx(a)linutronix.de>
x86/smp: Make stop_other_cpus() more robust
Borislav Petkov (AMD) <bp(a)alien8.de>
x86/microcode/AMD: Load late on both threads too
Tony Luck <tony.luck(a)intel.com>
mm, hwpoison: when copy-on-write hits poison, take page offline
Tony Luck <tony.luck(a)intel.com>
mm, hwpoison: try to recover from copy-on write faults
Paolo Abeni <pabeni(a)redhat.com>
mptcp: ensure listener is unhashed before updating the sk status
David Woodhouse <dwmw(a)amazon.co.uk>
mm/mmap: Fix error return in do_vmi_align_munmap()
Liam R. Howlett <Liam.Howlett(a)oracle.com>
mm/mmap: Fix error path in do_vmi_align_munmap()
-------------
Diffstat:
Makefile | 4 +-
arch/alpha/Kconfig | 1 +
arch/alpha/mm/fault.c | 13 +--
arch/arc/Kconfig | 1 +
arch/arc/mm/fault.c | 11 +--
arch/arm/Kconfig | 1 +
arch/arm/mm/fault.c | 63 +++-----------
arch/arm64/Kconfig | 1 +
arch/arm64/mm/fault.c | 46 ++--------
arch/csky/Kconfig | 1 +
arch/csky/mm/fault.c | 22 ++---
arch/hexagon/Kconfig | 1 +
arch/hexagon/mm/vm_fault.c | 18 +---
arch/ia64/mm/fault.c | 36 ++------
arch/loongarch/Kconfig | 1 +
arch/loongarch/mm/fault.c | 16 ++--
arch/m68k/mm/fault.c | 9 +-
arch/microblaze/mm/fault.c | 5 +-
arch/mips/Kconfig | 1 +
arch/mips/mm/fault.c | 12 +--
arch/nios2/Kconfig | 1 +
arch/nios2/mm/fault.c | 17 +---
arch/openrisc/mm/fault.c | 5 +-
arch/parisc/mm/fault.c | 23 +++--
arch/powerpc/Kconfig | 1 +
arch/powerpc/mm/copro_fault.c | 14 +--
arch/powerpc/mm/fault.c | 39 +--------
arch/riscv/Kconfig | 1 +
arch/riscv/mm/fault.c | 31 +++----
arch/s390/mm/fault.c | 5 +-
arch/sh/Kconfig | 1 +
arch/sh/mm/fault.c | 17 +---
arch/sparc/Kconfig | 1 +
arch/sparc/mm/fault_32.c | 32 ++-----
arch/sparc/mm/fault_64.c | 8 +-
arch/um/kernel/trap.c | 11 +--
arch/x86/Kconfig | 1 +
arch/x86/include/asm/cpu.h | 2 +
arch/x86/include/asm/smp.h | 2 +
arch/x86/kernel/cpu/microcode/amd.c | 2 +-
arch/x86/kernel/process.c | 28 +++++-
arch/x86/kernel/smp.c | 73 ++++++++++------
arch/x86/kernel/smpboot.c | 81 ++++++++++++++++--
arch/x86/mm/fault.c | 52 +-----------
arch/xtensa/Kconfig | 1 +
arch/xtensa/mm/fault.c | 14 +--
drivers/hid/hid-logitech-hidpp.c | 2 +-
drivers/hid/hidraw.c | 9 +-
drivers/hid/wacom_wac.c | 6 +-
drivers/hid/wacom_wac.h | 2 +-
drivers/iommu/amd/iommu_v2.c | 4 +-
drivers/iommu/io-pgfault.c | 2 +-
drivers/thermal/mtk_thermal.c | 14 +--
drivers/video/fbdev/core/sysimgblt.c | 2 +-
fs/binfmt_elf.c | 6 +-
fs/exec.c | 38 +++++----
include/linux/highmem.h | 26 ++++++
include/linux/mm.h | 21 ++---
lib/maple_tree.c | 11 +--
mm/Kconfig | 4 +
mm/gup.c | 6 +-
mm/memory.c | 159 ++++++++++++++++++++++++++++++++---
mm/mmap.c | 154 +++++++++++++++++++++++++--------
mm/nommu.c | 17 ++--
net/can/isotp.c | 5 +-
net/mptcp/pm_netlink.c | 1 +
net/mptcp/protocol.c | 26 ++++--
67 files changed, 682 insertions(+), 559 deletions(-)
From: Lorenz Brun <lorenz(a)brun.one>
[ Upstream commit 03633c4ef1fb5ee119296dfe0c411656a9b5e04f ]
Currently the ROCK64 device tree specifies two regulators, vcc_host_5v
and vcc_host1_5v for USB VBUS on the device. Both of those are however
specified with RK_PA2 as the GPIO enabling them, causing the following
error when booting:
rockchip-pinctrl pinctrl: pin gpio0-2 already requested by vcc-host-5v-regulator; cannot claim for vcc-host1-5v-regulator
rockchip-pinctrl pinctrl: pin-2 (vcc-host1-5v-regulator) status -22
rockchip-pinctrl pinctrl: could not request pin 2 (gpio0-2) from group usb20-host-drv on device rockchip-pinctrl
reg-fixed-voltage vcc-host1-5v-regulator: Error applying setting, reverse things back
Looking at the schematic, there are in fact three USB regulators,
vcc_host_5v, vcc_host1_5v and vcc_otg_v5. But the enable signal for all
three is driven by Q2604 which is in turn driven by GPIO_A2/PA2.
Since these three regulators are not controllable separately, I removed
the second one which was causing the error and added labels for all
rails to the single regulator.
Signed-off-by: Lorenz Brun <lorenz(a)brun.one>
Tested-by: Diederik de Haas <didi.debian(a)cknow.org>
Link: https://lore.kernel.org/r/20230421213841.3079632-1-lorenz@brun.one
Signed-off-by: Heiko Stuebner <heiko(a)sntech.de>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index f69a38f42d2d5..0a27fa5271f57 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -37,7 +37,8 @@ vcc_sd: sdmmc-regulator {
vin-supply = <&vcc_io>;
};
- vcc_host_5v: vcc-host-5v-regulator {
+ /* Common enable line for all of the rails mentioned in the labels */
+ vcc_host_5v: vcc_host1_5v: vcc_otg_5v: vcc-host-5v-regulator {
compatible = "regulator-fixed";
gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
@@ -48,17 +49,6 @@ vcc_host_5v: vcc-host-5v-regulator {
vin-supply = <&vcc_sys>;
};
- vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
- compatible = "regulator-fixed";
- gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&usb20_host_drv>;
- regulator-name = "vcc_host1_5v";
- regulator-always-on;
- regulator-boot-on;
- vin-supply = <&vcc_sys>;
- };
-
vcc_sys: vcc-sys {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
--
2.39.2
From: Long Li <longli(a)microsoft.com>
The hardware specification specifies that WQE_COUNT should set to 0 for
the Receive Queue. Although currently the hardware doesn't enforce the
check, in the future releases it may check on this value.
Cc: stable(a)vger.kernel.org
Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
Reviewed-by: Haiyang Zhang <haiyangz(a)microsoft.com>
Reviewed-by: Dexuan Cui <decui(a)microsoft.com>
Signed-off-by: Long Li <longli(a)microsoft.com>
---
Change log:
v4:
Split the original patch into two: one for batching doorbell, one for setting the correct wqe count
drivers/net/ethernet/microsoft/mana/gdma_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c
index 8f3f78b68592..3765d3389a9a 100644
--- a/drivers/net/ethernet/microsoft/mana/gdma_main.c
+++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c
@@ -300,8 +300,11 @@ static void mana_gd_ring_doorbell(struct gdma_context *gc, u32 db_index,
void mana_gd_wq_ring_doorbell(struct gdma_context *gc, struct gdma_queue *queue)
{
+ /* Hardware Spec specifies that software client should set 0 for
+ * wqe_cnt for Receive Queues. This value is not used in Send Queues.
+ */
mana_gd_ring_doorbell(gc, queue->gdma_dev->doorbell, queue->type,
- queue->id, queue->head * GDMA_WQE_BU_SIZE, 1);
+ queue->id, queue->head * GDMA_WQE_BU_SIZE, 0);
}
void mana_gd_ring_cq(struct gdma_queue *cq, u8 arm_bit)
--
2.34.1
From: Long Li <longli(a)microsoft.com>
It's inefficient to ring the doorbell page every time a WQE is posted to
the received queue. Excessive MMIO writes result in CPU spending more
time waiting on LOCK instructions (atomic operations), resulting in
poor scaling performance.
Move the code for ringing doorbell page to where after we have posted all
WQEs to the receive queue during a callback from napi_poll().
With this change, tests showed an improvement from 120G/s to 160G/s on a
200G physical link, with 16 or 32 hardware queues.
Tests showed no regression in network latency benchmarks on single
connection.
Cc: stable(a)vger.kernel.org
Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)")
Reviewed-by: Haiyang Zhang <haiyangz(a)microsoft.com>
Reviewed-by: Dexuan Cui <decui(a)microsoft.com>
Signed-off-by: Long Li <longli(a)microsoft.com>
---
Change log:
v2:
Check for comp_read > 0 as it might be negative on completion error.
Set rq.wqe_cnt to 0 according to BNIC spec.
v3:
Add details in the commit on the reason of performance increase and test numbers.
Add details in the commit on why rq.wqe_cnt should be set to 0 according to hardware spec.
Add "Reviewed-by" from Haiyang and Dexuan.
v4:
Split the original patch into two: one for batching doorbell, one for setting the correct wqe count
drivers/net/ethernet/microsoft/mana/mana_en.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index cd4d5ceb9f2d..1d8abe63fcb8 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -1383,8 +1383,8 @@ static void mana_post_pkt_rxq(struct mana_rxq *rxq)
recv_buf_oob = &rxq->rx_oobs[curr_index];
- err = mana_gd_post_and_ring(rxq->gdma_rq, &recv_buf_oob->wqe_req,
- &recv_buf_oob->wqe_inf);
+ err = mana_gd_post_work_request(rxq->gdma_rq, &recv_buf_oob->wqe_req,
+ &recv_buf_oob->wqe_inf);
if (WARN_ON_ONCE(err))
return;
@@ -1654,6 +1654,12 @@ static void mana_poll_rx_cq(struct mana_cq *cq)
mana_process_rx_cqe(rxq, cq, &comp[i]);
}
+ if (comp_read > 0) {
+ struct gdma_context *gc = rxq->gdma_rq->gdma_dev->gdma_context;
+
+ mana_gd_wq_ring_doorbell(gc, rxq->gdma_rq);
+ }
+
if (rxq->xdp_flush)
xdp_do_flush();
}
--
2.34.1
From: Mark Brown <broonie(a)kernel.org>
[ Upstream commit 97eea946b93961fffd29448dcda7398d0d51c4b2 ]
The bounds checks in snd_soc_put_volsw_sx() are only being applied to the
first channel, meaning it is possible to write out of bounds values to the
second channel in stereo controls. Add appropriate checks.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Link: https://lore.kernel.org/r/20220511134137.169575-2-broonie@kernel.org
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
sound/soc/soc-ops.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c
index 81c9ecfa7c7f9..63c0e61b17541 100644
--- a/sound/soc/soc-ops.c
+++ b/sound/soc/soc-ops.c
@@ -465,6 +465,12 @@ int snd_soc_put_volsw_sx(struct snd_kcontrol *kcontrol,
if (snd_soc_volsw_is_stereo(mc)) {
val_mask = mask << rshift;
val2 = (ucontrol->value.integer.value[1] + min) & mask;
+
+ if (mc->platform_max && val2 > mc->platform_max)
+ return -EINVAL;
+ if (val2 > max)
+ return -EINVAL;
+
val2 = val2 << rshift;
err = snd_soc_component_update_bits(component, reg2, val_mask,
--
2.39.2
From: Mark Brown <broonie(a)kernel.org>
[ Upstream commit 97eea946b93961fffd29448dcda7398d0d51c4b2 ]
The bounds checks in snd_soc_put_volsw_sx() are only being applied to the
first channel, meaning it is possible to write out of bounds values to the
second channel in stereo controls. Add appropriate checks.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Link: https://lore.kernel.org/r/20220511134137.169575-2-broonie@kernel.org
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
sound/soc/soc-ops.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c
index 453b61b42dd9e..00e6a6e46fe52 100644
--- a/sound/soc/soc-ops.c
+++ b/sound/soc/soc-ops.c
@@ -460,6 +460,12 @@ int snd_soc_put_volsw_sx(struct snd_kcontrol *kcontrol,
if (snd_soc_volsw_is_stereo(mc)) {
val_mask = mask << rshift;
val2 = (ucontrol->value.integer.value[1] + min) & mask;
+
+ if (mc->platform_max && val2 > mc->platform_max)
+ return -EINVAL;
+ if (val2 > max)
+ return -EINVAL;
+
val2 = val2 << rshift;
err = snd_soc_component_update_bits(component, reg2, val_mask,
--
2.39.2
From: Mark Brown <broonie(a)kernel.org>
[ Upstream commit 97eea946b93961fffd29448dcda7398d0d51c4b2 ]
The bounds checks in snd_soc_put_volsw_sx() are only being applied to the
first channel, meaning it is possible to write out of bounds values to the
second channel in stereo controls. Add appropriate checks.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Link: https://lore.kernel.org/r/20220511134137.169575-2-broonie@kernel.org
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
sound/soc/soc-ops.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c
index 453b61b42dd9e..00e6a6e46fe52 100644
--- a/sound/soc/soc-ops.c
+++ b/sound/soc/soc-ops.c
@@ -460,6 +460,12 @@ int snd_soc_put_volsw_sx(struct snd_kcontrol *kcontrol,
if (snd_soc_volsw_is_stereo(mc)) {
val_mask = mask << rshift;
val2 = (ucontrol->value.integer.value[1] + min) & mask;
+
+ if (mc->platform_max && val2 > mc->platform_max)
+ return -EINVAL;
+ if (val2 > max)
+ return -EINVAL;
+
val2 = val2 << rshift;
err = snd_soc_component_update_bits(component, reg2, val_mask,
--
2.39.2
From: Lorenz Brun <lorenz(a)brun.one>
[ Upstream commit 03633c4ef1fb5ee119296dfe0c411656a9b5e04f ]
Currently the ROCK64 device tree specifies two regulators, vcc_host_5v
and vcc_host1_5v for USB VBUS on the device. Both of those are however
specified with RK_PA2 as the GPIO enabling them, causing the following
error when booting:
rockchip-pinctrl pinctrl: pin gpio0-2 already requested by vcc-host-5v-regulator; cannot claim for vcc-host1-5v-regulator
rockchip-pinctrl pinctrl: pin-2 (vcc-host1-5v-regulator) status -22
rockchip-pinctrl pinctrl: could not request pin 2 (gpio0-2) from group usb20-host-drv on device rockchip-pinctrl
reg-fixed-voltage vcc-host1-5v-regulator: Error applying setting, reverse things back
Looking at the schematic, there are in fact three USB regulators,
vcc_host_5v, vcc_host1_5v and vcc_otg_v5. But the enable signal for all
three is driven by Q2604 which is in turn driven by GPIO_A2/PA2.
Since these three regulators are not controllable separately, I removed
the second one which was causing the error and added labels for all
rails to the single regulator.
Signed-off-by: Lorenz Brun <lorenz(a)brun.one>
Tested-by: Diederik de Haas <didi.debian(a)cknow.org>
Link: https://lore.kernel.org/r/20230421213841.3079632-1-lorenz@brun.one
Signed-off-by: Heiko Stuebner <heiko(a)sntech.de>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 95ab6928cfd40..d6a288b0e2ab6 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -32,7 +32,8 @@ vcc_sd: sdmmc-regulator {
vin-supply = <&vcc_io>;
};
- vcc_host_5v: vcc-host-5v-regulator {
+ /* Common enable line for all of the rails mentioned in the labels */
+ vcc_host_5v: vcc_host1_5v: vcc_otg_5v: vcc-host-5v-regulator {
compatible = "regulator-fixed";
gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
@@ -43,17 +44,6 @@ vcc_host_5v: vcc-host-5v-regulator {
vin-supply = <&vcc_sys>;
};
- vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
- compatible = "regulator-fixed";
- gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&usb20_host_drv>;
- regulator-name = "vcc_host1_5v";
- regulator-always-on;
- regulator-boot-on;
- vin-supply = <&vcc_sys>;
- };
-
vcc_sys: vcc-sys {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
--
2.39.2
From: Lorenz Brun <lorenz(a)brun.one>
[ Upstream commit 03633c4ef1fb5ee119296dfe0c411656a9b5e04f ]
Currently the ROCK64 device tree specifies two regulators, vcc_host_5v
and vcc_host1_5v for USB VBUS on the device. Both of those are however
specified with RK_PA2 as the GPIO enabling them, causing the following
error when booting:
rockchip-pinctrl pinctrl: pin gpio0-2 already requested by vcc-host-5v-regulator; cannot claim for vcc-host1-5v-regulator
rockchip-pinctrl pinctrl: pin-2 (vcc-host1-5v-regulator) status -22
rockchip-pinctrl pinctrl: could not request pin 2 (gpio0-2) from group usb20-host-drv on device rockchip-pinctrl
reg-fixed-voltage vcc-host1-5v-regulator: Error applying setting, reverse things back
Looking at the schematic, there are in fact three USB regulators,
vcc_host_5v, vcc_host1_5v and vcc_otg_v5. But the enable signal for all
three is driven by Q2604 which is in turn driven by GPIO_A2/PA2.
Since these three regulators are not controllable separately, I removed
the second one which was causing the error and added labels for all
rails to the single regulator.
Signed-off-by: Lorenz Brun <lorenz(a)brun.one>
Tested-by: Diederik de Haas <didi.debian(a)cknow.org>
Link: https://lore.kernel.org/r/20230421213841.3079632-1-lorenz@brun.one
Signed-off-by: Heiko Stuebner <heiko(a)sntech.de>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index 1b0f7e4551ea4..522d2d4281033 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -37,7 +37,8 @@ vcc_sd: sdmmc-regulator {
vin-supply = <&vcc_io>;
};
- vcc_host_5v: vcc-host-5v-regulator {
+ /* Common enable line for all of the rails mentioned in the labels */
+ vcc_host_5v: vcc_host1_5v: vcc_otg_5v: vcc-host-5v-regulator {
compatible = "regulator-fixed";
gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
@@ -48,17 +49,6 @@ vcc_host_5v: vcc-host-5v-regulator {
vin-supply = <&vcc_sys>;
};
- vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
- compatible = "regulator-fixed";
- gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&usb20_host_drv>;
- regulator-name = "vcc_host1_5v";
- regulator-always-on;
- regulator-boot-on;
- vin-supply = <&vcc_sys>;
- };
-
vcc_sys: vcc-sys {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
--
2.39.2
From: Lorenz Brun <lorenz(a)brun.one>
[ Upstream commit 03633c4ef1fb5ee119296dfe0c411656a9b5e04f ]
Currently the ROCK64 device tree specifies two regulators, vcc_host_5v
and vcc_host1_5v for USB VBUS on the device. Both of those are however
specified with RK_PA2 as the GPIO enabling them, causing the following
error when booting:
rockchip-pinctrl pinctrl: pin gpio0-2 already requested by vcc-host-5v-regulator; cannot claim for vcc-host1-5v-regulator
rockchip-pinctrl pinctrl: pin-2 (vcc-host1-5v-regulator) status -22
rockchip-pinctrl pinctrl: could not request pin 2 (gpio0-2) from group usb20-host-drv on device rockchip-pinctrl
reg-fixed-voltage vcc-host1-5v-regulator: Error applying setting, reverse things back
Looking at the schematic, there are in fact three USB regulators,
vcc_host_5v, vcc_host1_5v and vcc_otg_v5. But the enable signal for all
three is driven by Q2604 which is in turn driven by GPIO_A2/PA2.
Since these three regulators are not controllable separately, I removed
the second one which was causing the error and added labels for all
rails to the single regulator.
Signed-off-by: Lorenz Brun <lorenz(a)brun.one>
Tested-by: Diederik de Haas <didi.debian(a)cknow.org>
Link: https://lore.kernel.org/r/20230421213841.3079632-1-lorenz@brun.one
Signed-off-by: Heiko Stuebner <heiko(a)sntech.de>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
arch/arm64/boot/dts/rockchip/rk3328-rock64.dts | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
index f69a38f42d2d5..0a27fa5271f57 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
@@ -37,7 +37,8 @@ vcc_sd: sdmmc-regulator {
vin-supply = <&vcc_io>;
};
- vcc_host_5v: vcc-host-5v-regulator {
+ /* Common enable line for all of the rails mentioned in the labels */
+ vcc_host_5v: vcc_host1_5v: vcc_otg_5v: vcc-host-5v-regulator {
compatible = "regulator-fixed";
gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
@@ -48,17 +49,6 @@ vcc_host_5v: vcc-host-5v-regulator {
vin-supply = <&vcc_sys>;
};
- vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
- compatible = "regulator-fixed";
- gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&usb20_host_drv>;
- regulator-name = "vcc_host1_5v";
- regulator-always-on;
- regulator-boot-on;
- vin-supply = <&vcc_sys>;
- };
-
vcc_sys: vcc-sys {
compatible = "regulator-fixed";
regulator-name = "vcc_sys";
--
2.39.2
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.14.y
git checkout FETCH_HEAD
git cherry-pick -x c2d22806aecb24e2de55c30a06e5d6eb297d161d
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023062901-public-account-117e@gregkh' --subject-prefix 'PATCH 4.14.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From c2d22806aecb24e2de55c30a06e5d6eb297d161d Mon Sep 17 00:00:00 2001
From: Zhang Shurong <zhang_shurong(a)foxmail.com>
Date: Sun, 25 Jun 2023 00:16:49 +0800
Subject: [PATCH] fbdev: fix potential OOB read in fast_imageblit()
There is a potential OOB read at fast_imageblit, for
"colortab[(*src >> 4)]" can become a negative value due to
"const char *s = image->data, *src".
This change makes sure the index for colortab always positive
or zero.
Similar commit:
https://patchwork.kernel.org/patch/11746067
Potential bug report:
https://groups.google.com/g/syzkaller-bugs/c/9ubBXKeKXf4/m/k-QXy4UgAAAJ
Signed-off-by: Zhang Shurong <zhang_shurong(a)foxmail.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Helge Deller <deller(a)gmx.de>
diff --git a/drivers/video/fbdev/core/sysimgblt.c b/drivers/video/fbdev/core/sysimgblt.c
index 335e92b813fc..665ef7a0a249 100644
--- a/drivers/video/fbdev/core/sysimgblt.c
+++ b/drivers/video/fbdev/core/sysimgblt.c
@@ -189,7 +189,7 @@ static void fast_imageblit(const struct fb_image *image, struct fb_info *p,
u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
u32 bit_mask, eorx, shift;
- const char *s = image->data, *src;
+ const u8 *s = image->data, *src;
u32 *dst;
const u32 *tab;
size_t tablen;
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-4.19.y
git checkout FETCH_HEAD
git cherry-pick -x c2d22806aecb24e2de55c30a06e5d6eb297d161d
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023062953-frosty-dubiously-e01d@gregkh' --subject-prefix 'PATCH 4.19.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From c2d22806aecb24e2de55c30a06e5d6eb297d161d Mon Sep 17 00:00:00 2001
From: Zhang Shurong <zhang_shurong(a)foxmail.com>
Date: Sun, 25 Jun 2023 00:16:49 +0800
Subject: [PATCH] fbdev: fix potential OOB read in fast_imageblit()
There is a potential OOB read at fast_imageblit, for
"colortab[(*src >> 4)]" can become a negative value due to
"const char *s = image->data, *src".
This change makes sure the index for colortab always positive
or zero.
Similar commit:
https://patchwork.kernel.org/patch/11746067
Potential bug report:
https://groups.google.com/g/syzkaller-bugs/c/9ubBXKeKXf4/m/k-QXy4UgAAAJ
Signed-off-by: Zhang Shurong <zhang_shurong(a)foxmail.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Helge Deller <deller(a)gmx.de>
diff --git a/drivers/video/fbdev/core/sysimgblt.c b/drivers/video/fbdev/core/sysimgblt.c
index 335e92b813fc..665ef7a0a249 100644
--- a/drivers/video/fbdev/core/sysimgblt.c
+++ b/drivers/video/fbdev/core/sysimgblt.c
@@ -189,7 +189,7 @@ static void fast_imageblit(const struct fb_image *image, struct fb_info *p,
u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
u32 bit_mask, eorx, shift;
- const char *s = image->data, *src;
+ const u8 *s = image->data, *src;
u32 *dst;
const u32 *tab;
size_t tablen;
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y
git checkout FETCH_HEAD
git cherry-pick -x c2d22806aecb24e2de55c30a06e5d6eb297d161d
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023062944-backless-boastful-fd52@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From c2d22806aecb24e2de55c30a06e5d6eb297d161d Mon Sep 17 00:00:00 2001
From: Zhang Shurong <zhang_shurong(a)foxmail.com>
Date: Sun, 25 Jun 2023 00:16:49 +0800
Subject: [PATCH] fbdev: fix potential OOB read in fast_imageblit()
There is a potential OOB read at fast_imageblit, for
"colortab[(*src >> 4)]" can become a negative value due to
"const char *s = image->data, *src".
This change makes sure the index for colortab always positive
or zero.
Similar commit:
https://patchwork.kernel.org/patch/11746067
Potential bug report:
https://groups.google.com/g/syzkaller-bugs/c/9ubBXKeKXf4/m/k-QXy4UgAAAJ
Signed-off-by: Zhang Shurong <zhang_shurong(a)foxmail.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Helge Deller <deller(a)gmx.de>
diff --git a/drivers/video/fbdev/core/sysimgblt.c b/drivers/video/fbdev/core/sysimgblt.c
index 335e92b813fc..665ef7a0a249 100644
--- a/drivers/video/fbdev/core/sysimgblt.c
+++ b/drivers/video/fbdev/core/sysimgblt.c
@@ -189,7 +189,7 @@ static void fast_imageblit(const struct fb_image *image, struct fb_info *p,
u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
u32 bit_mask, eorx, shift;
- const char *s = image->data, *src;
+ const u8 *s = image->data, *src;
u32 *dst;
const u32 *tab;
size_t tablen;
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y
git checkout FETCH_HEAD
git cherry-pick -x c2d22806aecb24e2de55c30a06e5d6eb297d161d
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023062936-cesarean-acid-5726@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From c2d22806aecb24e2de55c30a06e5d6eb297d161d Mon Sep 17 00:00:00 2001
From: Zhang Shurong <zhang_shurong(a)foxmail.com>
Date: Sun, 25 Jun 2023 00:16:49 +0800
Subject: [PATCH] fbdev: fix potential OOB read in fast_imageblit()
There is a potential OOB read at fast_imageblit, for
"colortab[(*src >> 4)]" can become a negative value due to
"const char *s = image->data, *src".
This change makes sure the index for colortab always positive
or zero.
Similar commit:
https://patchwork.kernel.org/patch/11746067
Potential bug report:
https://groups.google.com/g/syzkaller-bugs/c/9ubBXKeKXf4/m/k-QXy4UgAAAJ
Signed-off-by: Zhang Shurong <zhang_shurong(a)foxmail.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Helge Deller <deller(a)gmx.de>
diff --git a/drivers/video/fbdev/core/sysimgblt.c b/drivers/video/fbdev/core/sysimgblt.c
index 335e92b813fc..665ef7a0a249 100644
--- a/drivers/video/fbdev/core/sysimgblt.c
+++ b/drivers/video/fbdev/core/sysimgblt.c
@@ -189,7 +189,7 @@ static void fast_imageblit(const struct fb_image *image, struct fb_info *p,
u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
u32 bit_mask, eorx, shift;
- const char *s = image->data, *src;
+ const u8 *s = image->data, *src;
u32 *dst;
const u32 *tab;
size_t tablen;
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y
git checkout FETCH_HEAD
git cherry-pick -x c2d22806aecb24e2de55c30a06e5d6eb297d161d
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023062930-passage-rockband-816c@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From c2d22806aecb24e2de55c30a06e5d6eb297d161d Mon Sep 17 00:00:00 2001
From: Zhang Shurong <zhang_shurong(a)foxmail.com>
Date: Sun, 25 Jun 2023 00:16:49 +0800
Subject: [PATCH] fbdev: fix potential OOB read in fast_imageblit()
There is a potential OOB read at fast_imageblit, for
"colortab[(*src >> 4)]" can become a negative value due to
"const char *s = image->data, *src".
This change makes sure the index for colortab always positive
or zero.
Similar commit:
https://patchwork.kernel.org/patch/11746067
Potential bug report:
https://groups.google.com/g/syzkaller-bugs/c/9ubBXKeKXf4/m/k-QXy4UgAAAJ
Signed-off-by: Zhang Shurong <zhang_shurong(a)foxmail.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Helge Deller <deller(a)gmx.de>
diff --git a/drivers/video/fbdev/core/sysimgblt.c b/drivers/video/fbdev/core/sysimgblt.c
index 335e92b813fc..665ef7a0a249 100644
--- a/drivers/video/fbdev/core/sysimgblt.c
+++ b/drivers/video/fbdev/core/sysimgblt.c
@@ -189,7 +189,7 @@ static void fast_imageblit(const struct fb_image *image, struct fb_info *p,
u32 fgx = fgcolor, bgx = bgcolor, bpp = p->var.bits_per_pixel;
u32 ppw = 32/bpp, spitch = (image->width + 7)/8;
u32 bit_mask, eorx, shift;
- const char *s = image->data, *src;
+ const u8 *s = image->data, *src;
u32 *dst;
const u32 *tab;
size_t tablen;
Hi Paul,
A number of stable kernels recently backported this upstream commit:
"""
commit 4ce1f694eb5d8ca607fed8542d32a33b4f1217a5
Author: Paul Moore <paul(a)paul-moore.com>
Date: Wed Apr 12 13:29:11 2023 -0400
selinux: ensure av_permissions.h is built when needed
"""
We're seeing a build issue with this commit where the "crash" tool will fail
to start, it complains that the vmlinux image and /proc/version don't match.
A minimum reproducer would be having "make" version before 4.3 and building
the kernel with:
$ make bzImages
$ make modules
Then compare the version strings in the bzImage and vmlinux images,
we can use "strings" for this. For example, in the 5.10.181 kernel I get:
$ strings vmlinux | egrep '^Linux version'
Linux version 5.10.181 (ec2-user(a)ip-172-31-79-134.ec2.internal) (gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15), GNU ld version 2.29.1-31.amzn2) #2 SMP Thu Jun 1 01:26:38 UTC 2023
$ strings ./arch/x86_64/boot/bzImage | egrep 'ld version'
5.10.181 (ec2-user(a)ip-172-31-79-134.ec2.internal) (gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15), GNU ld version 2.29.1-31.amzn2) #1 SMP Thu Jun 1 01:23:59 UTC 2023
The version string in the bzImage doesn't have the "Linux version" part, but
I think this is added by the kernel when printing. If you compare the strings,
you'll see that they have a different build date and the "#1" and "#2" are
different.
This only happens with commit 4ce1f694eb5 applied and older "make", in my case I
have "make" version 3.82.
If I revert 4ce1f694eb5 or use "make" version 4.3 I get identical strings (except
for the "Linux version" part):
$ strings vmlinux | egrep '^Linux version'
Linux version 5.10.181+ (ec2-user(a)ip-172-31-79-134.ec2.internal) (gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15), GNU ld version 2.29.1-31.amzn2) #1 SMP Thu Jun 1 01:29:11 UTC 2023
$ strings ./arch/x86_64/boot/bzImage | egrep 'ld version'
5.10.181+ (ec2-user(a)ip-172-31-79-134.ec2.internal) (gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-15), GNU ld version 2.29.1-31.amzn2) #1 SMP Thu Jun 1 01:29:11 UTC 2023
Maybe the grouped target usage in 4ce1f694eb5 with older "make" is causing a
rebuild of the vmlinux image in "make modules"? If yes, is this expected?
I'm afraid this issue could be high impact for distros with older user-space.
- Luiz
Hi,
Would you be interested in reaching out to top level decisions makers to promote your services?
Learning Development
Training / Talent Development
CVD Human Resource
CVD Learning
Corporate Training
Meeting & Events
Owners, CEO, Presidents etc
Industries:
Information Technology |Finance |Advertising & Marketing |Construction and Real estate |Charity and NGO’s |Education |Publishing |Retail | Consumer | Manufacturing |Healthcare | Hospitality |Legal Services |Food & Beverages |Media & Entertainment |Energy and chemicals |Aerospace and Defense |Transportation and Logistics Etc.
We customize the list according to your target requirements: - Job titles, Industries and location.
Let us know your target audience and we will send you more details.
Regards,
Claire
Claire Davis | Marketing Consultant
Reply only opt-out in the subject line to remove from the mailing list.
Hi Greg,
below is the manual backport of an upstream patch to fix the build failure
in kernel v4.14 in imsttfb.c.
It's not sufficient to just return from init_imstt() as the kernel then
may crash later when it tries to access the non-existent framebuffer or
cmap. Instead return failure to imsttfb_probe() so that the kernel
will skip using that hardware/driver.
Can you please apply this patch to the v4.14 stable queue?
Thanks,
Helge
-----------
From: Zheng Wang <zyytlz.wz(a)163.com>
This is a manual backport of upstream patch c75f5a55061091030a13fef71b9995b89bc86213
to fix a build error in imsttfb.c in kernel v4.14.
A use-after-free bug may occur if init_imstt invokes framebuffer_release
and free the info ptr. The caller, imsttfb_probe didn't notice that and
still keep the ptr as private data in pdev.
If we remove the driver which will call imsttfb_remove to make cleanup,
UAF happens.
Fix it by return error code if bad case happens in init_imstt.
Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com>
Signed-off-by: Helge Deller <deller(a)gmx.de>
diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c
index 6589d5f0a5a4..eaaa5f1c0f6f 100644
--- a/drivers/video/fbdev/imsttfb.c
+++ b/drivers/video/fbdev/imsttfb.c
@@ -1348,7 +1348,7 @@ static struct fb_ops imsttfb_ops = {
.fb_ioctl = imsttfb_ioctl,
};
-static void init_imstt(struct fb_info *info)
+static int init_imstt(struct fb_info *info)
{
struct imstt_par *par = info->par;
__u32 i, tmp, *ip, *end;
@@ -1420,7 +1420,7 @@ static void init_imstt(struct fb_info *info)
|| !(compute_imstt_regvals(par, info->var.xres, info->var.yres))) {
printk("imsttfb: %ux%ux%u not supported\n", info->var.xres, info->var.yres, info->var.bits_per_pixel);
framebuffer_release(info);
- return;
+ return -ENODEV;
}
sprintf(info->fix.id, "IMS TT (%s)", par->ramdac == IBM ? "IBM" : "TVP");
@@ -1460,12 +1460,13 @@ static void init_imstt(struct fb_info *info)
if (register_framebuffer(info) < 0) {
fb_dealloc_cmap(&info->cmap);
framebuffer_release(info);
- return;
+ return -ENODEV;
}
tmp = (read_reg_le32(par->dc_regs, SSTATUS) & 0x0f00) >> 8;
fb_info(info, "%s frame buffer; %uMB vram; chip version %u\n",
info->fix.id, info->fix.smem_len >> 20, tmp);
+ return 0;
}
static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
@@ -1474,6 +1475,7 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
struct imstt_par *par;
struct fb_info *info;
struct device_node *dp;
+ int ret;
dp = pci_device_to_OF_node(pdev);
if(dp)
@@ -1525,10 +1527,10 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
par->cmap_regs_phys = addr + 0x840000;
par->cmap_regs = (__u8 *)ioremap(addr + 0x840000, 0x1000);
info->pseudo_palette = par->palette;
- init_imstt(info);
-
- pci_set_drvdata(pdev, info);
- return 0;
+ ret = init_imstt(info);
+ if (!ret)
+ pci_set_drvdata(pdev, info);
+ return ret;
}
static void imsttfb_remove(struct pci_dev *pdev)
From: Yi Yang <yiyang13(a)huawei.com>
Kmemleak reported the following leak info in try_smi_init():
unreferenced object 0xffff00018ecf9400 (size 1024):
comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s)
backtrace:
[<000000004ca5b312>] __kmalloc+0x4b8/0x7b0
[<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si]
[<000000006460d325>] 0xffff800081b10148
[<0000000039206ea5>] do_one_initcall+0x64/0x2a4
[<00000000601399ce>] do_init_module+0x50/0x300
[<000000003c12ba3c>] load_module+0x7a8/0x9e0
[<00000000c246fffe>] __se_sys_init_module+0x104/0x180
[<00000000eea99093>] __arm64_sys_init_module+0x24/0x30
[<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250
[<0000000070f4f8b7>] do_el0_svc+0x48/0xe0
[<000000005a05337f>] el0_svc+0x24/0x3c
[<000000005eb248d6>] el0_sync_handler+0x160/0x164
[<0000000030a59039>] el0_sync+0x160/0x180
The problem was that when an error occurred before handlers registration
and after allocating `new_smi->si_sm`, the variable wouldn't be freed in
the error handling afterwards since `shutdown_smi()` hadn't been
registered yet. Fix it by adding a `kfree()` in the error handling path
in `try_smi_init()`.
Cc: stable(a)vger.kernel.org # 4.19+
Fixes: 7960f18a5647 ("ipmi_si: Convert over to a shutdown handler")
Signed-off-by: Yi Yang <yiyang13(a)huawei.com>
Co-developed-by: GONG, Ruiqi <gongruiqi(a)huaweicloud.com>
Signed-off-by: GONG, Ruiqi <gongruiqi(a)huaweicloud.com>
---
drivers/char/ipmi/ipmi_si_intf.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c
index abddd7e43a9a..5cd031f3fc97 100644
--- a/drivers/char/ipmi/ipmi_si_intf.c
+++ b/drivers/char/ipmi/ipmi_si_intf.c
@@ -2082,6 +2082,11 @@ static int try_smi_init(struct smi_info *new_smi)
new_smi->io.io_cleanup = NULL;
}
+ if (rv && new_smi->si_sm) {
+ kfree(new_smi->si_sm);
+ new_smi->si_sm = NULL;
+ }
+
return rv;
}
--
2.25.1
From: Xiubo Li <xiubli(a)redhat.com>
If a client sends out a cap update dropping caps with the prior 'seq'
just before an incoming cap revoke request, then the client may drop
the revoke because it believes it's already released the requested
capabilities.
This causes the MDS to wait indefinitely for the client to respond
to the revoke. It's therefore always a good idea to ack the cap
revoke request with the bumped up 'seq'.
Cc: stable(a)vger.kernel.org
Link: https://tracker.ceph.com/issues/61782
Signed-off-by: Xiubo Li <xiubli(a)redhat.com>
Reviewed-by: Milind Changire <mchangir(a)redhat.com>
Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com>
---
V3:
- Updated the commit message from Patrick. Thanks!
fs/ceph/caps.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
index cef91dd5ef83..e2bb0d0072da 100644
--- a/fs/ceph/caps.c
+++ b/fs/ceph/caps.c
@@ -3566,6 +3566,15 @@ static void handle_cap_grant(struct inode *inode,
}
BUG_ON(cap->issued & ~cap->implemented);
+ /* don't let check_caps skip sending a response to MDS for revoke msgs */
+ if (le32_to_cpu(grant->op) == CEPH_CAP_OP_REVOKE) {
+ cap->mds_wanted = 0;
+ if (cap == ci->i_auth_cap)
+ check_caps = 1; /* check auth cap only */
+ else
+ check_caps = 2; /* check all caps */
+ }
+
if (extra_info->inline_version > 0 &&
extra_info->inline_version >= ci->i_inline_version) {
ci->i_inline_version = extra_info->inline_version;
--
2.40.1
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y
git checkout FETCH_HEAD
git cherry-pick -x 0108a4e9f3584a7a2c026d1601b0682ff7335d95
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023062341-reunite-senior-f0c0@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 0108a4e9f3584a7a2c026d1601b0682ff7335d95 Mon Sep 17 00:00:00 2001
From: Krister Johansen <kjlx(a)templeofstupid.com>
Date: Mon, 12 Jun 2023 17:44:40 -0700
Subject: [PATCH] bpf: ensure main program has an extable
When subprograms are in use, the main program is not jit'd after the
subprograms because jit_subprogs sets a value for prog->bpf_func upon
success. Subsequent calls to the JIT are bypassed when this value is
non-NULL. This leads to a situation where the main program and its
func[0] counterpart are both in the bpf kallsyms tree, but only func[0]
has an extable. Extables are only created during JIT. Now there are
two nearly identical program ksym entries in the tree, but only one has
an extable. Depending upon how the entries are placed, there's a chance
that a fault will call search_extable on the aux with the NULL entry.
Since jit_subprogs already copies state from func[0] to the main
program, include the extable pointer in this state duplication.
Additionally, ensure that the copy of the main program in func[0] is not
added to the bpf_prog_kallsyms table. Instead, let the main program get
added later in bpf_prog_load(). This ensures there is only a single
copy of the main program in the kallsyms table, and that its tag matches
the tag observed by tooling like bpftool.
Cc: stable(a)vger.kernel.org
Fixes: 1c2a088a6626 ("bpf: x64: add JIT support for multi-function programs")
Signed-off-by: Krister Johansen <kjlx(a)templeofstupid.com>
Acked-by: Yonghong Song <yhs(a)fb.com>
Acked-by: Ilya Leoshkevich <iii(a)linux.ibm.com>
Tested-by: Ilya Leoshkevich <iii(a)linux.ibm.com>
Link: https://lore.kernel.org/r/6de9b2f4b4724ef56efbb0339daaa66c8b68b1e7.16866166…
Signed-off-by: Alexei Starovoitov <ast(a)kernel.org>
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 0dd8adc7a159..cf5f230360f5 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -17217,9 +17217,10 @@ static int jit_subprogs(struct bpf_verifier_env *env)
}
/* finally lock prog and jit images for all functions and
- * populate kallsysm
+ * populate kallsysm. Begin at the first subprogram, since
+ * bpf_prog_load will add the kallsyms for the main program.
*/
- for (i = 0; i < env->subprog_cnt; i++) {
+ for (i = 1; i < env->subprog_cnt; i++) {
bpf_prog_lock_ro(func[i]);
bpf_prog_kallsyms_add(func[i]);
}
@@ -17245,6 +17246,8 @@ static int jit_subprogs(struct bpf_verifier_env *env)
prog->jited = 1;
prog->bpf_func = func[0]->bpf_func;
prog->jited_len = func[0]->jited_len;
+ prog->aux->extable = func[0]->aux->extable;
+ prog->aux->num_exentries = func[0]->aux->num_exentries;
prog->aux->func = func;
prog->aux->func_cnt = env->subprog_cnt;
bpf_prog_jit_attempt_done(prog);
This is the start of the stable review cycle for the 4.14.320 release.
There are 26 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Wed, 28 Jun 2023 18:07:23 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.320-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.14.320-rc1
Clark Wang <xiaoning.wang(a)nxp.com>
i2c: imx-lpi2c: fix type char overflow issue when calculating the clock cycle
Dheeraj Kumar Srivastava <dheerajkumar.srivastava(a)amd.com>
x86/apic: Fix kernel panic when booting with intremap=off and x2apic_phys
Min Li <lm0963hack(a)gmail.com>
drm/radeon: fix race condition UAF in radeon_gem_set_domain_ioctl
Min Li <lm0963hack(a)gmail.com>
drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctl
Inki Dae <inki.dae(a)samsung.com>
drm/exynos: vidi: fix a wrong error return
Vineeth Vijayan <vneethv(a)linux.ibm.com>
s390/cio: unregister device when the only path is gone
Dan Carpenter <dan.carpenter(a)linaro.org>
usb: gadget: udc: fix NULL dereference in remove()
Helge Deller <deller(a)gmx.de>
fbdev: imsttfb: Release framebuffer and dealloc cmap on error path
Osama Muhammad <osmtendev(a)gmail.com>
nfcsim.c: Fix error checking for debugfs_create_dir
Marc Zyngier <maz(a)kernel.org>
arm64: Add missing Set/Way CMO encodings
Denis Arefev <arefev(a)swemel.ru>
HID: wacom: Add error check to wacom_parse_and_register()
Maurizio Lombardi <mlombard(a)redhat.com>
scsi: target: iscsi: Prevent login threads from racing between each other
Pablo Neira Ayuso <pablo(a)netfilter.org>
netfilter: nf_tables: disallow element updates of bound anonymous sets
Ross Lagerwall <ross.lagerwall(a)citrix.com>
be2net: Extend xmit workaround to BE3 chip
Sergey Shtylyov <s.shtylyov(a)omp.ru>
mmc: usdhi60rol0: fix deferred probing
Sergey Shtylyov <s.shtylyov(a)omp.ru>
mmc: omap_hsmmc: fix deferred probing
Sergey Shtylyov <s.shtylyov(a)omp.ru>
mmc: omap: fix deferred probing
Sergey Shtylyov <s.shtylyov(a)omp.ru>
mmc: mtk-sd: fix deferred probing
Stefan Wahren <stefan.wahren(a)i2se.com>
net: qca_spi: Avoid high load if QCA7000 is not available
Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
xfrm: Linearize the skb after offloading if needed.
Ryusuke Konishi <konishi.ryusuke(a)gmail.com>
nilfs2: prevent general protection fault in nilfs_clear_dirty_page()
Xiu Jianfeng <xiujianfeng(a)huawei.com>
cgroup: Do not corrupt task iteration when rebinding subsystem
Michael Kelley <mikelley(a)microsoft.com>
Drivers: hv: vmbus: Fix vmbus_wait_for_unload() to scan present CPUs
Ryusuke Konishi <konishi.ryusuke(a)gmail.com>
nilfs2: fix buffer corruption due to concurrent device reads
Ryusuke Konishi <konishi.ryusuke(a)gmail.com>
nilfs2: reject devices with insufficient block count
Bernhard Seibold <mail(a)bernhard-seibold.de>
serial: lantiq: add missing interrupt ack
-------------
Diffstat:
Makefile | 4 +--
arch/arm64/include/asm/sysreg.h | 6 ++++
arch/x86/kernel/apic/x2apic_phys.c | 5 +++-
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 --
drivers/gpu/drm/radeon/radeon_gem.c | 4 +--
drivers/hid/wacom_sys.c | 7 ++++-
drivers/hv/channel_mgmt.c | 18 ++++++++++--
drivers/i2c/busses/i2c-imx-lpi2c.c | 4 +--
drivers/mmc/host/mtk-sd.c | 2 +-
drivers/mmc/host/omap.c | 2 +-
drivers/mmc/host/omap_hsmmc.c | 6 ++--
drivers/mmc/host/usdhi6rol0.c | 6 ++--
drivers/net/ethernet/emulex/benet/be_main.c | 4 +--
drivers/net/ethernet/qualcomm/qca_spi.c | 3 +-
drivers/nfc/nfcsim.c | 4 ---
drivers/s390/cio/device.c | 5 +++-
drivers/target/iscsi/iscsi_target_nego.c | 4 ++-
drivers/tty/serial/lantiq.c | 1 +
drivers/usb/gadget/udc/amd5536udc_pci.c | 3 ++
drivers/video/fbdev/imsttfb.c | 6 +++-
fs/nilfs2/page.c | 10 ++++++-
fs/nilfs2/segbuf.c | 6 ++++
fs/nilfs2/segment.c | 7 +++++
fs/nilfs2/super.c | 25 ++++++++++++++--
fs/nilfs2/the_nilfs.c | 44 ++++++++++++++++++++++++++++-
kernel/cgroup/cgroup.c | 20 +++++++++++--
net/ipv4/esp4_offload.c | 3 ++
net/ipv6/esp6_offload.c | 3 ++
net/netfilter/nf_tables_api.c | 7 +++--
30 files changed, 183 insertions(+), 40 deletions(-)
namespace's request queue is frozen and quiesced during error recovering,
writeback IO is blocked in bio_queue_enter(), so fsync_bdev() <- del_gendisk()
can't move on, and causes IO hang. Removal could be from sysfs, hard
unplug or error handling.
Fix this kind of issue by marking controller as DEAD if removal breaks
error recovery.
This ways is reasonable too, because controller can't be recovered any
more after being removed.
Cc: stable(a)vger.kernel.org
Reported-by: Chunguang Xu <brookxu.cn(a)gmail.com>
Closes: https://lore.kernel.org/linux-nvme/cover.1685350577.git.chunguang.xu@shopee…
Reported-by: Yi Zhang <yi.zhang(a)redhat.com>
Signed-off-by: Ming Lei <ming.lei(a)redhat.com>
---
V2:
- patch style fix, as suggested by Christoph
- document this handling
drivers/nvme/host/core.c | 9 ++++++++-
drivers/nvme/host/nvme.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index fdfcf2781c85..1419eb35b47a 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -567,6 +567,7 @@ bool nvme_change_ctrl_state(struct nvme_ctrl *ctrl,
}
if (changed) {
+ ctrl->old_state = ctrl->state;
ctrl->state = new_state;
wake_up_all(&ctrl->state_wq);
}
@@ -4054,8 +4055,14 @@ void nvme_remove_namespaces(struct nvme_ctrl *ctrl)
* disconnected. In that case, we won't be able to flush any data while
* removing the namespaces' disks; fail all the queues now to avoid
* potentially having to clean up the failed sync later.
+ *
+ * If this removal happens during error recovering, resetting part
+ * may not be started, or controller isn't be recovered completely,
+ * so we have to treat controller as DEAD for avoiding IO hang since
+ * queues can be left as frozen and quiesced.
*/
- if (ctrl->state == NVME_CTRL_DEAD) {
+ if (ctrl->state == NVME_CTRL_DEAD ||
+ ctrl->old_state != NVME_CTRL_LIVE) {
nvme_mark_namespaces_dead(ctrl);
nvme_unquiesce_io_queues(ctrl);
}
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index 9a98c14c552a..ce67856d4d4f 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -254,6 +254,7 @@ struct nvme_ctrl {
bool comp_seen;
bool identified;
enum nvme_ctrl_state state;
+ enum nvme_ctrl_state old_state;
spinlock_t lock;
struct mutex scan_lock;
const struct nvme_ctrl_ops *ops;
--
2.40.1
From: Sheetal <sheetal(a)nvidia.com>
I2S data sanity tests fail beyond a bit clock frequency of 6.144MHz.
This happens because the AHUB clock rate is too low and it shows
9.83MHz on boot.
The maximum rate of PLLA_OUT0 is 49.152MHz and is used to serve I/O
clocks. It is recommended that AHUB clock operates higher than this.
Thus fix this by using PLLP_OUT0 as parent clock for AHUB instead of
PLLA_OUT0 and fix the rate to 81.6MHz.
Fixes: dc94a94daa39 ("arm64: tegra: Add audio devices on Tegra234")
Cc: stable(a)vger.kernel.org
Signed-off-by: Sheetal <sheetal(a)nvidia.com>
Signed-off-by: Sameer Pujar <spujar(a)nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard(a)nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
index f4974e8..0f12a8de 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
@@ -180,7 +180,8 @@
clocks = <&bpmp TEGRA234_CLK_AHUB>;
clock-names = "ahub";
assigned-clocks = <&bpmp TEGRA234_CLK_AHUB>;
- assigned-clock-parents = <&bpmp TEGRA234_CLK_PLLA_OUT0>;
+ assigned-clock-parents = <&bpmp TEGRA234_CLK_PLLP_OUT0>;
+ assigned-clock-rates = <81600000>;
status = "disabled";
#address-cells = <2>;
--
2.7.4
From: Sheetal <sheetal(a)nvidia.com>
Byte mask for channel-1 of stream-1 is not getting enabled and this
causes failures during ADX use cases. This happens because the byte
map value 0 matches the byte map array and put() callback returns
without enabling the corresponding bits in the byte mask.
ADX supports 4 output streams and each stream can have a maximum of
16 channels. Each byte in the input frame is uniquely mapped to a
byte in one of these 4 outputs. This mapping is done with the help of
byte map array via user space control setting. The byte map array
size in the driver is 16 and each array element is of size 4 bytes.
This corresponds to 64 byte map values.
Each byte in the byte map array can have any value between 0 to 255
to enable the corresponding bits in the byte mask. The value 256 is
used as a way to disable the byte map. However the byte map array
element cannot store this value. The put() callback disables the byte
mask for 256 value and byte map value is reset to 0 for this case.
This causes problems during subsequent runs since put() callback,
for value of 0, just returns without enabling the byte mask. In short,
the problem is coming because 0 and 256 control values are stored as
0 in the byte map array.
Right now fix the put() callback by actually looking at the byte mask
array state to identify if any change is needed and update the fields
accordingly. The get() callback needs an update as well to return the
correct control value that user has set before. Note that when user
set 256, the value is stored as 0 and byte mask is disabled. So byte
mask state is used to either return 256 or the value from byte map
array.
Given above, this looks bit complicated and all this happens because
the byte map array is tightly packed and cannot actually store the 256
value. Right now the priority is to fix the existing failure and a TODO
item is put to improve this logic.
Fixes: 3c97881b8c8a ("ASoC: tegra: Fix kcontrol put callback in ADX")
Cc: stable(a)vger.kernel.org
Signed-off-by: Sheetal <sheetal(a)nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard(a)nvidia.com>
Reviewed-by: Sameer Pujar <spujar(a)nvidia.com>
---
sound/soc/tegra/tegra210_adx.c | 34 ++++++++++++++++++++++------------
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/sound/soc/tegra/tegra210_adx.c b/sound/soc/tegra/tegra210_adx.c
index bd0b10c..7d003f0 100644
--- a/sound/soc/tegra/tegra210_adx.c
+++ b/sound/soc/tegra/tegra210_adx.c
@@ -2,7 +2,7 @@
//
// tegra210_adx.c - Tegra210 ADX driver
//
-// Copyright (c) 2021 NVIDIA CORPORATION. All rights reserved.
+// Copyright (c) 2021-2023 NVIDIA CORPORATION. All rights reserved.
#include <linux/clk.h>
#include <linux/device.h>
@@ -175,10 +175,20 @@ static int tegra210_adx_get_byte_map(struct snd_kcontrol *kcontrol,
mc = (struct soc_mixer_control *)kcontrol->private_value;
enabled = adx->byte_mask[mc->reg / 32] & (1 << (mc->reg % 32));
+ /*
+ * TODO: Simplify this logic to just return from bytes_map[]
+ *
+ * Presently below is required since bytes_map[] is
+ * tightly packed and cannot store the control value of 256.
+ * Byte mask state is used to know if 256 needs to be returned.
+ * Note that for control value of 256, the put() call stores 0
+ * in the bytes_map[] and disables the corresponding bit in
+ * byte_mask[].
+ */
if (enabled)
ucontrol->value.integer.value[0] = bytes_map[mc->reg];
else
- ucontrol->value.integer.value[0] = 0;
+ ucontrol->value.integer.value[0] = 256;
return 0;
}
@@ -192,19 +202,19 @@ static int tegra210_adx_put_byte_map(struct snd_kcontrol *kcontrol,
int value = ucontrol->value.integer.value[0];
struct soc_mixer_control *mc =
(struct soc_mixer_control *)kcontrol->private_value;
+ unsigned int mask_val = adx->byte_mask[mc->reg / 32];
- if (value == bytes_map[mc->reg])
+ if (value >= 0 && value <= 255)
+ mask_val |= (1 << (mc->reg % 32));
+ else
+ mask_val &= ~(1 << (mc->reg % 32));
+
+ if (mask_val == adx->byte_mask[mc->reg / 32])
return 0;
- if (value >= 0 && value <= 255) {
- /* update byte map and enable slot */
- bytes_map[mc->reg] = value;
- adx->byte_mask[mc->reg / 32] |= (1 << (mc->reg % 32));
- } else {
- /* reset byte map and disable slot */
- bytes_map[mc->reg] = 0;
- adx->byte_mask[mc->reg / 32] &= ~(1 << (mc->reg % 32));
- }
+ /* Update byte map and slot */
+ bytes_map[mc->reg] = value % 256;
+ adx->byte_mask[mc->reg / 32] = mask_val;
return 1;
}
--
2.7.4
From: Sheetal <sheetal(a)nvidia.com>
Byte mask for channel-1 of stream-1 is not getting enabled and this
causes failures during AMX use cases. This happens because the byte
map value 0 matches the byte map array and put() callback returns
without enabling the corresponding bits in the byte mask.
AMX supports 4 input streams and each stream can take a maximum of
16 channels. Each byte in the output frame is uniquely mapped to a
byte in one of these 4 inputs. This mapping is done with the help of
byte map array via user space control setting. The byte map array
size in the driver is 16 and each array element is of size 4 bytes.
This corresponds to 64 byte map values.
Each byte in the byte map array can have any value between 0 to 255
to enable the corresponding bits in the byte mask. The value 256 is
used as a way to disable the byte map. However the byte map array
element cannot store this value. The put() callback disables the byte
mask for 256 value and byte map value is reset to 0 for this case.
This causes problems during subsequent runs since put() callback,
for value of 0, just returns without enabling the byte mask. In short,
the problem is coming because 0 and 256 control values are stored as
0 in the byte map array.
Right now fix the put() callback by actually looking at the byte mask
array state to identify if any change is needed and update the fields
accordingly. The get() callback needs an update as well to return the
correct control value that user has set before. Note that when user
sets 256, the value is stored as 0 and byte mask is disabled. So byte
mask state is used to either return 256 or the value from byte map
array.
Given above, this looks bit complicated and all this happens because
the byte map array is tightly packed and cannot actually store the 256
value. Right now the priority is to fix the existing failure and a TODO
item is put to improve this logic.
Fixes: 8db78ace1ba8 ("ASoC: tegra: Fix kcontrol put callback in AMX")
Cc: stable(a)vger.kernel.org
Signed-off-by: Sheetal <sheetal(a)nvidia.com>
Reviewed-by: Mohan Kumar D <mkumard(a)nvidia.com>
Reviewed-by: Sameer Pujar <spujar(a)nvidia.com>
---
sound/soc/tegra/tegra210_amx.c | 40 ++++++++++++++++++++++------------------
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/sound/soc/tegra/tegra210_amx.c b/sound/soc/tegra/tegra210_amx.c
index 782a141..1798769 100644
--- a/sound/soc/tegra/tegra210_amx.c
+++ b/sound/soc/tegra/tegra210_amx.c
@@ -2,7 +2,7 @@
//
// tegra210_amx.c - Tegra210 AMX driver
//
-// Copyright (c) 2021 NVIDIA CORPORATION. All rights reserved.
+// Copyright (c) 2021-2023 NVIDIA CORPORATION. All rights reserved.
#include <linux/clk.h>
#include <linux/device.h>
@@ -203,10 +203,20 @@ static int tegra210_amx_get_byte_map(struct snd_kcontrol *kcontrol,
else
enabled = amx->byte_mask[0] & (1 << reg);
+ /*
+ * TODO: Simplify this logic to just return from bytes_map[]
+ *
+ * Presently below is required since bytes_map[] is
+ * tightly packed and cannot store the control value of 256.
+ * Byte mask state is used to know if 256 needs to be returned.
+ * Note that for control value of 256, the put() call stores 0
+ * in the bytes_map[] and disables the corresponding bit in
+ * byte_mask[].
+ */
if (enabled)
ucontrol->value.integer.value[0] = bytes_map[reg];
else
- ucontrol->value.integer.value[0] = 0;
+ ucontrol->value.integer.value[0] = 256;
return 0;
}
@@ -221,25 +231,19 @@ static int tegra210_amx_put_byte_map(struct snd_kcontrol *kcontrol,
unsigned char *bytes_map = (unsigned char *)&amx->map;
int reg = mc->reg;
int value = ucontrol->value.integer.value[0];
+ unsigned int mask_val = amx->byte_mask[reg / 32];
- if (value == bytes_map[reg])
+ if (value >= 0 && value <= 255)
+ mask_val |= (1 << (reg % 32));
+ else
+ mask_val &= ~(1 << (reg % 32));
+
+ if (mask_val == amx->byte_mask[reg / 32])
return 0;
- if (value >= 0 && value <= 255) {
- /* Update byte map and enable slot */
- bytes_map[reg] = value;
- if (reg > 31)
- amx->byte_mask[1] |= (1 << (reg - 32));
- else
- amx->byte_mask[0] |= (1 << reg);
- } else {
- /* Reset byte map and disable slot */
- bytes_map[reg] = 0;
- if (reg > 31)
- amx->byte_mask[1] &= ~(1 << (reg - 32));
- else
- amx->byte_mask[0] &= ~(1 << reg);
- }
+ /* Update byte map and slot */
+ bytes_map[reg] = value % 256;
+ amx->byte_mask[reg / 32] = mask_val;
return 1;
}
--
2.7.4
Before calling add partition or resize partition, there is no check
on whether the length is aligned with the logical block size.
If the logical block size of the disk is larger than 512 bytes,
then the partition size maybe not the multiple of the logical block size,
and when the last sector is read, bio_truncate() will adjust the bio size,
resulting in an IO error if the size of the read command is smaller than
the logical block size.If integrity data is supported, this will also
result in a null pointer dereference when calling bio_integrity_free.
Cc: stable(a)vger.kernel.org
Signed-off-by: Min Li <min15.li(a)samsung.com>
---
Changes from v1:
- Add a space after /* and before */.
- Move length alignment check before the "start = p.start >> SECTOR_SHIFT"
- Move check for p.start being aligned together with this length alignment check.
Changes from v2:
- Add the assignment on the first line and merge the two lines into one.
Changes from v3:
- Change the blksz to unsigned int.
- Add check if p.start and p.length are negative.
---
block/ioctl.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/block/ioctl.c b/block/ioctl.c
index 3be11941fb2d..a8061c2fcae0 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -16,9 +16,10 @@
static int blkpg_do_ioctl(struct block_device *bdev,
struct blkpg_partition __user *upart, int op)
{
+ unsigned int blksz = bdev_logical_block_size(bdev);
struct gendisk *disk = bdev->bd_disk;
struct blkpg_partition p;
- long long start, length;
+ sector_t start, length;
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
@@ -33,14 +34,17 @@ static int blkpg_do_ioctl(struct block_device *bdev,
if (op == BLKPG_DEL_PARTITION)
return bdev_del_partition(disk, p.pno);
+ if (p.start < 0 || p.length <= 0 || p.start + p.length < 0)
+ return -EINVAL;
+ /* Check that the partition is aligned to the block size */
+ if (!IS_ALIGNED(p.start | p.length, blksz))
+ return -EINVAL;
+
start = p.start >> SECTOR_SHIFT;
length = p.length >> SECTOR_SHIFT;
switch (op) {
case BLKPG_ADD_PARTITION:
- /* check if partition is aligned to blocksize */
- if (p.start & (bdev_logical_block_size(bdev) - 1))
- return -EINVAL;
return bdev_add_partition(disk, p.pno, start, length);
case BLKPG_RESIZE_PARTITION:
return bdev_resize_partition(disk, p.pno, start, length);
--
2.34.1
From: Xiubo Li <xiubli(a)redhat.com>
If a client sends out a cap-update request with the old 'seq' just
before a pending cap revoke request, then the MDS might miscalculate
the 'seqs' and caps. It's therefore always a good idea to ack the
cap revoke request with the bumped up 'seq'.
Cc: stable(a)vger.kernel.org
Cc: Patrick Donnelly <pdonnell(a)redhat.com>
URL: https://tracker.ceph.com/issues/61782
Signed-off-by: Xiubo Li <xiubli(a)redhat.com>
---
V2:
- Rephrased the commit comment for better understanding from Milind
fs/ceph/caps.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
index 1052885025b3..eee2fbca3430 100644
--- a/fs/ceph/caps.c
+++ b/fs/ceph/caps.c
@@ -3737,6 +3737,15 @@ static void handle_cap_grant(struct inode *inode,
}
BUG_ON(cap->issued & ~cap->implemented);
+ /* don't let check_caps skip sending a response to MDS for revoke msgs */
+ if (le32_to_cpu(grant->op) == CEPH_CAP_OP_REVOKE) {
+ cap->mds_wanted = 0;
+ if (cap == ci->i_auth_cap)
+ check_caps = 1; /* check auth cap only */
+ else
+ check_caps = 2; /* check all caps */
+ }
+
if (extra_info->inline_version > 0 &&
extra_info->inline_version >= ci->i_inline_version) {
ci->i_inline_version = extra_info->inline_version;
--
2.40.1
commit 1c249565426e3a9940102c0ba9f63914f7cda73d upstream.
This problem was encountered on an arm64 system with a lot of memory.
Without kernel debug symbols installed, and with both kcore and kallsyms
available, perf managed to get confused and returned "unknown" for all
of the kernel symbols that it tried to look up.
On this system, stext fell within the vmalloc segment. The kcore symbol
matching code tries to find the first segment that contains stext and
uses that to replace the segment generated from just the kallsyms
information. In this case, however, there were two: a very large
vmalloc segment, and the text segment. This caused perf to get confused
because multiple overlapping segments were inserted into the RB tree
that holds the discovered segments. However, that alone wasn't
sufficient to cause the problem. Even when we could find the segment,
the offsets were adjusted in such a way that the newly generated symbols
didn't line up with the instruction addresses in the trace. The most
obvious solution would be to consult which segment type is text from
kcore, but this information is not exposed to users.
Instead, select the smallest matching segment that contains stext
instead of the first matching segment. This allows us to match the text
segment instead of vmalloc, if one is contained within the other.
Reviewed-by: Adrian Hunter <adrian.hunter(a)intel.com>
Signed-off-by: Krister Johansen <kjlx(a)templeofstupid.com>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: David Reaver <me(a)davidreaver.com>
Cc: Ian Rogers <irogers(a)google.com>
Cc: Jiri Olsa <jolsa(a)kernel.org>
Cc: Mark Rutland <mark.rutland(a)arm.com>
Cc: Michael Petlan <mpetlan(a)redhat.com>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Link: http://lore.kernel.org/lkml/20230125183418.GD1963@templeofstupid.com
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
Signed-off-by: Krister Johansen <kjlx(a)templeofstupid.com>
---
tools/perf/util/symbol.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index a3a165ae933a..98014f937568 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1368,10 +1368,23 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
/* Find the kernel map using the '_stext' symbol */
if (!kallsyms__get_function_start(kallsyms_filename, "_stext", &stext)) {
+ u64 replacement_size = 0;
+
list_for_each_entry(new_map, &md.maps, node) {
- if (stext >= new_map->start && stext < new_map->end) {
+ u64 new_size = new_map->end - new_map->start;
+
+ if (!(stext >= new_map->start && stext < new_map->end))
+ continue;
+
+ /*
+ * On some architectures, ARM64 for example, the kernel
+ * text can get allocated inside of the vmalloc segment.
+ * Select the smallest matching segment, in case stext
+ * falls within more than one in the list.
+ */
+ if (!replacement_map || new_size < replacement_size) {
replacement_map = new_map;
- break;
+ replacement_size = new_size;
}
}
}
--
2.25.1
We have to verify the selected mode as Userspace might request one which
we can't configure the GPU for.
X with the modesetting DDX is adding a bunch of modes, some so far outside
of hardware limits that things simply break.
Sadly we can't fix X this way as on start it sticks to one mode and
ignores any error and there is really nothing we can do about this, but at
least this way we won't let the GPU run into any errors caused by a non
supported display mode.
However this does prevent X from switching to such a mode, which to be
fair is an improvement as well.
Seen on one of my Tesla GPUs with a connected 4K display.
Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/199
Cc: Ben Skeggs <bskeggs(a)redhat.com>
Cc: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org # v6.1+
Signed-off-by: Karol Herbst <kherbst(a)redhat.com>
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 22c42a5e184d..edf490c1490c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1114,6 +1114,25 @@ nouveau_connector_atomic_check(struct drm_connector *connector, struct drm_atomi
struct drm_connector_state *conn_state =
drm_atomic_get_new_connector_state(state, connector);
+ /* As we can get any random mode from Userspace, we have to make sure the to be set mode
+ * is valid and does not violate hardware constraints as we rely on it being sane.
+ */
+ if (conn_state->crtc) {
+ struct drm_crtc_state *crtc_state =
+ drm_atomic_get_crtc_state(state, conn_state->crtc);
+
+ if (IS_ERR(crtc_state))
+ return PTR_ERR(crtc_state);
+
+ if (crtc_state->enable && (crtc_state->mode_changed ||
+ crtc_state->connectors_changed)) {
+ struct drm_display_mode *mode = &crtc_state->mode;
+
+ if (connector->helper_private->mode_valid(connector, mode) != MODE_OK)
+ return -EINVAL;
+ }
+ }
+
if (!nv_conn->dp_encoder || !nv50_has_mst(nouveau_drm(connector->dev)))
return 0;
--
2.41.0