4.19.323-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 312/350 dt-bindings: power: Add r8a774b1 SYSC power domain definitions
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Biju Das <[email protected]>
[ Upstream commit be67c41781cb4c06a4acb0b92db0cbb728e955e2 ]
This patch adds power domain indices for the RZ/G2N (a.k.a r8a774b1) SoC.
Stable-dep-of: 8a7d12d674ac ("net: usb: usbnet: fix name regression")
--- include/dt-bindings/power/r8a774b1-sysc.h | 26 +++++++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 include/dt-bindings/power/r8a774b1-sysc.h
include/dt-bindings/power/r8a774b1-sysc.h new file +26 -0
@@ -0,0 +1,26 @@ +/* SPDX-License-Identifier: GPL-2.0 +* +* Copyright (C) 2019 Renesas Electronics Corp. +*/ +#ifndef __DT_BINDINGS_POWER_R8A774B1_SYSC_H__ +#define __DT_BINDINGS_POWER_R8A774B1_SYSC_H__ + +/* +* These power domain indices match the numbers of the interrupt bits +* representing the power areas in the various Interrupt Registers +* (e.g. SYSCISR, Interrupt Status Register) +*/ + +#define R8A774B1_PD_CA57_CPU0 0 +#define R8A774B1_PD_CA57_CPU1 1 +#define R8A774B1_PD_A3VP 9 +#define R8A774B1_PD_CA57_SCU 12 +#define R8A774B1_PD_A3VC 14 +#define R8A774B1_PD_3DG_A 17 +#define R8A774B1_PD_3DG_B 18 +#define R8A774B1_PD_A2VC1 26 + +/* Always-on power area */ +#define R8A774B1_PD_ALWAYS_ON 32 + +#endif /* __DT_BINDINGS_POWER_R8A774B1_SYSC_H__ */
Signature · 1 line
2.43.0
Re: [PATCH 4.19 312/350] dt-bindings: power: Add r8a774b1 SYSC power domain definitions
Hi Greg,
Quoted 10 lines · Greg Kroah-Hartman
4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Biju Das <[email protected]>
[ Upstream commit
be67c41781cb4c06a4acb0b92db0cbb728e955e2]This patch adds power domain indices for the RZ/G2N (a.k.a r8a774b1) SoC.
Why is this being backported?
It is (only a small subset of) new hardware support.
Quoted 4 lines
Signed-off-by Biju Das <[email protected]>Signed-off-by Geert Uytterhoeven <[email protected]>Stable-dep-of:
8a7d12d674ac("net: usb: usbnet: fix name regression")
This is completely unrelated?
Quoted 1 line
Signed-off-by Sasha Levin <[email protected]>
Gr{oetje,eeting}s,
Geert
Signature · 5 lines
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected] In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Greg Kroah-Hartman
maintainerRe: [PATCH 4.19 312/350] dt-bindings: power: Add r8a774b1 SYSC power domain definitions
Quoted 18 lines · Geert Uytterhoeven
Hi Greg,
Quoted 10 lines · Greg Kroah-Hartman
4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Biju Das <[email protected]>
[ Upstream commit
be67c41781cb4c06a4acb0b92db0cbb728e955e2]This patch adds power domain indices for the RZ/G2N (a.k.a r8a774b1) SoC.
Why is this being backported?
It is (only a small subset of) new hardware support.
Quoted 6 lines
Quoted 4 lines
Signed-off-by Biju Das <[email protected]>Signed-off-by Geert Uytterhoeven <[email protected]>Stable-dep-of:
8a7d12d674ac("net: usb: usbnet: fix name regression")This is completely unrelated?
Now dropped from both trees, thanks.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 313/350 net: usb: usbnet: fix name regression
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Oliver Neukum <[email protected]>
[ Upstream commit 8a7d12d674ac6f2147c18f36d1e15f1a48060edf ]
The fix for MAC addresses broke detection of the naming convention because it gave network devices no random MAC before bind() was called. This means that the check for the local assignment bit was always negative as the address was zeroed from allocation, instead of from overwriting the MAC with a unique hardware address.
The correct check for whether bind() has altered the MAC is done with is_zero_ether_addr
--- drivers/net/usb/usbnet.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/usb/usbnet.c +2 -1
@@ -1746,7 +1746,8 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod)// can rename the link if it knows better. if ((dev->driver_info->flags &FLAG_ETHER ) !=0 && ((dev->driver_info->flags &FLAG_POINTTOPOINT ) ==0 || - (net->dev_addr [0 ] &0x02 ) ==0 )) +/* somebody touched it*/ + !is_zero_ether_addr (net->dev_addr)))strscpy (net->name,"eth%d" ,sizeof (net->name));/* WLAN devices should always be named "wlan%d" */ if ((dev->driver_info->flags &FLAG_WLAN ) !=0 )
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 314/350 posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jinjie Ruan <[email protected]>
[ Upstream commit 6e62807c7fbb3c758d233018caf94dfea9c65dbd ]
If get_clock_desc() succeeds, it calls fget() for the clockid's fd, and get the clk->rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid's fd to make the refcount balance and release the fd related resource.
However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the "ts" is not changed after that.
--- kernel/time/posix-clock.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
kernel/time/posix-clock.c +3 -3
@@ -303,6 +303,9 @@ static int pc_clock_settime(clockid_t id, const struct timespec64 *ts)struct posix_clock_desc cd;int err; +if (!timespec64_valid_strict (ts)) +return -EINVAL ; + err =get_clock_desc (id, &cd);if (err)return err;
@@ -312,9 +315,6 @@ static int pc_clock_settime(clockid_t id, const struct timespec64 *ts) goto out; } -if (!timespec64_valid_strict (ts)) -return -EINVAL ; -if (cd.clk->ops.clock_settime) err = cd.clk->ops.clock_settime (cd.clk, ts);else
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 315/350 ALSA: hda/realtek: Update default depop procedure
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kailang Yang <[email protected]>
[ Upstream commit e3ea2757c312e51bbf62ebc434a6f7df1e3a201f ]
Old procedure has a chance to meet Headphone no output.
--- sound/pci/hda/patch_realtek.c | 38 ++++++++++++++++------------------- 1 file changed, 17 insertions(+), 21 deletions(-)
sound/pci/hda/patch_realtek.c +17 -21
@@ -3537,20 +3537,18 @@ static void alc_default_init(struct hda_codec *codec) hp_pin_sense =snd_hda_jack_detect (codec, hp_pin); -if (hp_pin_sense) +if (hp_pin_sense) {msleep (2 ); -snd_hda_codec_write (codec, hp_pin,0 , -AC_VERB_SET_AMP_GAIN_MUTE ,AMP_OUT_MUTE ); - -if (hp_pin_sense) -msleep (85 ); +snd_hda_codec_write (codec, hp_pin,0 , +AC_VERB_SET_PIN_WIDGET_CONTROL ,PIN_OUT ); -snd_hda_codec_write (codec, hp_pin,0 , -AC_VERB_SET_PIN_WIDGET_CONTROL ,PIN_OUT ); +msleep (75 ); -if (hp_pin_sense) -msleep (100 ); +snd_hda_codec_write (codec, hp_pin,0 , +AC_VERB_SET_AMP_GAIN_MUTE ,AMP_OUT_UNMUTE ); +msleep (75 ); + } }static void alc_default_shutup (struct hda_codec *codec)
@@ -3566,22 +3564,20 @@ static void alc_default_shutup(struct hda_codec *codec) hp_pin_sense =snd_hda_jack_detect (codec, hp_pin); -if (hp_pin_sense) +if (hp_pin_sense) {msleep (2 ); -snd_hda_codec_write (codec, hp_pin,0 , -AC_VERB_SET_AMP_GAIN_MUTE ,AMP_OUT_MUTE ); - -if (hp_pin_sense) -msleep (85 ); - -if (!spec->no_shutup_pins)snd_hda_codec_write (codec, hp_pin,0 , -AC_VERB_SET_PIN_WIDGET_CONTROL ,0x0 ); +AC_VERB_SET_AMP_GAIN_MUTE ,AMP_OUT_MUTE ); -if (hp_pin_sense) -msleep (100 ); +msleep (75 ); +if (!spec->no_shutup_pins) +snd_hda_codec_write (codec, hp_pin,0 , +AC_VERB_SET_PIN_WIDGET_CONTROL ,0x0 ); + +msleep (75 ); + }alc_auto_setup_eapd (codec, false);alc_shutup_pins (codec); }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 316/350 drm/amd: Guard against bad data for ATIF ACPI method
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello <[email protected]>
commit bf58f03931fdcf7b3c45cb76ac13244477a60f44 upstream.
If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller.
``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ```
It has been encountered on at least one system, so guard for it.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c +12 -3
@@ -90,6 +90,7 @@ static union acpi_object *amdgpu_atif_ca struct acpi_buffer *params) {acpi_status status; +union acpi_object *obj;union acpi_object atif_arg_elements[2 ];struct acpi_object_list atif_arg;struct acpi_buffer buffer = {ACPI_ALLOCATE_BUFFER ,NULL };
@@ -112,16 +113,24 @@ static union acpi_object *amdgpu_atif_ca status =acpi_evaluate_object (atif->handle,NULL , &atif_arg, &buffer); + obj = (union acpi_object *)buffer.pointer; -/* Fail only if calling the method fails and ATIF is supported */ +/* Fail if calling the method fails and ATIF is supported */ if (ACPI_FAILURE (status) && status !=AE_NOT_FOUND ) {DRM_DEBUG_DRIVER ("failed to evaluate ATIF got %s\n" ,acpi_format_exception (status)); -kfree (buffer.pointer); +kfree (obj);return NULL ; } -return buffer.pointer; +if (obj->type !=ACPI_TYPE_BUFFER ) { +DRM_DEBUG_DRIVER ("bad object returned from ATIF: %d\n" , + obj->type); +kfree (obj); +return NULL ; + } + +return obj; }/**
Greg Kroah-Hartman
maintainerPATCH 317/350 ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid detection issue
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shubham Panwar <[email protected]>
commit 8fa73ee44daefc884c53a25158c25a4107eb5a94 upstream.
Add a DMI quirk for Samsung Galaxy Book2 to fix an initial lid state detection issue.
The _LID device incorrectly returns the lid status as "closed" during boot, causing the system to enter a suspend loop right after booting.
The quirk ensures that the correct lid state is reported initially, preventing the system from immediately suspending after startup. It only addresses the initial lid state detection and ensures proper system behavior upon boot.
--- drivers/acpi/button.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/acpi/button.c +11 -0
@@ -124,6 +124,17 @@ static const struct dmi_system_id lid_bl }, .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN, }, + { + /* + * Samsung galaxybook2 ,initial _LID device notification returns + * lid closed. + */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), + DMI_MATCH(DMI_PRODUCT_NAME, "750XED"), + }, + .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN, + }, {} };
Greg Kroah-Hartman
maintainerPATCH 318/350 nilfs2: fix kernel bug due to missing clearing of buffer delay flag
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryusuke Konishi <[email protected]>
commit 6ed469df0bfbef3e4b44fca954a781919db9f7ab upstream.
Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug.
This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this.
This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing.
--- fs/nilfs2/page.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
fs/nilfs2/page.c +4 -2
@@ -78,7 +78,8 @@ void nilfs_forget_buffer(struct buffer_hconst unsigned long clear_bits = (BIT (BH_Uptodate) |BIT (BH_Dirty) |BIT (BH_Mapped) |BIT (BH_Async_Write) |BIT (BH_NILFS_Volatile) | -BIT (BH_NILFS_Checked) |BIT (BH_NILFS_Redirected)); +BIT (BH_NILFS_Checked) |BIT (BH_NILFS_Redirected) | +BIT (BH_Delay));lock_buffer (bh);set_mask_bits (&bh->b_state, clear_bits,0 );
@@ -412,7 +413,8 @@ void nilfs_clear_dirty_page(struct pageconst unsigned long clear_bits = (BIT (BH_Uptodate) |BIT (BH_Dirty) |BIT (BH_Mapped) |BIT (BH_Async_Write) |BIT (BH_NILFS_Volatile) | -BIT (BH_NILFS_Checked) |BIT (BH_NILFS_Redirected)); +BIT (BH_NILFS_Checked) |BIT (BH_NILFS_Redirected) | +BIT (BH_Delay)); bh = head =page_buffers (page); do {
Greg Kroah-Hartman
maintainerPATCH 319/350 hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haiyang Zhang <[email protected]>
commit 4c262801ea60c518b5bebc22a09f5b78b3147da2 upstream.
The existing code moves VF to the same namespace as the synthetic NIC during netvsc_register_vf(). But, if the synthetic device is moved to a new namespace after the VF registration, the VF won't be moved together.
To make the behavior more consistent, add a namespace check for synthetic NIC's NETDEV_REGISTER event (generated during its move), and move the VF if it is not in the same namespace.
--- drivers/net/hyperv/netvsc_drv.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
drivers/net/hyperv/netvsc_drv.c +30 -0
@@ -2526,6 +2526,31 @@ static struct hv_driver netvsc_drv = { }, }; +/* Set VF's namespace same as the synthetic NIC */ +static void netvsc_event_set_vf_ns (struct net_device *ndev) +{ +struct net_device_context *ndev_ctx =netdev_priv (ndev); +struct net_device *vf_netdev; +int ret; + + vf_netdev =rtnl_dereference (ndev_ctx->vf_netdev); +if (!vf_netdev) +return ; + +if (!net_eq (dev_net (ndev),dev_net (vf_netdev))) { + ret =dev_change_net_namespace (vf_netdev,dev_net (ndev), +"eth%d" ); +if (ret) +netdev_err (vf_netdev, +"Cannot move to same namespace as %s: %d\n" , + ndev->name, ret); +else +netdev_info (vf_netdev, +"Moved VF to namespace with: %s\n" , + ndev->name); + } +} +/* * On Hyper-V, every VF interface is matched with a corresponding * synthetic interface. The synthetic interface is presented first
@@ -2538,6 +2563,11 @@ static int netvsc_netdev_event(struct nostruct net_device *event_dev =netdev_notifier_info_to_dev (ptr);int ret =0 ; +if (event_dev->netdev_ops == &device_ops && event ==NETDEV_REGISTER ) { +netvsc_event_set_vf_ns (event_dev); +return NOTIFY_DONE ; + } + ret =check_dev_is_matching_vf (event_dev);if (ret !=0 )return NOTIFY_DONE ;
Greg Kroah-Hartman
maintainerPATCH 320/350 selinux: improve error checking in sel_write_load()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Moore <[email protected]>
[ Upstream commit 42c773238037c90b3302bf37a57ae3b5c3f6004a ]
Move our existing input sanity checking to the top of sel_write_load() and add a check to ensure the buffer size is non-zero.
Move a local variable initialization from the declaration to before it is used.
Minor style adjustments.
--- security/selinux/selinuxfs.c | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-)
security/selinux/selinuxfs.c +17 -14
@@ -536,6 +536,16 @@ static ssize_t sel_write_load(struct file *file, const char __user *buf,ssize_t length;void *data =NULL ; +/* no partial writes */ +if (*ppos) +return -EINVAL ; +/* no empty policies */ +if (!count) +return -EINVAL ; + +if (count >64 *1024 *1024 ) +return -EFBIG ; +mutex_lock (&fsi->mutex); length = avc_has_perm(&selinux_state,
@@ -544,23 +554,15 @@ static ssize_t sel_write_load(struct file *file, const char __user *buf,if (length) goto out; -/* No partial writes. */ - length = -EINVAL ; -if (*ppos !=0 ) - goto out; - - length = -EFBIG ; -if (count >64 *1024 *1024 ) - goto out; - - length = -ENOMEM ; data =vmalloc (count); -if (!data) +if (!data) { + length = -ENOMEM ; goto out; - - length = -EFAULT ; -if (copy_from_user (data, buf, count) !=0 ) + } +if (copy_from_user (data, buf, count) !=0 ) { + length = -EFAULT ; goto out; + } length =security_load_policy (fsi->state, data, count);if (length) {
@@ -579,6 +581,7 @@ static ssize_t sel_write_load(struct file *file, const char __user *buf,"auid=%u ses=%u lsm=selinux res=1" ,from_kuid (&init_user_ns,audit_get_loginuid (current)), audit_get_sessionid(current)); + out:mutex_unlock (&fsi->mutex);vfree (data);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 321/350 arm64/uprobes: change the uprobe_opcode_t typedef to fix the sparse warning
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: junhua huang <[email protected]>
commit ef08c0fadd8a17ebe429b85e23952dac3263ad34 upstream.
After we fixed the uprobe inst endian in aarch_be, the sparse check report the following warning info:
sparse warnings: (new ones prefixed by >>)
Quoted 2 lines
Quoted 2 lines
kernel/events/uprobes.c:223:25: sparse: sparse: restricted__le32degrades to integerkernel/events/uprobes.c:574:56: sparse: sparse: incorrect type in argument 4 (different base types)
@@ expected unsigned int [addressable] [usertype] opcode @@ got restricted __le32 [usertype] @@
kernel/events/uprobes.c:574:56: sparse: expected unsigned int [addressable] [usertype] opcode
kernel/events/uprobes.c:574:56: sparse: got restricted __le32 [usertype]
Quoted 1 line
Quoted 1 line
kernel/events/uprobes.c:1483:32: sparse: sparse: incorrect type in initializer (different base types)
@@ expected unsigned int [usertype] insn @@ got restricted __le32 [usertype] @@
kernel/events/uprobes.c:1483:32: sparse: expected unsigned int [usertype] insn
kernel/events/uprobes.c:1483:32: sparse: got restricted __le32 [usertype]
use the __le32 to u32 for uprobe_opcode_t, to keep the same.
--- arch/arm64/include/asm/uprobes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/include/asm/uprobes.h +1 -1
@@ -17,7 +17,7 @@#define UPROBE_SWBP_INSN_SIZE AARCH64_INSN_SIZE#define UPROBE_XOL_SLOT_BYTES AARCH64_INSN_SIZE -typedef u32 uprobe_opcode_t ; +typedef __le32 uprobe_opcode_t ;struct arch_uprobe_task { };
Greg Kroah-Hartman
maintainerPATCH 322/350 xfrm: validate new SAs prefixlen using SA family when sel.family is unset
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sabrina Dubroca <[email protected]>
[ Upstream commit 3f0ab59e6537c6a8f9e1b355b48f9c05a76e8563 ]
This expands the validation introduced in commit 07bf7908950a ("xfrm:
Validate address prefix lengths in the xfrm selector.")
syzbot created an SA with
usersa.sel.family = AF_UNSPEC
usersa.sel.prefixlen_s = 128
usersa.family = AF_INET
Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on.
--- net/xfrm/xfrm_user.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
net/xfrm/xfrm_user.c +5 -1
@@ -148,6 +148,7 @@ static int verify_newsa_info(struct xfrm_usersa_info *p, struct nlattr **attrs) {int err; +u16 family = p->sel.family; err = -EINVAL ;switch (p->family) {
@@ -166,7 +167,10 @@ static int verify_newsa_info(struct xfrm_usersa_info *p, goto out; } -switch (p->sel.family) { +if (!family && !(p->flags &XFRM_STATE_AF_UNSPEC )) + family = p->family; + +switch (family) {case AF_UNSPEC :break ;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 323/350 usb: dwc3: remove generic PHY calibrate() calls
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Szyprowski <[email protected]>
[ Upstream commit a0a465569b45e3690be155c96fb54603d6904f41 ]
Calls to USB2 generic PHY calibrate() method has been moved to HCD core, which now successfully handles generic PHYs and their calibration after every HCD reset. This fixes all the timing issues related to PHY calibration done directly from DWC3 driver: incorrect operation after system suspend/resume or USB3.0 detection failure when XHCI-plat driver compiled as separate module.
Stable-dep-of: 0d410e8913f5 ("usb: dwc3: core: Stop processing of pending events if controller is halted")
--- drivers/usb/dwc3/core.c | 2 -- 1 file changed, 2 deletions(-)
drivers/usb/dwc3/core.c +0 -2
@@ -167,7 +167,6 @@ static void __dwc3_set_mode(struct work_struct *work)otg_set_vbus (dwc->usb2_phy->otg, true);phy_set_mode (dwc->usb2_generic_phy,PHY_MODE_USB_HOST );phy_set_mode (dwc->usb3_generic_phy,PHY_MODE_USB_HOST ); -phy_calibrate (dwc->usb2_generic_phy); }break ;case DWC3_GCTL_PRTCAP_DEVICE :
@@ -1178,7 +1177,6 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)dev_err (dev,"failed to initialize host\n" );return ret; } -phy_calibrate (dwc->usb2_generic_phy);break ;case USB_DR_MODE_OTG :INIT_WORK (&dwc->drd_work, __dwc3_set_mode);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 324/350 usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Chen <[email protected]>
[ Upstream commit f580170f135af14e287560d94045624d4242d712 ]
SPLIT_BOUNDARY_DISABLE should be set for DesignWare USB3 DRD Core of Hisilicon Kirin Soc when dwc3 core act as host.
[mchehab: dropped a dev_dbg() as only traces are now allowwed on this driver]
Stable-dep-of: 0d410e8913f5 ("usb: dwc3: core: Stop processing of pending events if controller is halted")
--- drivers/usb/dwc3/core.c | 25 +++++++++++++++++++++++++ drivers/usb/dwc3/core.h | 7 +++++++ 2 files changed, 32 insertions(+)
drivers/usb/dwc3/core.c +25 -0
@@ -116,6 +116,7 @@ static void __dwc3_set_mode(struct work_struct *work)struct dwc3 *dwc =work_to_dwc (work);unsigned long flags;int ret; +u32 reg;if (dwc->dr_mode !=USB_DR_MODE_OTG )return ;
@@ -167,6 +168,11 @@ static void __dwc3_set_mode(struct work_struct *work)otg_set_vbus (dwc->usb2_phy->otg, true);phy_set_mode (dwc->usb2_generic_phy,PHY_MODE_USB_HOST );phy_set_mode (dwc->usb3_generic_phy,PHY_MODE_USB_HOST ); +if (dwc->dis_split_quirk) { + reg =dwc3_readl (dwc->regs,DWC3_GUCTL3 ); + reg |=DWC3_GUCTL3_SPLITDISABLE ; +dwc3_writel (dwc->regs,DWC3_GUCTL3 , reg); + } }break ;case DWC3_GCTL_PRTCAP_DEVICE :
@@ -1314,6 +1320,9 @@ static void dwc3_get_properties(struct dwc3 *dwc) dwc->dis_metastability_quirk =device_property_read_bool (dev,"snps,dis_metastability_quirk" ); + dwc->dis_split_quirk =device_property_read_bool (dev, +"snps,dis-split-quirk" ); + dwc->lpm_nyet_threshold = lpm_nyet_threshold; dwc->tx_de_emphasis = tx_de_emphasis;
@@ -1850,10 +1859,26 @@ static int dwc3_resume(struct device *dev) return 0; } + +static void dwc3_complete (struct device *dev) +{ +struct dwc3 *dwc =dev_get_drvdata (dev); +u32 reg; + +if (dwc->current_dr_role ==DWC3_GCTL_PRTCAP_HOST && + dwc->dis_split_quirk) { + reg =dwc3_readl (dwc->regs,DWC3_GUCTL3 ); + reg |=DWC3_GUCTL3_SPLITDISABLE ; +dwc3_writel (dwc->regs,DWC3_GUCTL3 , reg); + } +} +#else +#define dwc3_complete NULL#endif /* CONFIG_PM_SLEEP */ static const struct dev_pm_ops dwc3_dev_pm_ops = {SET_SYSTEM_SLEEP_PM_OPS (dwc3_suspend, dwc3_resume) + .complete = dwc3_complete,SET_RUNTIME_PM_OPS (dwc3_runtime_suspend, dwc3_runtime_resume, dwc3_runtime_idle) };
drivers/usb/dwc3/core.h +7 -0
@@ -135,6 +135,7 @@#define DWC3_GEVNTCOUNT (n) (0xc40c + ((n) * 0x10))#define DWC3_GHWPARAMS8 0xc600 +#define DWC3_GUCTL3 0xc60c#define DWC3_GFLADJ 0xc630/* Device Registers */
@@ -362,6 +363,9 @@/* Global User Control Register 2 */ #define DWC3_GUCTL2_RST_ACTBITLATER BIT(14) +/* Global User Control Register 3 */ +#define DWC3_GUCTL3_SPLITDISABLE BIT(14) +/* Device Configuration Register */ #define DWC3_DCFG_DEVADDR (addr) ((addr) << 3)#define DWC3_DCFG_DEVADDR_MASK DWC3_DCFG_DEVADDR(0x7f)
@@ -1004,6 +1008,7 @@ struct dwc3_scratchpad_array {* 2 - No de-emphasis * 3 - Reserved * @dis_metastability_quirk: set to disable metastability quirk. +* @dis_split_quirk: set to disable split boundary. * @imod_interval: set the interrupt moderation interval in 250ns * increments or 0 to disable. */
@@ -1175,6 +1180,8 @@ struct dwc3 { unsigned dis_metastability_quirk:1; + unsigned dis_split_quirk:1; +u16 imod_interval; };
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 325/350 usb: dwc3: core: Stop processing of pending events if controller is halted
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Selvarasu Ganesan <[email protected]>
[ Upstream commit 0d410e8913f5cffebcca79ffdd596009d4a13a28 ]
This commit addresses an issue where events were being processed when the controller was in a halted state. To fix this issue by stop processing the events as the event count was considered stale or invalid when the controller was halted.
--- drivers/usb/dwc3/core.c | 22 +++++++++++++++++++--- drivers/usb/dwc3/core.h | 4 ---- drivers/usb/dwc3/gadget.c | 11 ----------- 3 files changed, 19 insertions(+), 18 deletions(-)
drivers/usb/dwc3/core.c +19 -3
@@ -404,6 +404,7 @@ static int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned length)int dwc3_event_buffers_setup (struct dwc3 *dwc) {struct dwc3_event_buffer *evt; +u32 reg;if (!dwc->ev_buf)return 0 ;
@@ -416,8 +417,10 @@ int dwc3_event_buffers_setup(struct dwc3 *dwc) upper_32_bits(evt->dma));dwc3_writel (dwc->regs,DWC3_GEVNTSIZ (0 ),DWC3_GEVNTSIZ_SIZE (evt->length)); -dwc3_writel (dwc->regs,DWC3_GEVNTCOUNT (0 ),0 ); +/* Clear any stale event */ + reg =dwc3_readl (dwc->regs,DWC3_GEVNTCOUNT (0 )); +dwc3_writel (dwc->regs,DWC3_GEVNTCOUNT (0 ), reg);return 0 ; }
@@ -444,7 +447,10 @@ void dwc3_event_buffers_cleanup(struct dwc3 *dwc)dwc3_writel (dwc->regs,DWC3_GEVNTADRHI (0 ),0 );dwc3_writel (dwc->regs,DWC3_GEVNTSIZ (0 ),DWC3_GEVNTSIZ_INTMASK |DWC3_GEVNTSIZ_SIZE (0 )); -dwc3_writel (dwc->regs,DWC3_GEVNTCOUNT (0 ),0 ); + +/* Clear any stale event */ + reg =dwc3_readl (dwc->regs,DWC3_GEVNTCOUNT (0 )); +dwc3_writel (dwc->regs,DWC3_GEVNTCOUNT (0 ), reg); }static int dwc3_alloc_scratch_buffers (struct dwc3 *dwc)
@@ -1792,7 +1798,11 @@ static int dwc3_runtime_resume(struct device *dev)switch (dwc->current_dr_role) {case DWC3_GCTL_PRTCAP_DEVICE : -dwc3_gadget_process_pending_events (dwc); +if (dwc->pending_events) { +pm_runtime_put (dwc->dev); + dwc->pending_events = false; +enable_irq (dwc->irq_gadget); + }break ;case DWC3_GCTL_PRTCAP_HOST :default :
@@ -1879,6 +1889,12 @@ static void dwc3_complete(struct device *dev)static const struct dev_pm_ops dwc3_dev_pm_ops = {SET_SYSTEM_SLEEP_PM_OPS (dwc3_suspend, dwc3_resume) .complete = dwc3_complete, + +/* +* Runtime suspend halts the controller on disconnection. It relies on +* platforms with custom connection notification to start the controller +* again. +*/ SET_RUNTIME_PM_OPS (dwc3_runtime_suspend, dwc3_runtime_resume, dwc3_runtime_idle) };
drivers/usb/dwc3/core.h +0 -4
@@ -1430,7 +1430,6 @@ static inline void dwc3_otg_host_init(struct dwc3 *dwc)#if !IS_ENABLED (CONFIG_USB_DWC3_HOST )int dwc3_gadget_suspend (struct dwc3 *dwc);int dwc3_gadget_resume (struct dwc3 *dwc); -void dwc3_gadget_process_pending_events (struct dwc3 *dwc);#else static inline int dwc3_gadget_suspend (struct dwc3 *dwc) {
@@ -1442,9 +1441,6 @@ static inline int dwc3_gadget_resume(struct dwc3 *dwc) return 0; } -static inline void dwc3_gadget_process_pending_events (struct dwc3 *dwc) -{ -}#endif /* !IS_ENABLED(CONFIG_USB_DWC3_HOST) */ #if IS_ENABLED (CONFIG_USB_DWC3_ULPI )
drivers/usb/dwc3/gadget.c +0 -11
@@ -3474,14 +3474,3 @@ int dwc3_gadget_resume(struct dwc3 *dwc) err0:return ret; } - -void dwc3_gadget_process_pending_events (struct dwc3 *dwc) -{ -if (dwc->pending_events) { -dwc3_interrupt (dwc->irq_gadget, dwc->ev_buf); -dwc3_thread_interrupt (dwc->irq_gadget, dwc->ev_buf); -pm_runtime_put (dwc->dev); - dwc->pending_events = false; -enable_irq (dwc->irq_gadget); - } -}
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 326/350 cgroup: Fix potential overflow issue when checking max_depth
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiu Jianfeng <[email protected]>
[ Upstream commit 3cc4e13bb1617f6a13e5e6882465984148743cf4 ]
cgroup.max.depth is the maximum allowed descent depth below the current cgroup. If the actual descent depth is equal or larger, an attempt to create a new child cgroup will fail. However due to the cgroup->max_depth is of int type and having the default value INT_MAX, the condition 'level > cgroup->max_depth' will never be satisfied, and it will cause an overflow of the level after it reaches to INT_MAX.
Fix it by starting the level from 0 and using '>=' instead.
It's worth mentioning that this issue is unlikely to occur in reality, as it's impossible to have a depth of INT_MAX hierarchy, but should be be avoided logically.
--- kernel/cgroup/cgroup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
kernel/cgroup/cgroup.c +2 -2
@@ -5104,7 +5104,7 @@ static bool cgroup_check_hierarchy_limits(struct cgroup *parent) {struct cgroup *cgroup;int ret = false; -int level =1 ; +int level =0 ;lockdep_assert_held (&cgroup_mutex);
@@ -5112,7 +5112,7 @@ static bool cgroup_check_hierarchy_limits(struct cgroup *parent)if (cgroup->nr_descendants >= cgroup->max_descendants) goto fail; -if (level > cgroup->max_depth) +if (level >= cgroup->max_depth) goto fail; level++;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 327/350 wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
[ Upstream commit 52009b419355195912a628d0a9847922e90c348c ]
Sync iterator conditions with ieee80211_iter_keys_rcu.
--- net/mac80211/key.c | 42 +++++++++++++++++++++++++----------------- 1 file changed, 25 insertions(+), 17 deletions(-)
net/mac80211/key.c +25 -17
@@ -777,6 +777,26 @@ void ieee80211_reset_crypto_tx_tailroom(struct ieee80211_sub_if_data *sdata)mutex_unlock (&sdata->local->key_mtx); } +static void +ieee80211_key_iter (struct ieee80211_hw *hw, +struct ieee80211_vif *vif, +struct ieee80211_key *key, +void (*iter)(struct ieee80211_hw *hw, +struct ieee80211_vif *vif, +struct ieee80211_sta *sta, +struct ieee80211_key_conf *key, +void *data), +void *iter_data) +{ +/* skip keys of station in removal process */ +if (key->sta && key->sta->removed) +return ; +if (!(key->flags &KEY_FLAG_UPLOADED_TO_HARDWARE )) +return ; +iter (hw, vif, key->sta ? &key->sta->sta :NULL , + &key->conf, iter_data); +} + void ieee80211_iter_keys(struct ieee80211_hw *hw, struct ieee80211_vif *vif, void (*iter)(struct ieee80211_hw *hw,
@@ -796,16 +816,13 @@ void ieee80211_iter_keys(struct ieee80211_hw *hw,if (vif) { sdata =vif_to_sdata (vif);list_for_each_entry_safe (key, tmp, &sdata->key_list, list) -iter (hw, &sdata->vif, - key->sta ? &key->sta->sta :NULL , - &key->conf, iter_data); +ieee80211_key_iter (hw, vif, key, iter, iter_data); }else {list_for_each_entry (sdata, &local->interfaces, list)list_for_each_entry_safe (key, tmp, &sdata->key_list, list) -iter (hw, &sdata->vif, - key->sta ? &key->sta->sta :NULL , - &key->conf, iter_data); +ieee80211_key_iter (hw, &sdata->vif, key, + iter, iter_data); }mutex_unlock (&local->key_mtx); }
@@ -823,17 +840,8 @@ _ieee80211_iter_keys_rcu(struct ieee80211_hw *hw, {struct ieee80211_key *key; -list_for_each_entry_rcu (key, &sdata->key_list, list) { -/* skip keys of station in removal process */ -if (key->sta && key->sta->removed) -continue ; -if (!(key->flags &KEY_FLAG_UPLOADED_TO_HARDWARE )) -continue ; - -iter (hw, &sdata->vif, - key->sta ? &key->sta->sta :NULL , - &key->conf, iter_data); - } +list_for_each_entry_rcu (key, &sdata->key_list, list) +ieee80211_key_iter (hw, &sdata->vif, key, iter, iter_data); } void ieee80211_iter_keys_rcu(struct ieee80211_hw *hw,
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 328/350 igb: Disable threaded IRQ for igb_msix_other
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wander Lairson Costa <[email protected]>
[ Upstream commit 338c4d3902feb5be49bfda530a72c7ab860e2c9f ]
During testing of SR-IOV, Red Hat QE encountered an issue where the ip link up command intermittently fails for the igbvf interfaces when using the PREEMPT_RT variant. Investigation revealed that e1000_write_posted_mbx returns an error due to the lack of an ACK from e1000_poll_for_ack.
The underlying issue arises from the fact that IRQs are threaded by default under PREEMPT_RT. While the exact hardware details are not available, it appears that the IRQ handled by igb_msix_other must be processed before e1000_poll_for_ack times out. However, e1000_write_posted_mbx is called with preemption disabled, leading to a scenario where the IRQ is serviced only after the failure of e1000_write_posted_mbx.
To resolve this, we set IRQF_NO_THREAD for the affected interrupt, ensuring that the kernel handles it immediately, thereby preventing the aforementioned error.
Reproducer:
#!/bin/bash
# echo 2 > /sys/class/net/ens14f0/device/sriov_numvfs
ipaddr_vlan=3
nic_test=ens14f0
vf=${nic_test}v0
while true; do
ip link set ${nic_test} mtu 1500
ip link set ${vf} mtu 1500
ip link set $vf up
ip link set ${nic_test} vf 0 vlan ${ipaddr_vlan}
ip addr add 172.30.${ipaddr_vlan}.1/24 dev ${vf}
ip addr add 2021:db8:${ipaddr_vlan}::1/64 dev ${vf}
if ! ip link show $vf | grep 'state UP'; then
echo 'Error found'
break
fi
ip link set $vf down
done--- drivers/net/ethernet/intel/igb/igb_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/intel/igb/igb_main.c +1 -1
@@ -943,7 +943,7 @@ static int igb_request_msix(struct igb_adapter *adapter)int i, err =0 , vector =0 , free_vector =0 ; err =request_irq (adapter->msix_entries[vector].vector, - igb_msix_other,0 , netdev->name, adapter); + igb_msix_other,IRQF_NO_THREAD , netdev->name, adapter);if (err) goto err_out;
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 329/350 gtp: simplify error handling code in gtp_encap_enable()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit b289ba5e07105548b8219695e5443d807a825eb8 ]
'gtp_encap_disable_sock(sk)' handles the case where sk is NULL, so there is no need to test it before calling the function.
This saves a few line of code.
Stable-dep-of: 7515e37bce5c ("gtp: allow -1 to be specified as file description from userspace")
--- drivers/net/gtp.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
drivers/net/gtp.c +3 -6
@@ -865,8 +865,7 @@ static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]) sk1u =gtp_encap_enable_socket (fd1,UDP_ENCAP_GTP1U , gtp);if (IS_ERR (sk1u)) { -if (sk0) -gtp_encap_disable_sock (sk0); +gtp_encap_disable_sock (sk0);return PTR_ERR (sk1u); } }
@@ -874,10 +873,8 @@ static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[])if (data[IFLA_GTP_ROLE ]) { role =nla_get_u32 (data[IFLA_GTP_ROLE ]);if (role >GTP_ROLE_SGSN ) { -if (sk0) -gtp_encap_disable_sock (sk0); -if (sk1u) -gtp_encap_disable_sock (sk1u); +gtp_encap_disable_sock (sk0); +gtp_encap_disable_sock (sk1u);return -EINVAL ; } }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 330/350 gtp: allow -1 to be specified as file description from userspace
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
[ Upstream commit 7515e37bce5c428a56a9b04ea7e96b3f53f17150 ]
Existing user space applications maintained by the Osmocom project are breaking since a recent fix that addresses incorrect error checking.
Restore operation for user space programs that specify -1 as file descriptor to skip GTPv0 or GTPv1 only sockets.
--- drivers/net/gtp.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-)
drivers/net/gtp.c +13 -9
@@ -853,20 +853,24 @@ static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[])unsigned int role =GTP_ROLE_GGSN ;if (data[IFLA_GTP_FD0 ]) { -u32 fd0 =nla_get_u32 (data[IFLA_GTP_FD0 ]); +int fd0 =nla_get_u32 (data[IFLA_GTP_FD0 ]); - sk0 =gtp_encap_enable_socket (fd0,UDP_ENCAP_GTP0 , gtp); -if (IS_ERR (sk0)) -return PTR_ERR (sk0); +if (fd0 >=0 ) { + sk0 =gtp_encap_enable_socket (fd0,UDP_ENCAP_GTP0 , gtp); +if (IS_ERR (sk0)) +return PTR_ERR (sk0); + } }if (data[IFLA_GTP_FD1 ]) { -u32 fd1 =nla_get_u32 (data[IFLA_GTP_FD1 ]); +int fd1 =nla_get_u32 (data[IFLA_GTP_FD1 ]); - sk1u =gtp_encap_enable_socket (fd1,UDP_ENCAP_GTP1U , gtp); -if (IS_ERR (sk1u)) { -gtp_encap_disable_sock (sk0); -return PTR_ERR (sk1u); +if (fd1 >=0 ) { + sk1u =gtp_encap_enable_socket (fd1,UDP_ENCAP_GTP1U , gtp); +if (IS_ERR (sk1u)) { +gtp_encap_disable_sock (sk0); +return PTR_ERR (sk1u); + } } }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 331/350 net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pedro Tammela <[email protected]>
[ Upstream commit 2e95c4384438adeaa772caa560244b1a2efef816 ]
In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff:
Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer.
In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT).
In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop.
net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/sched/sch_api.c +1 -1
@@ -783,7 +783,7 @@ void qdisc_tree_reduce_backlog(struct Qdisc *sch, unsigned int n, drops =max_t (int, n,0 );rcu_read_lock ();while ((parentid = sch->parent)) { -if (TC_H_MAJ (parentid) ==TC_H_MAJ (TC_H_INGRESS )) +if (parentid ==TC_H_ROOT )break ;if (sch->flags &TCQ_F_NOPARENT )
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 332/350 bpf: Fix out-of-bounds write in trie_get_next_key()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Byeonguk Jeong <[email protected]>
[ Upstream commit 13400ac8fb80c57c2bfb12ebd35ee121ce9b4d21 ]
trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.
--- kernel/bpf/lpm_trie.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/bpf/lpm_trie.c +1 -1
@@ -629,7 +629,7 @@ static int trie_get_next_key(struct bpf_map *map, void *_key, void *_next_key)if (!key || key->prefixlen > trie->max_prefixlen) goto find_leftmost; - node_stack =kmalloc_array (trie->max_prefixlen, + node_stack =kmalloc_array (trie->max_prefixlen +1 ,sizeof (struct lpm_trie_node *),GFP_ATOMIC | __GFP_NOWARN);if (!node_stack)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 333/350 net: support ip generic csum processing in skb_csum_hwoffload_help
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xin Long <[email protected]>
[ Upstream commit 62fafcd63139920eb25b3fbf154177ce3e6f3232 ]
NETIF_F_IP|IPV6_CSUM feature flag indicates UDP and TCP csum offload while NETIF_F_HW_CSUM feature flag indicates ip generic csum offload for HW, which includes not only for TCP/UDP csum, but also for other protocols' csum like GRE's.
However, in skb_csum_hwoffload_help() it only checks features against NETIF_F_CSUM_MASK(NETIF_F_HW|IP|IPV6_CSUM). So if it's a non TCP/UDP packet and the features doesn't support NETIF_F_HW_CSUM, but supports NETIF_F_IP|IPV6_CSUM only, it would still return 0 and leave the HW to do csum.
This patch is to support ip generic csum processing by checking NETIF_F_HW_CSUM for all protocols, and check (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM) only for TCP and UDP.
Note that we're using skb->csum_offset to check if it's a TCP/UDP proctol, this might be fragile. However, as Alex said, for now we only have a few L4 protocols that are requesting Tx csum offload, we'd better fix this until a new protocol comes with a same csum offset.
v1->v2:
- not extend skb->csum_not_inet, but use skb->csum_offset to tell if it's an UDP/TCP csum packet.v2->v3:
- add a note in the changelog, as Willem suggested.
Stable-dep-of: 04c20a9356f2 ("net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension")
--- net/core/dev.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
net/core/dev.c +12 -1
@@ -3323,7 +3323,18 @@ int skb_csum_hwoffload_help(struct sk_buff *skb,return !!(features &NETIF_F_SCTP_CRC ) ?0 :skb_crc32c_csum_help (skb); -return !!(features &NETIF_F_CSUM_MASK ) ?0 :skb_checksum_help (skb); +if (features &NETIF_F_HW_CSUM ) +return 0 ; + +if (features & (NETIF_F_IP_CSUM |NETIF_F_IPV6_CSUM )) { +switch (skb->csum_offset) { +case offsetof(struct tcphdr , check): +case offsetof(struct udphdr , check): +return 0 ; + } + } + +return skb_checksum_help (skb); }EXPORT_SYMBOL (skb_csum_hwoffload_help);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 334/350 net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Benoît Monin <[email protected]>
[ Upstream commit 04c20a9356f283da623903e81e7c6d5df7e4dc3c ]
As documented in skbuff.h, devices with NETIF_F_IPV6_CSUM capability can only checksum TCP and UDP over IPv6 if the IP header does not contains extension.
This is enforced for UDP packets emitted from user-space to an IPv6 address as they go through ip6_make_skb(), which calls __ip6_append_data() where a check is done on the header size before setting CHECKSUM_PARTIAL.
But the introduction of UDP encapsulation with fou6 added a code-path where it is possible to get an skb with a partial UDP checksum and an IPv6 header with extension:
* fou6 adds a UDP header with a partial checksum if the inner packet does not contains a valid checksum.
* ip6_tunnel adds an IPv6 header with a destination option extension header if encap_limit is non-zero (the default value is 4).
The thread linked below describes in more details how to reproduce the problem with GRE-in-UDP tunnel.
Add a check on the network header size in skb_csum_hwoffload_help() to make sure no IPv6 packet with extension header is handed to a network device with NETIF_F_IPV6_CSUM capability.
--- net/core/dev.c | 4 ++++ 1 file changed, 4 insertions(+)
net/core/dev.c +4 -0
@@ -3327,6 +3327,9 @@ int skb_csum_hwoffload_help(struct sk_buff *skb,return 0 ;if (features & (NETIF_F_IP_CSUM |NETIF_F_IPV6_CSUM )) { +if (vlan_get_protocol (skb) ==htons (ETH_P_IPV6 ) && +skb_network_header_len (skb) !=sizeof (struct ipv6hdr )) + goto sw_checksum;switch (skb->csum_offset) {case offsetof(struct tcphdr , check):case offsetof(struct udphdr , check):
@@ -3334,6 +3337,7 @@ int skb_csum_hwoffload_help(struct sk_buff *skb, } } +sw_checksum:return skb_checksum_help (skb); }EXPORT_SYMBOL (skb_csum_hwoffload_help);
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 335/350 netfilter: nft_payload: sanitize offset and length before calling skb_checksum()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pablo Neira Ayuso <[email protected]>
[ Upstream commit d5953d680f7e96208c29ce4139a0e38de87a57fe ]
If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON().
skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.
--- net/netfilter/nft_payload.c | 3 +++ 1 file changed, 3 insertions(+)
net/netfilter/nft_payload.c +3 -0
@@ -306,6 +306,9 @@ static void nft_payload_set_eval(const struct nft_expr *expr,if ((priv->csum_type ==NFT_PAYLOAD_CSUM_INET || priv->csum_flags) && (priv->base !=NFT_PAYLOAD_TRANSPORT_HEADER || skb->ip_summed !=CHECKSUM_PARTIAL )) { +if (offset + priv->len > skb->len) + goto err; + fsum =skb_checksum (skb, offset, priv->len,0 ); tsum =csum_partial (src, priv->len,0 );
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 336/350 firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiongfeng Wang <[email protected]>
[ Upstream commit c83212d79be2c9886d3e6039759ecd388fd5fed1 ]
In sdei_device_freeze(), the input parameter of cpuhp_remove_state() is passed as 'sdei_entry_point' by mistake. Change it to 'sdei_hp_state'.
--- drivers/firmware/arm_sdei.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/firmware/arm_sdei.c +1 -1
@@ -800,7 +800,7 @@ static int sdei_device_freeze(struct device *dev)int err;/* unregister private events */ -cpuhp_remove_state (sdei_entry_point); +cpuhp_remove_state (sdei_hp_state); err =sdei_unregister_shared ();if (err)
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 337/350 net: amd: mvme147: Fix probe banner message
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Palmer <[email protected]>
[ Upstream commit 82c5b53140faf89c31ea2b3a0985a2f291694169 ]
Currently this driver prints this line with what looks like a rogue format specifier when the device is probed:
[ 2.840000] eth%d: MVME147 at 0xfffe1800, irq 12, Hardware Address xx:xx:xx:xx:xx:xx
Change the printk() for netdev_info() and move it after the registration has completed so it prints out the name of the interface properly.
--- drivers/net/ethernet/amd/mvme147.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-)
drivers/net/ethernet/amd/mvme147.c +3 -4
@@ -105,10 +105,6 @@ struct net_device * __init mvme147lance_probe(int unit) address = address >>8 ; dev->dev_addr[3 ] = address&0xff ; -printk ("%s: MVME147 at 0x%08lx, irq %d, Hardware Address %pM\n" , - dev->name, dev->base_addr,MVME147_LANCE_IRQ , - dev->dev_addr); - lp =netdev_priv (dev); lp->ram =__get_dma_pages (GFP_ATOMIC ,3 );/* 32K */ if (!lp->ram) {
@@ -138,6 +134,9 @@ struct net_device * __init mvme147lance_probe(int unit)return ERR_PTR (err); } +netdev_info (dev,"MVME147 at 0x%08lx, irq %d, Hardware Address %pM\n" , + dev->base_addr,MVME147_LANCE_IRQ , dev->dev_addr); +return dev; }
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 338/350 misc: sgi-gru: Dont disable preemption in GRU driver
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dimitri Sivanich <[email protected]>
[ Upstream commit b983b271662bd6104d429b0fd97af3333ba760bf ]
Disabling preemption in the GRU driver is unnecessary, and clashes with sleeping locks in several code paths. Remove preempt_disable and preempt_enable from the GRU driver.
--- drivers/misc/sgi-gru/grukservices.c | 2 -- drivers/misc/sgi-gru/grumain.c | 4 ---- drivers/misc/sgi-gru/grutlbpurge.c | 2 -- 3 files changed, 8 deletions(-)
drivers/misc/sgi-gru/grukservices.c +0 -2
@@ -270,7 +270,6 @@ static int gru_get_cpu_resources(int dsr_bytes, void **cb, void **dsr)int lcpu;BUG_ON (dsr_bytes >GRU_NUM_KERNEL_DSR_BYTES ); -preempt_disable (); bs =gru_lock_kernel_context (-1 ); lcpu =uv_blade_processor_id (); *cb = bs->kernel_cb + lcpu *GRU_HANDLE_STRIDE ;
@@ -284,7 +283,6 @@ static int gru_get_cpu_resources(int dsr_bytes, void **cb, void **dsr)static void gru_free_cpu_resources (void *cb,void *dsr) {gru_unlock_kernel_context (uv_numa_blade_id ()); -preempt_enable (); }/*
drivers/misc/sgi-gru/grumain.c +0 -4
@@ -954,10 +954,8 @@ vm_fault_t gru_fault(struct vm_fault *vmf) again:mutex_lock (>s->ts_ctxlock); -preempt_disable ();if (gru_check_context_placement (gts)) { -preempt_enable ();mutex_unlock (>s->ts_ctxlock);gru_unload_context (gts,1 );return VM_FAULT_NOPAGE ;
@@ -966,7 +964,6 @@ vm_fault_t gru_fault(struct vm_fault *vmf)if (!gts->ts_gru) {STAT (load_user_context);if (!gru_assign_gru_context (gts)) { -preempt_enable ();mutex_unlock (>s->ts_ctxlock);set_current_state (TASK_INTERRUPTIBLE );schedule_timeout (GRU_ASSIGN_DELAY );/* true hack ZZZ */
@@ -982,7 +979,6 @@ vm_fault_t gru_fault(struct vm_fault *vmf) vma->vm_page_prot); } -preempt_enable ();mutex_unlock (>s->ts_ctxlock);return VM_FAULT_NOPAGE ;
drivers/misc/sgi-gru/grutlbpurge.c +0 -2
@@ -78,7 +78,6 @@ static struct gru_tlb_global_handle *get_lock_tgh_handle(struct gru_statestruct gru_tlb_global_handle *tgh;int n; -preempt_disable ();if (uv_numa_blade_id () == gru->gs_blade_id) n =get_on_blade_tgh (gru);else
@@ -92,7 +91,6 @@ static struct gru_tlb_global_handle *get_lock_tgh_handle(struct gru_statestatic void get_unlock_tgh_handle (struct gru_tlb_global_handle *tgh) {unlock_tgh_handle (tgh); -preempt_enable (); }/*
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 339/350 usbip: tools: Fix detach_port() invalid port error path
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zongmin Zhou <[email protected]>
commit e7cd4b811c9e019f5acbce85699c622b30194c24 upstream.
The detach_port() doesn't return error
when detach is attempted on an invalid port.
--- tools/usb/usbip/src/usbip_detach.c | 1 + 1 file changed, 1 insertion(+)
tools/usb/usbip/src/usbip_detach.c +1 -0
@@ -80,6 +80,7 @@ static int detach_port(char *port) }if (!found) { + ret =-1 ;err ("Invalid port %s > maxports %d" , port, vhci_driver->nports); goto call_driver_close;
Greg Kroah-Hartman
maintainerPATCH 340/350 usb: phy: Fix API devm_usb_put_phy() can not release the phy
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zijun Hu <[email protected]>
commit fdce49b5da6e0fb6d077986dec3e90ef2b094b50 upstream.
For devm_usb_put_phy(), its comment says it needs to invoke usb_put_phy() to release the phy, but it does not do that actually, so it can not fully undo what the API devm_usb_get_phy() does, that is wrong, fixed by using devres_release() instead of devres_destroy() within the API.
--- drivers/usb/phy/phy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/phy/phy.c +1 -1
@@ -579,7 +579,7 @@ void devm_usb_put_phy(struct device *dev {int r; - r =devres_destroy (dev, devm_usb_phy_release, devm_usb_phy_match, phy); + r =devres_release (dev, devm_usb_phy_release, devm_usb_phy_match, phy);dev_WARN_ONCE (dev, r,"couldn't find PHY resource\n" ); }EXPORT_SYMBOL_GPL (devm_usb_put_phy);
Greg Kroah-Hartman
maintainerPATCH 341/350 xhci: Fix Link TRB DMA in command ring stopped completion event
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Faisal Hassan <[email protected]>
commit 075919f6df5dd82ad0b1894898b315fbb3c29b84 upstream.
During the aborting of a command, the software receives a command completion event for the command ring stopped, with the TRB pointing to the next TRB after the aborted command.
If the command we abort is located just before the Link TRB in the command ring, then during the 'command ring stopped' completion event, the xHC gives the Link TRB in the event's cmd DMA, which causes a mismatch in handling command completion event.
To address this situation, move the 'command ring stopped' completion event check slightly earlier, since the specific command it stopped on isn't of significant concern.
--- drivers/usb/host/xhci-ring.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
drivers/usb/host/xhci-ring.c +8 -8
@@ -1431,6 +1431,14 @@ static void handle_cmd_completion(structtrace_xhci_handle_command (xhci->cmd_ring, &cmd_trb->generic); + cmd_comp_code =GET_COMP_CODE (le32_to_cpu (event->status)); + +/* If CMD ring stopped we own the trbs between enqueue and dequeue */ +if (cmd_comp_code ==COMP_COMMAND_RING_STOPPED ) { +complete_all (&xhci->cmd_ring_stop_completion); +return ; + } + cmd_dequeue_dma =xhci_trb_virt_to_dma (xhci->cmd_ring->deq_seg, cmd_trb);/*
@@ -1447,14 +1455,6 @@ static void handle_cmd_completion(structcancel_delayed_work (&xhci->cmd_timer); - cmd_comp_code =GET_COMP_CODE (le32_to_cpu (event->status)); - -/* If CMD ring stopped we own the trbs between enqueue and dequeue */ -if (cmd_comp_code ==COMP_COMMAND_RING_STOPPED ) { -complete_all (&xhci->cmd_ring_stop_completion); -return ; - } -if (cmd->command_trb != xhci->cmd_ring->dequeue) {xhci_err (xhci,"Command completion event does not match command\n" );
Greg Kroah-Hartman
maintainerPATCH 342/350 Revert "driver core: Fix uevent_show() vs driver detach race"
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit 9a71892cbcdb9d1459c84f5a4c722b14354158a5 upstream.
This reverts commit 15fffc6a5624b13b428bb1c6e9088e32a55eb82c.
This commit causes a regression, so revert it for now until it can come back in a way that works for everyone.
--- drivers/base/core.c | 13 +++++-------- drivers/base/module.c | 4 ---- 2 files changed, 5 insertions(+), 12 deletions(-)
drivers/base/core.c +5 -8
@@ -24,7 +24,6 @@#include <linux/mutex.h> #include <linux/pm_runtime.h> #include <linux/netdevice.h> -#include <linux/rcupdate.h> #include <linux/sched/signal.h> #include <linux/sysfs.h>
@@ -1138,7 +1137,6 @@ static int dev_uevent(struct kset *kset, struct kobj_uevent_env *env) {struct device *dev =kobj_to_dev (kobj); -struct device_driver *driver;int retval =0 ;/* add device node properties if present */
@@ -1167,12 +1165,8 @@ static int dev_uevent(struct kset *kset,if (dev->type && dev->type->name)add_uevent_var (env,"DEVTYPE=%s" , dev->type->name); -/* Synchronize with module_remove_driver() */ -rcu_read_lock (); - driver =READ_ONCE (dev->driver); -if (driver) -add_uevent_var (env,"DRIVER=%s" , driver->name); -rcu_read_unlock (); +if (dev->driver) +add_uevent_var (env,"DRIVER=%s" , dev->driver->name);/* Add common DT information about the device */ of_device_uevent (dev, env);
@@ -1242,8 +1236,11 @@ static ssize_t uevent_show(struct deviceif (!env)return -ENOMEM ; +/* Synchronize with really_probe() */ +device_lock (dev);/* let the kset specific function add its keys */ retval = kset->uevent_ops->uevent (kset, &dev->kobj, env); +device_unlock (dev);if (retval) goto out;
drivers/base/module.c +0 -4
@@ -7,7 +7,6 @@#include <linux/errno.h> #include <linux/slab.h> #include <linux/string.h> -#include <linux/rcupdate.h> #include "base.h" static char *make_driver_name (struct device_driver *drv)
@@ -78,9 +77,6 @@ void module_remove_driver(struct device_if (!drv)return ; -/* Synchronize with dev_uevent() */ -synchronize_rcu (); -sysfs_remove_link (&drv->p->kobj,"module" );if (drv->owner)
Greg Kroah-Hartman
maintainerPATCH 343/350 wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Fietkau <[email protected]>
commit 393b6bc174b0dd21bb2a36c13b36e62fc3474a23 upstream.
Avoid potentially crashing in the driver because of uninitialized private data
--- net/mac80211/cfg.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/mac80211/cfg.c +2 -1
@@ -2443,7 +2443,8 @@ static int ieee80211_get_tx_power(structstruct ieee80211_local *local =wiphy_priv (wiphy);struct ieee80211_sub_if_data *sdata =IEEE80211_WDEV_TO_SUB_IF (wdev); -if (local->ops->get_txpower) +if (local->ops->get_txpower && + (sdata->flags &IEEE80211_SDATA_IN_DRIVER ))return drv_get_txpower (local, sdata, dbm);if (!local->use_chanctx)
Greg Kroah-Hartman
maintainerPATCH 344/350 wifi: ath10k: Fix memory leak in management tx
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Manikanta Pubbisetty <[email protected]>
commit e15d84b3bba187aa372dff7c58ce1fd5cb48a076 upstream.
In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic.
Kmemleak reports this problem as below,
unreferenced object 0xffffff80b64ed250 (size 16):
comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes):
00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t......
backtrace:
[<ffffffe6e7b245dc>] __kmem_cache_alloc_node+0x1e4/0x2d8
[<ffffffe6e7adde88>] kmalloc_trace+0x48/0x110
[<ffffffe6bbd765fc>] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core]
[<ffffffe6bbd3eed4>] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core]
[<ffffffe6e78d5974>] process_scheduled_works+0x1ac/0x400
[<ffffffe6e78d60b8>] worker_thread+0x208/0x328
[<ffffffe6e78dc890>] kthread+0x100/0x1c0
[<ffffffe6e78166c0>] ret_from_fork+0x10/0x20Free the memory during completion and cleanup to fix the leak.
Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances.
Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1
--- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 7 ++++++- drivers/net/wireless/ath/ath10k/wmi.c | 2 ++ 2 files changed, 8 insertions(+), 1 deletion(-)
drivers/net/wireless/ath/ath10k/wmi-tlv.c +6 -1
@@ -2655,9 +2655,14 @@ ath10k_wmi_tlv_op_cleanup_mgmt_tx_send(s struct sk_buff *msdu) {struct ath10k_skb_cb *cb =ATH10K_SKB_CB (msdu); +struct ath10k_mgmt_tx_pkt_addr *pkt_addr;struct ath10k_wmi *wmi = &ar->wmi; -idr_remove (&wmi->mgmt_pending_tx, cb->msdu_id); +spin_lock_bh (&ar->data_lock); + pkt_addr =idr_remove (&wmi->mgmt_pending_tx, cb->msdu_id); +spin_unlock_bh (&ar->data_lock); + +kfree (pkt_addr);return 0 ; }
drivers/net/wireless/ath/ath10k/wmi.c +2 -0
@@ -2362,6 +2362,7 @@ static int wmi_process_mgmt_tx_comp(strudma_unmap_single (ar->dev, pkt_addr->paddr, msdu->len,DMA_TO_DEVICE ); info =IEEE80211_SKB_CB (msdu); +kfree (pkt_addr);if (status) info->flags &= ~IEEE80211_TX_STAT_ACK ;
@@ -9233,6 +9234,7 @@ static int ath10k_wmi_mgmt_tx_clean_up_pdma_unmap_single (ar->dev, pkt_addr->paddr, msdu->len,DMA_TO_DEVICE );ieee80211_free_txskb (ar->hw, msdu); +kfree (pkt_addr);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 345/350 wifi: iwlegacy: Clear stale interrupts before resuming device
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ville Syrjälä <[email protected]>
commit 07c90acb071b9954e1fecb1e4f4f13d12c544b34 upstream.
iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up.
Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume.
Here's a debug log of the indicent:
[ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 00 c6 83 ad 05 00 00 00 48 89 df e8 98 1b fc ff 85 c0 41 89 c7 0f 84 e9 02 00 00 48 c7 c7 a0 e6 48 a0 e8 d1 77 c4 e0 <0f> 0b eb 2d 84 c0 0f 85 8b 01 00 00 c6 87 ad 05 00 00 00 e8 69 1b [ 16.132504] RSP: 0018:ffffc9000029fcf0 EFLAGS: 00010282 [ 16.132507] RAX: 0000000000000000 RBX: ffff8880072008e0 RCX: 0000000000000001 [ 16.132509] RDX: ffffffff81f21a18 RSI: 0000000000000086 RDI: 0000000000000001 [ 16.132510] RBP: ffff8880072003c0 R08: 0000000000000000 R09: 0000000000000003 [ 16.132512] R10: 0000000000000000 R11: ffff88807e5b0000 R12: 0000000000000001 [ 16.132514] R13: 0000000000000000 R14: 0000000000000000 R15: 00000000ffffff92 [ 16.132515] FS: 0000000000000000(0000) GS:ffff88807c200000(0000) knlGS:0000000000000000 [ 16.132517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.132519] CR2: 000055dd43786c08 CR3: 000000000978f000 CR4: 00000000000006f0 [ 16.132521] Call Trace: [ 16.132525] <TASK> [ 16.132526] ? __warn+0x77/0x120 [ 16.132532] ? ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132564] ? report_bug+0x15c/0x190 [ 16.132568] ? handle_bug+0x36/0x70 [ 16.132571] ? exc_invalid_op+0x13/0x60 [ 16.132573] ? asm_exc_invalid_op+0x16/0x20 [ 16.132579] ? ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132611] ? snd_hdac_bus_init_cmd_io+0x24/0x200 [snd_hda_core] [ 16.132617] ? pick_eevdf+0x133/0x1c0 [ 16.132622] ? check_preempt_wakeup_fair+0x70/0x90 [ 16.132626] ? wakeup_preempt+0x4a/0x60 [ 16.132628] ? ttwu_do_activate.isra.0+0x5a/0x190 [ 16.132632] wiphy_resume+0x79/0x1a0 [cfg80211] [ 16.132675] ? wiphy_suspend+0x2a0/0x2a0 [cfg80211] [ 16.132697] dpm_run_callback+0x75/0x1b0 [ 16.132703] device_resume+0x97/0x200 [ 16.132707] async_resume+0x14/0x20 [ 16.132711] async_run_entry_fn+0x1b/0xa0 [ 16.132714] process_one_work+0x13d/0x350 [ 16.132718] worker_thread+0x2be/0x3d0 [ 16.132722] ? cancel_delayed_work_sync+0x70/0x70 [ 16.132725] kthread+0xc0/0xf0 [ 16.132729] ? kthread_park+0x80/0x80 [ 16.132732] ret_from_fork+0x28/0x40 [ 16.132735] ? kthread_park+0x80/0x80 [ 16.132738] ret_from_fork_asm+0x11/0x20 [ 16.132741] </TASK> [ 16.132742] ---[ end trace 0000000000000000 ]--- [ 16.132930] ------------[ cut here ]------------ [ 16.132932] WARNING: CPU: 0 PID: 181 at net/mac80211/driver-ops.c:41 drv_stop+0xe7/0xf0 [mac80211] [ 16.132957] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.133014] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Tainted: G W 6.11.0-cl+ #143 [ 16.133018] Tainted: [W]=WARN [ 16.133019] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.133021] Workqueue: async async_run_entry_fn [ 16.133025] RIP: 0010:drv_stop+0xe7/0xf0 [mac80211] [ 16.133048] Code: 48 85 c0 74 0e 48 8b 78 08 89 ea 48 89 de e8 e0 87 04 00 65 ff 0d d1 de c4 5f 0f 85 42 ff ff ff e8 be 52 c2 e0 e9 38 ff ff ff <0f> 0b 5b 5d c3 0f 1f 40 00 41 54 49 89 fc 55 53 48 89 f3 2e 2e 2e [ 16.133050] RSP: 0018:ffffc9000029fc50 EFLAGS: 00010246 [ 16.133053] RAX: 0000000000000000 RBX: ffff8880072008e0 RCX: ffff88800377f6c0 [ 16.133054] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8880072008e0 [ 16.133056] RBP: 0000000000000000 R08: ffffffff81f238d8 R09: 0000000000000000 [ 16.133058] R10: ffff8880080520f0 R11: 0000000000000000 R12: ffff888008051c60 [ 16.133060] R13: ffff8880072008e0 R14: 0000000000000000 R15: ffff8880072011d8 [ 16.133061] FS: 0000000000000000(0000) GS:ffff88807c200000(0000) knlGS:0000000000000000 [ 16.133063] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.133065] CR2: 000055dd43786c08 CR3: 000000000978f000 CR4: 00000000000006f0 [ 16.133067] Call Trace: [ 16.133069] <TASK> [ 16.133070] ? __warn+0x77/0x120 [ 16.133075] ? drv_stop+0xe7/0xf0 [mac80211] [ 16.133098] ? report_bug+0x15c/0x190 [ 16.133100] ? handle_bug+0x36/0x70 [ 16.133103] ? exc_invalid_op+0x13/0x60 [ 16.133105] ? asm_exc_invalid_op+0x16/0x20 [ 16.133109] ? drv_stop+0xe7/0xf0 [mac80211] [ 16.133132] ieee80211_do_stop+0x55a/0x810 [mac80211] [ 16.133161] ? fq_codel_reset+0xa5/0xc0 [sch_fq_codel] [ 16.133164] ieee80211_stop+0x4f/0x180 [mac80211] [ 16.133192] __dev_close_many+0xa2/0x120 [ 16.133195] dev_close_many+0x90/0x150 [ 16.133198] dev_close+0x5d/0x80 [ 16.133200] cfg80211_shutdown_all_interfaces+0x40/0xe0 [cfg80211] [ 16.133223] wiphy_resume+0xb2/0x1a0 [cfg80211] [ 16.133247] ? wiphy_suspend+0x2a0/0x2a0 [cfg80211] [ 16.133269] dpm_run_callback+0x75/0x1b0 [ 16.133273] device_resume+0x97/0x200 [ 16.133277] async_resume+0x14/0x20 [ 16.133280] async_run_entry_fn+0x1b/0xa0 [ 16.133283] process_one_work+0x13d/0x350 [ 16.133287] worker_thread+0x2be/0x3d0 [ 16.133290] ? cancel_delayed_work_sync+0x70/0x70 [ 16.133294] kthread+0xc0/0xf0 [ 16.133296] ? kthread_park+0x80/0x80 [ 16.133299] ret_from_fork+0x28/0x40 [ 16.133302] ? kthread_park+0x80/0x80 [ 16.133304] ret_from_fork_asm+0x11/0x20 [ 16.133307] </TASK> [ 16.133308] ---[ end trace 0000000000000000 ]--- [ 16.133335] ieee80211 phy0: PM: dpm_run_callback(): wiphy_resume [cfg80211] returns -110 [ 16.133360] ieee80211 phy0: PM: failed to restore async: error -110
--- drivers/net/wireless/intel/iwlegacy/common.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/wireless/intel/iwlegacy/common.c +2 -0
@@ -4986,6 +4986,8 @@ il_pci_resume(struct device *device)*/ pci_write_config_byte (pdev,PCI_CFG_RETRY_TIMEOUT ,0x00 ); +_il_wr (il,CSR_INT ,0xffffffff ); +_il_wr (il,CSR_FH_INT_STATUS ,0xffffffff );il_enable_interrupts (il);if (!(_il_rd (il,CSR_GP_CNTRL ) &CSR_GP_CNTRL_REG_FLAG_HW_RF_KILL_SW ))
Greg Kroah-Hartman
maintainerPATCH 346/350 nilfs2: fix potential deadlock with newly created symlinks
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryusuke Konishi <[email protected]>
commit b3a033e3ecd3471248d474ef263aadc0059e516a upstream.
Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock.
This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem().
This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held:
Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.
--- fs/nilfs2/namei.c | 3 +++ 1 file changed, 3 insertions(+)
fs/nilfs2/namei.c +3 -0
@@ -156,6 +156,9 @@ static int nilfs_symlink(struct inode *d/* slow symlink */ inode->i_op = &nilfs_symlink_inode_operations;inode_nohighmem (inode); +mapping_set_gfp_mask (inode->i_mapping, +mapping_gfp_constraint (inode->i_mapping, + ~__GFP_FS)); inode->i_mapping->a_ops = &nilfs_aops; err =page_symlink (inode, symname, l);if (err)
Greg Kroah-Hartman
maintainerPATCH 347/350 ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Edward Adam Davis <[email protected]>
[ Upstream commit bc0a2f3a73fcdac651fca64df39306d1e5ebe3b0 ]
Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are "unsigned int".
So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.
--- fs/ocfs2/file.c | 8 ++++++++ 1 file changed, 8 insertions(+)
fs/ocfs2/file.c +8 -0
@@ -1795,6 +1795,14 @@ int ocfs2_remove_inode_range(struct inode *inode,return 0 ;if (OCFS2_I (inode)->ip_dyn_features &OCFS2_INLINE_DATA_FL ) { +int id_count =ocfs2_max_inline_data_with_xattr (inode->i_sb, di); + +if (byte_start > id_count || byte_start + byte_len > id_count) { + ret = -EINVAL ; +mlog_errno (ret); + goto out; + } + ret =ocfs2_truncate_inline (inode, di_bh, byte_start, byte_start + byte_len,0 );if (ret) {
Signature · 1 line
2.43.0
Greg Kroah-Hartman
maintainerPATCH 348/350 nilfs2: fix kernel bug due to missing clearing of checked flag
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryusuke Konishi <[email protected]>
commit 41e192ad2779cae0102879612dfe46726e4396aa upstream.
Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug.
This was found to be because the "checked" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that.
This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.
--- fs/nilfs2/page.c | 1 + 1 file changed, 1 insertion(+)
fs/nilfs2/page.c +1 -0
@@ -407,6 +407,7 @@ void nilfs_clear_dirty_page(struct pageClearPageUptodate (page);ClearPageMappedToDisk (page); +ClearPageChecked (page);if (page_has_buffers (page)) {struct buffer_head *bh, *head;
Greg Kroah-Hartman
maintainerPATCH 349/350 mm: shmem: fix data-race in shmem_getattr()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeongjun Park <[email protected]>
commit d949d1d14fa281ace388b1de978e8f2cd52875cf upstream.
I got the following KCSAN report during syzbot testing:
==================================================================
BUG: KCSAN: data-race in generic_fillattr / inode_set_ctime_current
write to 0xffff888102eb3260 of 4 bytes by task 6565 on cpu 1:
inode_set_ctime_to_ts include/linux/fs.h:1638 [inline] inode_set_ctime_current+0x169/0x1d0 fs/inode.c:2626 shmem_mknod+0x117/0x180 mm/shmem.c:3443 shmem_create+0x34/0x40 mm/shmem.c:3497 lookup_open fs/namei.c:3578 [inline] open_last_lookups fs/namei.c:3647 [inline] path_openat+0xdbc/0x1f00 fs/namei.c:3883 do_filp_open+0xf7/0x200 fs/namei.c:3913 do_sys_openat2+0xab/0x120 fs/open.c:1416 do_sys_open fs/open.c:1431 [inline] __do_sys_openat fs/open.c:1447 [inline] __se_sys_openat fs/open.c:1442 [inline] __x64_sys_openat+0xf3/0x120 fs/open.c:1442 x64_sys_call+0x1025/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:258 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e
read to 0xffff888102eb3260 of 4 bytes by task 3498 on cpu 0:
inode_get_ctime_nsec include/linux/fs.h:1623 [inline] inode_get_ctime include/linux/fs.h:1629 [inline] generic_fillattr+0x1dd/0x2f0 fs/stat.c:62 shmem_getattr+0x17b/0x200 mm/shmem.c:1157 vfs_getattr_nosec fs/stat.c:166 [inline] vfs_getattr+0x19b/0x1e0 fs/stat.c:207 vfs_statx_path fs/stat.c:251 [inline] vfs_statx+0x134/0x2f0 fs/stat.c:315 vfs_fstatat+0xec/0x110 fs/stat.c:341 __do_sys_newfstatat fs/stat.c:505 [inline] __se_sys_newfstatat+0x58/0x260 fs/stat.c:499 __x64_sys_newfstatat+0x55/0x70 fs/stat.c:499 x64_sys_call+0x141f/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:263 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e
value changed: 0x2755ae53 -> 0x27ee44d3
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 3498 Comm: udevd Not tainted 6.11.0-rc6-syzkaller-00326-gd1f2d51b711a-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 ==================================================================
When calling generic_fillattr(), if you don't hold read lock, data-race will occur in inode member variables, which can cause unexpected behavior.
Since there is no special protection when shmem_getattr() calls generic_fillattr(), data-race occurs by functions such as shmem_unlink() or shmem_mknod(). This can cause unexpected results, so commenting it out is not enough.
Therefore, when calling generic_fillattr() from shmem_getattr(), it is appropriate to protect the inode using inode_lock_shared() and inode_unlock_shared() to prevent data-race.
--- mm/shmem.c | 2 ++ 1 file changed, 2 insertions(+)
mm/shmem.c +2 -0
@@ -1014,7 +1014,9 @@ static int shmem_getattr(const struct pashmem_recalc_inode (inode);spin_unlock_irq (&info->lock); } +inode_lock_shared (inode);generic_fillattr (inode, stat); +inode_unlock_shared (inode);if (is_huge_enabled (sb_info)) stat->blksize =HPAGE_PMD_SIZE ;
Greg Kroah-Hartman
maintainerPATCH 350/350 vt: prevent kernel-infoleak in con_font_get()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeongjun Park <[email protected]>
commit f956052e00de211b5c9ebaa1958366c23f82ee9e upstream.
font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.
--- drivers/tty/vt/vt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/tty/vt/vt.c +1 -1
@@ -4450,7 +4450,7 @@ static int con_font_get(struct vc_data *int c;if (op->data) { - font.data =kmalloc (max_font_size,GFP_KERNEL ); + font.data =kzalloc (max_font_size,GFP_KERNEL );if (!font.data)return -ENOMEM ; }else
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.323 release. There are 350 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 Fri, 08 Nov 2024 12:02:47 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.323-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
The arm builds failed with gcc-8, gcc-12 on the Linux stable-rc linux-4.19.y and linux-5.4.y.
First seen on Linux v4.19.322-351-ge024cd330026
Good: v4.19.321-96-g00a71bfa9b89
Bad: v4.19.322-351-ge024cd330026
arm:
build:
* gcc-8-lkftconfig
* gcc-12-lkftconfig
Build log:
---------drivers/pinctrl/mvebu/pinctrl-dove.c: In function 'dove_pinctrl_probe':drivers/pinctrl/mvebu/pinctrl-dove.c:791:9: error: implicit declaration of function 'devm_platform_get_and_ioremap_resource'; did you mean 'devm_platform_ioremap_resource'? [-Werror=implicit-function-declaration]
base = devm_platform_get_and_ioremap_resource(pdev, 0, &mpp_res);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
devm_platform_ioremap_resource
drivers/pinctrl/mvebu/pinctrl-dove.c:791:7: warning: assignment to
'void *' from 'int' makes pointer from integer without a cast
[-Wint-conversion]
base = devm_platform_get_and_ioremap_resource(pdev, 0, &mpp_res);
^cc1: some warnings being treated as errors
Build image:
-----------
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2oTbkOSx8FRoSUpBZX23UatyPIP/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2oTbkOSx8FRoSUpBZX23UatyPIP/build.log
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2oTbkOSx8FRoSUpBZX23UatyPIP/config
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.322-351-ge024cd330026/testrun/25686486/suite/build/test/gcc-12-lkftconfig/details/
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.284-463-g21641076146f/testrun/25690547/suite/build/test/gcc-12-lkftconfig/log
Steps to reproduce:
------------
- tuxmake --runtime podman --target-arch arm --toolchain gcc-12
--kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2oTbkOSx8FRoSUpBZX23UatyPIP/config
metadata:
----
git describe: v4.19.322-351-ge024cd330026
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git sha: e024cd330026af478986a90829dd6ff03e3c1f92
kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2oTbkOSx8FRoSUpBZX23UatyPIP/config
build url: https://storage.tuxsuite.com/public/linaro/lkft/builds/2oTbkOSx8FRoSUpBZX23UatyPIP/
toolchain: gcc-12 and gcc-8
config: lkftconfig
arch: arm
--
Linaro LKFT
https://lkft.linaro.org
Hi!
Quoted 19 lines
Quoted 17 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.323 release. There are 350 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 Fri, 08 Nov 2024 12:02:47 +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.19.323-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
Quoted 8 lines
Quoted 1 line
greg k-h
The arm builds failed with gcc-8, gcc-12 on the Linux stable-rc linux-4.19.y and linux-5.4.y.
First seen on Linux v4.19.322-351-ge024cd330026
Good: v4.19.321-96-g00a71bfa9b89
Bad: v4.19.322-351-ge024cd330026
We see same failure.
drivers/pinctrl/mvebu/pinctrl-dove.c: In function 'dove_pinctrl_probe':
3778drivers/pinctrl/mvebu/pinctrl-dove.c:791:9: error: implicit declaration of function 'devm_platform_get_and_ioremap_resource'; did you mean 'devm_platform_ioremap_resource'? [-Werror=implicit-function-declaration] 3779
base = devm_platform_get_and_ioremap_resource(pdev, 0, &mpp_res);
3780
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3781
devm_platform_ioremap_resource
3782drivers/pinctrl/mvebu/pinctrl-dove.c:791:7: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion] 3783
base = devm_platform_get_and_ioremap_resource(pdev, 0, &mpp_res);
3784
^
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/1529999662
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Greg Kroah-Hartman
maintainerQuoted 66 lines · Naresh Kamboju
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.323 release. There are 350 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 Fri, 08 Nov 2024 12:02:47 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.323-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
The arm builds failed with gcc-8, gcc-12 on the Linux stable-rc linux-4.19.y and linux-5.4.y.
First seen on Linux v4.19.322-351-ge024cd330026
Good: v4.19.321-96-g00a71bfa9b89
Bad: v4.19.322-351-ge024cd330026arm:
build:
* gcc-8-lkftconfig
* gcc-12-lkftconfigBuild log:
---------drivers/pinctrl/mvebu/pinctrl-dove.c: In function 'dove_pinctrl_probe':drivers/pinctrl/mvebu/pinctrl-dove.c:791:9: error: implicit declaration of function 'devm_platform_get_and_ioremap_resource'; did you mean 'devm_platform_ioremap_resource'? [-Werror=implicit-function-declaration]base = devm_platform_get_and_ioremap_resource(pdev, 0, &mpp_res); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ devm_platform_ioremap_resource drivers/pinctrl/mvebu/pinctrl-dove.c:791:7: warning: assignment to 'void *' from 'int' makes pointer from integer without a cast [-Wint-conversion] base = devm_platform_get_and_ioremap_resource(pdev, 0, &mpp_res); ^cc1: some warnings being treated as errors
Build image:
-----------
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2oTbkOSx8FRoSUpBZX23UatyPIP/
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2oTbkOSx8FRoSUpBZX23UatyPIP/build.log
- https://storage.tuxsuite.com/public/linaro/lkft/builds/2oTbkOSx8FRoSUpBZX23UatyPIP/config
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.322-351-ge024cd330026/testrun/25686486/suite/build/test/gcc-12-lkftconfig/details/
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.284-463-g21641076146f/testrun/25690547/suite/build/test/gcc-12-lkftconfig/logSteps to reproduce:
------------
- tuxmake --runtime podman --target-arch arm --toolchain gcc-12
--kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/2oTbkOSx8FRoSUpBZX23UatyPIP/config
Quoted 11 lines
metadata:
----
git describe: v4.19.322-351-ge024cd330026
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git sha:e024cd330026af478986a90829dd6ff03e3c1f92
kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2oTbkOSx8FRoSUpBZX23UatyPIP/config
build url: https://storage.tuxsuite.com/public/linaro/lkft/builds/2oTbkOSx8FRoSUpBZX23UatyPIP/
toolchain: gcc-12 and gcc-8
config: lkftconfig
arch: arm
Thanks, I'll go fix this up in 4.19 and 5.4 and push out new -rc2 releases now.
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.323 release. There are 350 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 Fri, 08 Nov 2024 12:02:47 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.323-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah