6.0.4-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 6.0.4-rc1 review
This is the start of the stable review cycle for the 6.0.4 release. There are 20 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, 26 Oct 2022 11:29:24 +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.0.4-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.0.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 6.0.4-rc1
Thomas Zimmermann <[email protected]>
fbdev/core: Remove remove_conflicting_pci_framebuffers()
Mel Gorman <[email protected]>
mm/huge_memory: do not clobber swp_entry_t during THP split
Rafael Mendonca <[email protected]>
io-wq: Fix memory leak in worker creation
Martin Liska <[email protected]>
gcov: support GCC 12.1 and newer compilers
Ard Biesheuvel <[email protected]>
efi: ssdt: Don't free memory if ACPI table was loaded successfully
Ard Biesheuvel <[email protected]>
efi: efivars: Fix variable writes without query_variable_store()
Nikos Tsironis <[email protected]>
dm clone: Fix typo in block_device format specifier
Tim Huang <[email protected]>
drm/amd/pm: update SMU IP v13.0.4 driver interface version
Evan Quan <[email protected]>
drm/amd/pm: fulfill SMU13.0.0 cstate control interface
Evan Quan <[email protected]>
drm/amd/pm: disable cstate feature for gpu reset scenario
Tim Huang <[email protected]>
drm/amd/pm: add SMU IP v13.0.4 IF version define to V7
Evan Quan <[email protected]>
drm/amd/pm: fulfill SMU13.0.7 cstate control interface
Pavel Begunkov <[email protected]>
net: flag sockets supporting msghdr originated zerocopy
Roderick Colenbrander <[email protected]>
HID: playstation: add initial DualSense Edge controller support
Roderick Colenbrander <[email protected]>
HID: playstation: stop DualSense output work on remove.
Pavel Begunkov <[email protected]>
io_uring/net: fail zc send when unsupported by socket
Rafael J. Wysocki <[email protected]>
thermal: intel_powerclamp: Use first online CPU as control_cpu
Basavaraj Natikar <[email protected]>
pinctrl: amd: change dev_warn to dev_dbg for additional feature support
Ville Syrjälä <[email protected]>
drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers
Ville Syrjälä <[email protected]>
drm/i915/bios: Validate fp_timing terminator presence
-------------
Diffstat:
Makefile | 4 +- drivers/firmware/efi/efi.c | 2 + drivers/firmware/efi/vars.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++ .../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_4.h | 17 +++- drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 2 +- drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 8 ++ drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 9 ++ .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 11 +++ .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 12 +++ drivers/gpu/drm/i915/display/intel_bios.c | 106 ++++++++++----------- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-playstation.c | 46 +++++++-- drivers/md/dm-clone-target.c | 2 +- drivers/pinctrl/pinctrl-amd.c | 4 +- drivers/thermal/intel/intel_powerclamp.c | 6 +- drivers/video/aperture.c | 30 +++--- drivers/video/fbdev/core/fbmem.c | 48 ---------- fs/efivarfs/vars.c | 16 ---- include/linux/efi.h | 3 - include/linux/fb.h | 2 - include/linux/net.h | 1 + io_uring/io-wq.c | 2 +- io_uring/net.c | 2 + kernel/gcov/gcc_4_7.c | 18 +++- mm/huge_memory.c | 11 ++- net/ipv4/tcp.c | 1 + net/ipv4/udp.c | 1 + 28 files changed, 218 insertions(+), 165 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/20 drm/i915/bios: Validate fp_timing terminator presence
From: Ville Syrjälä <[email protected]>
commit 4e78d6023c15c6acce8fbe42e13027c460395522 upstream.
Validate the LFP data block a bit hardwer by making sure the fp_timing terminators (0xffff) are where we expect them to be.
--- drivers/gpu/drm/i915/display/intel_bios.c | 60 ++++++++++++++++-------------- 1 file changed, 32 insertions(+), 28 deletions(-)
drivers/gpu/drm/i915/display/intel_bios.c +32 -28
@@ -135,18 +135,6 @@ static u32 raw_block_offset(const void *return block - bdb; } -/* size of the block excluding the header */ -static u32 raw_block_size (const void *bdb,enum bdb_block_id section_id) -{ -const void *block; - - block =find_raw_section (bdb, section_id); -if (!block) -return 0 ; - -return get_blocksize (block); -} -struct bdb_block_entry {struct list_head node;enum bdb_block_id section_id;
@@ -231,9 +219,14 @@ static bool validate_lfp_data_ptrs(const {int fp_timing_size, dvo_timing_size, panel_pnp_id_size, panel_name_size;int data_block_size, lfp_data_size; +const void *data_block;int i; - data_block_size =raw_block_size (bdb,BDB_LVDS_LFP_DATA ); + data_block =find_raw_section (bdb,BDB_LVDS_LFP_DATA ); +if (!data_block) +return false; + + data_block_size =get_blocksize (data_block);if (data_block_size ==0 )return false;
@@ -261,21 +254,6 @@ static bool validate_lfp_data_ptrs(constif (16 * lfp_data_size > data_block_size)return false; -/* -* Except for vlv/chv machines all real VBTs seem to have 6 -* unaccounted bytes in the fp_timing table. And it doesn't -* appear to be a really intentional hole as the fp_timing -* 0xffff terminator is always within those 6 missing bytes. -*/ -if (fp_timing_size + dvo_timing_size + panel_pnp_id_size != lfp_data_size && - fp_timing_size +6 + dvo_timing_size + panel_pnp_id_size != lfp_data_size) -return false; - -if (ptrs->ptr[0 ].fp_timing.offset + fp_timing_size > ptrs->ptr[0 ].dvo_timing.offset || - ptrs->ptr[0 ].dvo_timing.offset + dvo_timing_size != ptrs->ptr[0 ].panel_pnp_id.offset || - ptrs->ptr[0 ].panel_pnp_id.offset + panel_pnp_id_size != lfp_data_size) -return false; -/* make sure the table entries have uniform size */ for (i =1 ; i <16 ; i++) { if (ptrs->ptr[i].fp_timing.table_size != fp_timing_size ||
@@ -289,6 +267,23 @@ static bool validate_lfp_data_ptrs(constreturn false; } +/* +* Except for vlv/chv machines all real VBTs seem to have 6 +* unaccounted bytes in the fp_timing table. And it doesn't +* appear to be a really intentional hole as the fp_timing +* 0xffff terminator is always within those 6 missing bytes. +*/ +if (fp_timing_size +6 + dvo_timing_size + panel_pnp_id_size == lfp_data_size) + fp_timing_size +=6 ; + +if (fp_timing_size + dvo_timing_size + panel_pnp_id_size != lfp_data_size) +return false; + +if (ptrs->ptr[0 ].fp_timing.offset + fp_timing_size != ptrs->ptr[0 ].dvo_timing.offset || + ptrs->ptr[0 ].dvo_timing.offset + dvo_timing_size != ptrs->ptr[0 ].panel_pnp_id.offset || + ptrs->ptr[0 ].panel_pnp_id.offset + panel_pnp_id_size != lfp_data_size) +return false; +/* make sure the tables fit inside the data block */ for (i =0 ; i <16 ; i++) { if (ptrs->ptr[i].fp_timing.offset + fp_timing_size > data_block_size ||
@@ -300,6 +295,15 @@ static bool validate_lfp_data_ptrs(constif (ptrs->panel_name.offset +16 * panel_name_size > data_block_size)return false; +/* make sure fp_timing terminators are present at expected locations */ +for (i =0 ; i <16 ; i++) { +const u16 *t = data_block + ptrs->ptr[i].fp_timing.offset + + fp_timing_size -2 ; + +if (*t !=0xffff ) +return false; + } +return true; }
Greg Kroah-Hartman
maintainerPATCH 2/20 drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers
In reply to Greg Kroah-HartmanFrom: Ville Syrjälä <[email protected]>
commit d3a7051841f0a4bcb1ee26a1b721c6150cc4c2b1 upstream.
The current scheme for generating the LFP data table pointers (when the block including them is missing from the VBT) expects the 0xffff sequence to only appear in the fp_timing terminator entries. However some VBTs also have extra 0xffff sequences elsewhere in the LFP data. When looking for the terminators we may end up finding those extra sequeneces insted, which means we deduce the wrong size for the fp_timing table. The code then notices the inconsistent looking values and gives up on the generated data table pointers, preventing us from parsing the LFP data table entirely.
Let's give up on the "search for the terminators" approach and instead just hardcode the expected size for the fp_timing table.
We have enough sanity checks in place to make sure we shouldn't end up parsing total garbage even if that size should change in the future (although that seems unlikely as the fp_timing and dvo_timing tables have been declared obsolete as of VBT version 229).
--- drivers/gpu/drm/i915/display/intel_bios.c | 46 +++++++++++------------------- 1 file changed, 18 insertions(+), 28 deletions(-)
drivers/gpu/drm/i915/display/intel_bios.c +18 -28
@@ -337,18 +337,6 @@ static bool fixup_lfp_data_ptrs(const voreturn validate_lfp_data_ptrs (bdb, ptrs); } -static const void *find_fp_timing_terminator (const u8 *data,int size) -{ -int i; - -for (i =0 ; i < size -1 ; i++) { -if (data[i] ==0xff && data[i+1 ] ==0xff ) -return &data[i]; - } - -return NULL ; -} -static int make_lfp_data_ptr (struct lvds_lfp_data_ptr_table *table,int table_size,int total_size) {
@@ -372,11 +360,22 @@ static void next_lfp_data_ptr(struct lvdstatic void *generate_lfp_data_ptrs (struct drm_i915_private *i915,const void *bdb) { -int i, size, table_size, block_size, offset; -const void *t0, *t1, *block; +int i, size, table_size, block_size, offset, fp_timing_size;struct bdb_lvds_lfp_data_ptrs *ptrs; +const void *block;void *ptrs_block; +/* +* The hardcoded fp_timing_size is only valid for +* modernish VBTs. All older VBTs definitely should +* include block 41 and thus we don't need to +* generate one. +*/ +if (i915->vbt.version <155 ) +return NULL ; + + fp_timing_size =38 ; + block =find_raw_section (bdb,BDB_LVDS_LFP_DATA );if (!block)return NULL ;
@@ -385,17 +384,8 @@ static void *generate_lfp_data_ptrs(stru block_size =get_blocksize (block); - size = block_size; - t0 =find_fp_timing_terminator (block, size); -if (!t0) -return NULL ; - - size -= t0 - block -2 ; - t1 =find_fp_timing_terminator (t0 +2 , size); -if (!t1) -return NULL ; - - size = t1 - t0; + size = fp_timing_size +sizeof (struct lvds_dvo_timing ) + +sizeof (struct lvds_pnp_id );if (size *16 > block_size)return NULL ;
@@ -413,7 +403,7 @@ static void *generate_lfp_data_ptrs(stru table_size =sizeof (struct lvds_dvo_timing ); size =make_lfp_data_ptr (&ptrs->ptr[0 ].dvo_timing, table_size, size); - table_size = t0 - block +2 ; + table_size = fp_timing_size; size =make_lfp_data_ptr (&ptrs->ptr[0 ].fp_timing, table_size, size);if (ptrs->ptr[0 ].fp_timing.table_size)
@@ -428,14 +418,14 @@ static void *generate_lfp_data_ptrs(strureturn NULL ; } - size = t1 - t0; + size = fp_timing_size +sizeof (struct lvds_dvo_timing ) + +sizeof (struct lvds_pnp_id );for (i =1 ; i <16 ; i++) {next_lfp_data_ptr (&ptrs->ptr[i].fp_timing, &ptrs->ptr[i-1 ].fp_timing, size);next_lfp_data_ptr (&ptrs->ptr[i].dvo_timing, &ptrs->ptr[i-1 ].dvo_timing, size);next_lfp_data_ptr (&ptrs->ptr[i].panel_pnp_id, &ptrs->ptr[i-1 ].panel_pnp_id, size); } - size = t1 - t0; table_size =sizeof (struct lvds_lfp_panel_name );if (16 * (size + table_size) <= block_size) {
Greg Kroah-Hartman
maintainerPATCH 3/20 pinctrl: amd: change dev_warn to dev_dbg for additional feature support
In reply to Greg Kroah-HartmanFrom: Basavaraj Natikar <[email protected]>
commit 3160b37e5cb695e866e06c3fdbc385846b569294 upstream.
Use dev_dbg instead of dev_warn for additional support of pinmux feature.
--- drivers/pinctrl/pinctrl-amd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/pinctrl/pinctrl-amd.c +2 -2
@@ -1051,13 +1051,13 @@ static void amd_get_iomux_res(struct amd index =device_property_match_string (dev,"pinctrl-resource-names" ,"iomux" );if (index <0 ) { -dev_warn (dev,"failed to get iomux index\n" ); +dev_dbg (dev,"iomux not supported\n" ); goto out_no_pinmux; } gpio_dev->iomux_base =devm_platform_ioremap_resource (gpio_dev->pdev, index);if (IS_ERR (gpio_dev->iomux_base)) { -dev_warn (dev,"Failed to get iomux %d io resource\n" , index); +dev_dbg (dev,"iomux not supported %d io resource\n" , index); goto out_no_pinmux; }
Greg Kroah-Hartman
maintainerPATCH 4/20 thermal: intel_powerclamp: Use first online CPU as control_cpu
In reply to Greg Kroah-HartmanFrom: Rafael J. Wysocki <[email protected]>
commit 4bb7f6c2781e46fc5bd00475a66df2ea30ef330d upstream.
Commit 68b99e94a4a2 ("thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash") fixed an issue related to using smp_processor_id() in preemptible context by replacing it with a pair of get_cpu()/put_cpu(), but what is needed there really is any online CPU and not necessarily the one currently running the code. Arguably, getting the one that's running the code in there is confusing.
For this reason, simply give the control CPU role to the first online one which automatically will be CPU0 if it is online, so one check can be dropped from the code for an added benefit.
--- drivers/thermal/intel/intel_powerclamp.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)
drivers/thermal/intel/intel_powerclamp.c +1 -5
@@ -531,11 +531,7 @@ static int start_power_clamp(void)cpus_read_lock ();/* prefer BSP */ - control_cpu =0 ; -if (!cpu_online (control_cpu)) { - control_cpu =get_cpu (); -put_cpu (); - } + control_cpu =cpumask_first (cpu_online_mask); clamping = true;schedule_delayed_work (&poll_pkg_cstate_work,0 );
Greg Kroah-Hartman
maintainerPATCH 5/20 io_uring/net: fail zc send when unsupported by socket
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
commit edf81438799ccead7122948446d7e44b083e788d upstream.
If a protocol doesn't support zerocopy it will silently fall back to copying. This type of behaviour has always been a source of troubles so it's better to fail such requests instead.
--- io_uring/net.c | 2 ++ 1 file changed, 2 insertions(+)
io_uring/net.c +2 -0
@@ -1001,6 +1001,8 @@ int io_send_zc(struct io_kiocb *req, uns sock =sock_from_file (req->file);if (unlikely (!sock))return -ENOTSOCK ; +if (!test_bit (SOCK_SUPPORT_ZC , &sock->flags)) +return -EOPNOTSUPP ; msg.msg_name =NULL ; msg.msg_control =NULL ;
Greg Kroah-Hartman
maintainerPATCH 6/20 HID: playstation: stop DualSense output work on remove.
In reply to Greg Kroah-HartmanFrom: Roderick Colenbrander <[email protected]>
commit 182934a1e93b17f4edf71f4fcc8d19b19a6fe67a upstream.
Ensure we don't schedule any new output work on removal and wait for any existing work to complete. If we don't do this e.g. rumble work can get queued during deletion and we trigger a kernel crash.
--- drivers/hid/hid-playstation.c | 41 ++++++++++++++++++++++++++++++++++++----- 1 file changed, 36 insertions(+), 5 deletions(-)
drivers/hid/hid-playstation.c +36 -5
@@ -46,6 +46,7 @@ struct ps_device {uint32_t fw_version;int (*parse_report)(struct ps_device *dev,struct hid_report *report,u8 *data,int size); +void (*remove)(struct ps_device *dev); };/* Calibration data for playstation motion sensors. */
@@ -174,6 +175,7 @@ struct dualsense {struct led_classdev player_leds[5 ];struct work_struct output_worker; +bool output_worker_initialized;void *output_report_dmabuf;uint8_t output_seq;/* Sequence number for output report. */ };
@@ -299,6 +301,7 @@ static const struct {int x; int y; } ps_ {0, 0}, }; +static inline void dualsense_schedule_work (struct dualsense *ds);static void dualsense_set_lightbar (struct dualsense *ds,uint8_t red,uint8_t green,uint8_t blue);/*
@@ -792,6 +795,7 @@ err_free:return ret; } +static int dualsense_get_firmware_info (struct dualsense *ds) {uint8_t *buf;
@@ -881,7 +885,7 @@ static int dualsense_player_led_set_brig ds->update_player_leds = true;spin_unlock_irqrestore (&ds->base.lock, flags); -schedule_work (&ds->output_worker); +dualsense_schedule_work (ds);return 0 ; }
@@ -925,6 +929,16 @@ static void dualsense_init_output_report } } +static inline void dualsense_schedule_work (struct dualsense *ds) +{ +unsigned long flags; + +spin_lock_irqsave (&ds->base.lock, flags); +if (ds->output_worker_initialized) +schedule_work (&ds->output_worker); +spin_unlock_irqrestore (&ds->base.lock, flags); +} +/* * Helper function to send DualSense output reports. Applies a CRC at the end of a report * for Bluetooth reports.
@@ -1085,7 +1099,7 @@ static int dualsense_parse_report(structspin_unlock_irqrestore (&ps_dev->lock, flags);/* Schedule updating of microphone state at hardware level. */ -schedule_work (&ds->output_worker); +dualsense_schedule_work (ds); } ds->last_btn_mic_state = btn_mic_state;
@@ -1200,10 +1214,22 @@ static int dualsense_play_effect(struct ds->motor_right = effect->u.rumble.weak_magnitude /256 ;spin_unlock_irqrestore (&ds->base.lock, flags); -schedule_work (&ds->output_worker); +dualsense_schedule_work (ds);return 0 ; } +static void dualsense_remove (struct ps_device *ps_dev) +{ + struct dualsense *ds = container_of(ps_dev, struct dualsense, base); +unsigned long flags; + +spin_lock_irqsave (&ds->base.lock, flags); + ds->output_worker_initialized = false; +spin_unlock_irqrestore (&ds->base.lock, flags); + +cancel_work_sync (&ds->output_worker); +} +static int dualsense_reset_leds (struct dualsense *ds) {struct dualsense_output_report report;
@@ -1240,7 +1266,7 @@ static void dualsense_set_lightbar(struc ds->lightbar_blue = blue;spin_unlock_irqrestore (&ds->base.lock, flags); -schedule_work (&ds->output_worker); +dualsense_schedule_work (ds); }static void dualsense_set_player_leds (struct dualsense *ds)
@@ -1263,7 +1289,7 @@ static void dualsense_set_player_leds(st ds->update_player_leds = true; ds->player_leds_state = player_ids[player_id]; -schedule_work (&ds->output_worker); +dualsense_schedule_work (ds); }static struct ps_device *dualsense_create (struct hid_device *hdev)
@@ -1302,7 +1328,9 @@ static struct ps_device *dualsense_creat ps_dev->battery_capacity =100 ;/* initial value until parse_report. */ ps_dev->battery_status =POWER_SUPPLY_STATUS_UNKNOWN ; ps_dev->parse_report = dualsense_parse_report; + ps_dev->remove = dualsense_remove;INIT_WORK (&ds->output_worker, dualsense_output_worker); + ds->output_worker_initialized = true;hid_set_drvdata (hdev, ds); max_output_report_size =sizeof (struct dualsense_output_report_bt );
@@ -1470,6 +1498,9 @@ static void ps_remove(struct hid_deviceps_devices_list_remove (dev);ps_device_release_player_id (dev); +if (dev->remove) + dev->remove (dev); +hid_hw_close (hdev);hid_hw_stop (hdev); }
Greg Kroah-Hartman
maintainerPATCH 7/20 HID: playstation: add initial DualSense Edge controller support
In reply to Greg Kroah-HartmanFrom: Roderick Colenbrander <[email protected]>
commit b8a968efab301743fd659b5649c5d7d3e30e63a6 upstream.
Provide initial support for the DualSense Edge controller. The brings support up to the level of the original DualSense, but won't yet provide support for new features (e.g. reprogrammable buttons).
--- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-playstation.c | 5 ++++- 2 files changed, 5 insertions(+), 1 deletion(-)
drivers/hid/hid-ids.h +1 -0
@@ -1142,6 +1142,7 @@#define USB_DEVICE_ID_SONY_PS4_CONTROLLER_2 0x09cc#define USB_DEVICE_ID_SONY_PS4_CONTROLLER_DONGLE 0x0ba0#define USB_DEVICE_ID_SONY_PS5_CONTROLLER 0x0ce6 +#define USB_DEVICE_ID_SONY_PS5_CONTROLLER_2 0x0df2#define USB_DEVICE_ID_SONY_MOTION_CONTROLLER 0x03d5#define USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER 0x042f#define USB_DEVICE_ID_SONY_BUZZ_CONTROLLER 0x0002
drivers/hid/hid-playstation.c +4 -1
@@ -1467,7 +1467,8 @@ static int ps_probe(struct hid_device *h goto err_stop; } -if (hdev->product ==USB_DEVICE_ID_SONY_PS5_CONTROLLER ) { +if (hdev->product ==USB_DEVICE_ID_SONY_PS5_CONTROLLER || + hdev->product ==USB_DEVICE_ID_SONY_PS5_CONTROLLER_2 ) { dev =dualsense_create (hdev);if (IS_ERR (dev)) {hid_err (hdev,"Failed to create dualsense.\n" );
@@ -1508,6 +1509,8 @@ static void ps_remove(struct hid_devicestatic const struct hid_device_id ps_devices[] = { {HID_BLUETOOTH_DEVICE (USB_VENDOR_ID_SONY ,USB_DEVICE_ID_SONY_PS5_CONTROLLER ) }, {HID_USB_DEVICE (USB_VENDOR_ID_SONY ,USB_DEVICE_ID_SONY_PS5_CONTROLLER ) }, + {HID_BLUETOOTH_DEVICE (USB_VENDOR_ID_SONY ,USB_DEVICE_ID_SONY_PS5_CONTROLLER_2 ) }, + {HID_USB_DEVICE (USB_VENDOR_ID_SONY ,USB_DEVICE_ID_SONY_PS5_CONTROLLER_2 ) }, { } };MODULE_DEVICE_TABLE (hid, ps_devices);
Greg Kroah-Hartman
maintainerPATCH 8/20 net: flag sockets supporting msghdr originated zerocopy
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
commit e993ffe3da4bcddea0536b03be1031bf35cd8d85 upstream.
We need an efficient way in io_uring to check whether a socket supports zerocopy with msghdr provided ubuf_info. Add a new flag into the struct socket flags fields.
--- include/linux/net.h | 1 + net/ipv4/tcp.c | 1 + net/ipv4/udp.c | 1 + 3 files changed, 3 insertions(+)
include/linux/net.h +1 -0
@@ -41,6 +41,7 @@ struct net;#define SOCK_NOSPACE 2#define SOCK_PASSCRED 3#define SOCK_PASSSEC 4 +#define SOCK_SUPPORT_ZC 5#ifndef ARCH_HAS_SOCKET_TYPES /**
net/ipv4/tcp.c +1 -0
@@ -457,6 +457,7 @@ void tcp_init_sock(struct sock *sk)WRITE_ONCE (sk->sk_sndbuf,READ_ONCE (sock_net (sk)->ipv4.sysctl_tcp_wmem[1 ]));WRITE_ONCE (sk->sk_rcvbuf,READ_ONCE (sock_net (sk)->ipv4.sysctl_tcp_rmem[1 ])); +set_bit (SOCK_SUPPORT_ZC , &sk->sk_socket->flags);sk_sockets_allocated_inc (sk); }EXPORT_SYMBOL (tcp_init_sock);
net/ipv4/udp.c +1 -0
@@ -1620,6 +1620,7 @@ int udp_init_sock(struct sock *sk) {skb_queue_head_init (&udp_sk (sk)->reader_queue); sk->sk_destruct = udp_destruct_sock; +set_bit (SOCK_SUPPORT_ZC , &sk->sk_socket->flags);return 0 ; }EXPORT_SYMBOL_GPL (udp_init_sock);
Greg Kroah-Hartman
maintainerPATCH 9/20 drm/amd/pm: fulfill SMU13.0.7 cstate control interface
In reply to Greg Kroah-HartmanFrom: Evan Quan <[email protected]>
commit ba2f09960e75accf757ed12b4ef61409dcc97df8 upstream.
Fulfill the functionality for cstate control.
--- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 12 ++++++++++++ 1 file changed, 12 insertions(+)
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c +12 -0
@@ -121,6 +121,7 @@ static struct cmn2asic_msg_mapping smu_vMSG_MAP (Mode1Reset, PPSMC_MSG_Mode1Reset,0 ),MSG_MAP (PrepareMp1ForUnload, PPSMC_MSG_PrepareMp1ForUnload,0 ),MSG_MAP (SetMGpuFanBoostLimitRpm, PPSMC_MSG_SetMGpuFanBoostLimitRpm,0 ), + MSG_MAP(DFCstateControl, PPSMC_MSG_SetExternalClientDfCstateAllow, 0), }; static struct cmn2asic_mapping smu_v13_0_7_clk_map[SMU_CLK_COUNT] = {
@@ -1587,6 +1588,16 @@ static bool smu_v13_0_7_is_mode1_reset_sreturn true; } + +static int smu_v13_0_7_set_df_cstate (struct smu_context *smu, +enum pp_df_cstate state) +{ +return smu_cmn_send_smc_msg_with_param (smu, + SMU_MSG_DFCstateControl, + state, +NULL ); +} +static const struct pptable_funcs smu_v13_0_7_ppt_funcs = { .get_allowed_feature_mask = smu_v13_0_7_get_allowed_feature_mask, .set_default_dpm_table = smu_v13_0_7_set_default_dpm_table,
@@ -1649,6 +1660,7 @@ static const struct pptable_funcs smu_v1 .mode1_reset_is_support = smu_v13_0_7_is_mode1_reset_supported, .mode1_reset = smu_v13_0_mode1_reset, .set_mp1_state = smu_v13_0_7_set_mp1_state, + .set_df_cstate = smu_v13_0_7_set_df_cstate, };void smu_v13_0_7_set_ppt_funcs (struct smu_context *smu)
Greg Kroah-Hartman
maintainerPATCH 10/20 drm/amd/pm: add SMU IP v13.0.4 IF version define to V7
In reply to Greg Kroah-HartmanFrom: Tim Huang <[email protected]>
commit 31c261a7ffb8d5bba8144e2d43db304f2bc7e81a upstream.
The pmfw has changed the driver interface version, so keep same with the fw.
--- drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h +1 -1
@@ -28,7 +28,7 @@#define SMU13_DRIVER_IF_VERSION_INV 0xFFFFFFFF#define SMU13_DRIVER_IF_VERSION_YELLOW_CARP 0x04#define SMU13_DRIVER_IF_VERSION_ALDE 0x08 -#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_4 0x05 +#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_4 0x07#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_5 0x04#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_0 0x30#define SMU13_DRIVER_IF_VERSION_SMU_V13_0_7 0x2C
Greg Kroah-Hartman
maintainerPATCH 11/20 drm/amd/pm: disable cstate feature for gpu reset scenario
In reply to Greg Kroah-HartmanFrom: Evan Quan <[email protected]>
commit 3059cd8c5f797ad83d2b194ae66339f5c007ca43 upstream.
Suggested by PMFW team and same as what did for gfxoff feature. This can address some Mode1Reset failures observed on SMU13.0.0.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++++++++ drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 8 ++++++++ drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 9 +++++++++ 3 files changed, 25 insertions(+)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +8 -0
@@ -2926,6 +2926,14 @@ static int amdgpu_device_ip_suspend_phasamdgpu_device_set_pg_state (adev,AMD_PG_STATE_UNGATE );amdgpu_device_set_cg_state (adev,AMD_CG_STATE_UNGATE ); +/* +* Per PMFW team's suggestion, driver needs to handle gfxoff +* and df cstate features disablement for gpu reset(e.g. Mode1Reset) +* scenario. Add the missing df cstate disablement here. +*/ +if (amdgpu_dpm_set_df_cstate (adev,DF_CSTATE_DISALLOW )) +dev_warn (adev->dev,"Failed to disallow df cstate" ); +for (i = adev->num_ip_blocks -1 ; i >=0 ; i--) {if (!adev->ip_blocks[i].status.valid)continue ;
drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c +8 -0
@@ -2242,9 +2242,17 @@ static void arcturus_get_unique_id(strucstatic int arcturus_set_df_cstate (struct smu_context *smu,enum pp_df_cstate state) { +struct amdgpu_device *adev = smu->adev;uint32_t smu_version;int ret; +/* +* Arcturus does not need the cstate disablement +* prerequisite for gpu reset. +*/ +if (amdgpu_in_reset (adev) || adev->in_suspend) +return 0 ; + ret =smu_cmn_get_smc_version (smu,NULL , &smu_version);if (ret) {dev_err (smu->adev->dev,"Failed to get smu version!\n" );
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c +9 -0
@@ -1640,6 +1640,15 @@ static bool aldebaran_is_baco_supported(static int aldebaran_set_df_cstate (struct smu_context *smu,enum pp_df_cstate state) { +struct amdgpu_device *adev = smu->adev; + +/* +* Aldebaran does not need the cstate disablement +* prerequisite for gpu reset. +*/ +if (amdgpu_in_reset (adev) || adev->in_suspend) +return 0 ; +return smu_cmn_send_smc_msg_with_param (smu, SMU_MSG_DFCstateControl, state,NULL ); }
Greg Kroah-Hartman
maintainerPATCH 12/20 drm/amd/pm: fulfill SMU13.0.0 cstate control interface
In reply to Greg Kroah-HartmanFrom: Evan Quan <[email protected]>
commit 528c0e66e0c01a8c078d2d94431db80f9c75d2a0 upstream.
Fulfill the functionality for cstate control.
--- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c +11 -0
@@ -119,6 +119,7 @@ static struct cmn2asic_msg_mapping smu_vMSG_MAP (NotifyPowerSource, PPSMC_MSG_NotifyPowerSource,0 ),MSG_MAP (Mode1Reset, PPSMC_MSG_Mode1Reset,0 ),MSG_MAP (PrepareMp1ForUnload, PPSMC_MSG_PrepareMp1ForUnload,0 ), + MSG_MAP(DFCstateControl, PPSMC_MSG_SetExternalClientDfCstateAllow, 0), }; static struct cmn2asic_mapping smu_v13_0_0_clk_map[SMU_CLK_COUNT] = {
@@ -1753,6 +1754,15 @@ static int smu_v13_0_0_set_mp1_state(strreturn ret; } +static int smu_v13_0_0_set_df_cstate (struct smu_context *smu, +enum pp_df_cstate state) +{ +return smu_cmn_send_smc_msg_with_param (smu, + SMU_MSG_DFCstateControl, + state, +NULL ); +} +static const struct pptable_funcs smu_v13_0_0_ppt_funcs = { .get_allowed_feature_mask = smu_v13_0_0_get_allowed_feature_mask, .set_default_dpm_table = smu_v13_0_0_set_default_dpm_table,
@@ -1822,6 +1832,7 @@ static const struct pptable_funcs smu_v1 .mode1_reset_is_support = smu_v13_0_0_is_mode1_reset_supported, .mode1_reset = smu_v13_0_mode1_reset, .set_mp1_state = smu_v13_0_0_set_mp1_state, + .set_df_cstate = smu_v13_0_0_set_df_cstate, };void smu_v13_0_0_set_ppt_funcs (struct smu_context *smu)
Greg Kroah-Hartman
maintainerPATCH 13/20 drm/amd/pm: update SMU IP v13.0.4 driver interface version
In reply to Greg Kroah-HartmanFrom: Tim Huang <[email protected]>
commit 853fdb49160e9c30674fd8e4a2eabc06bf70b13a upstream.
Update the SMU driver interface version to V7.
--- drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_4.h | 17 ++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_4.h +15 -2
@@ -27,7 +27,7 @@// *** IMPORTANT *** // SMU TEAM: Always increment the interface version if // any structure is changed in this file -#define PMFW_DRIVER_IF_VERSION 5 +#define PMFW_DRIVER_IF_VERSION 7 typedef struct { int32_t value;
@@ -163,8 +163,8 @@ typedef struct {uint16_t DclkFrequency;//[MHz] uint16_t MemclkFrequency;//[MHz] uint16_t spare;//[centi] -uint16_t UvdActivity;//[centi] uint16_t GfxActivity;//[centi] +uint16_t UvdActivity;//[centi] uint16_t Voltage[2 ];//[mV] indices: VDDCR_VDD, VDDCR_SOC uint16_t Current[2 ];//[mA] indices: VDDCR_VDD, VDDCR_SOC
@@ -199,6 +199,19 @@ typedef struct {uint16_t DeviceState;uint16_t CurTemp;//[centi-Celsius] uint16_t spare2; + +uint16_t AverageGfxclkFrequency; +uint16_t AverageFclkFrequency; +uint16_t AverageGfxActivity; +uint16_t AverageSocclkFrequency; +uint16_t AverageVclkFrequency; +uint16_t AverageVcnActivity; +uint16_t AverageDRAMReads;//Filtered DF Bandwidth::DRAM Reads +uint16_t AverageDRAMWrites;//Filtered DF Bandwidth::DRAM Writes +uint16_t AverageSocketPower;//Filtered value of CurrentSocketPower +uint16_t AverageCorePower;//Filtered of [sum of CorePower[8]]) +uint16_t AverageCoreC0Residency[8 ];//Filtered of [average C0 residency % per core] +uint32_t MetricsCounter;//Counts the # of metrics table parameter reads per update to the metrics table, i.e. if the metrics table update happens every 1 second, this value could be up to 1000 if the smu collected metrics data every cycle, or as low as 0 if the smu was asleep the whole time. Reset to 0 after writing. } SmuMetrics_t; typedef struct {
Greg Kroah-Hartman
maintainerPATCH 14/20 dm clone: Fix typo in block_device format specifier
In reply to Greg Kroah-HartmanFrom: Nikos Tsironis <[email protected]>
commit 5434ee8d28575b2e784bd5b4dbfc912e5da90759 upstream.
Use %pg for printing the block device name, instead of %pd.
--- drivers/md/dm-clone-target.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/dm-clone-target.c +1 -1
@@ -2035,7 +2035,7 @@ static void disable_passdown_if_not_supported(struct clone *clone) reason ="max discard sectors smaller than a region" ;if (reason) { -DMWARN ("Destination device (%pd) %s: Disabling discard passdown." , +DMWARN ("Destination device (%pg) %s: Disabling discard passdown." , dest_dev, reason);clear_bit (DM_CLONE_DISCARD_PASSDOWN , &clone->flags); }
Signature · 1 line
2.38.1
Greg Kroah-Hartman
maintainerPATCH 15/20 efi: efivars: Fix variable writes without query_variable_store()
In reply to Greg Kroah-HartmanFrom: Ard Biesheuvel <[email protected]>
commit 8a254d90a77580244ec57e82bca7eb65656cc167 upstream.
Commit bbc6d2c6ef22 ("efi: vars: Switch to new wrapper layer") refactored the efivars layer so that the 'business logic' related to which UEFI variables affect the boot flow in which way could be moved out of it, and into the efivarfs driver.
This inadvertently broke setting variables on firmware implementations that lack the QueryVariableInfo() boot service, because we no longer tolerate a EFI_UNSUPPORTED result from check_var_size() when calling efivar_entry_set_get_size(), which now ends up calling check_var_size() a second time inadvertently.
If QueryVariableInfo() is missing, we support writes of up to 64k - let's move that logic into check_var_size(), and drop the redundant call.
--- drivers/firmware/efi/vars.c | 10 +++++----- fs/efivarfs/vars.c | 16 ---------------- include/linux/efi.h | 3 --- 3 files changed, 5 insertions(+), 24 deletions(-)
drivers/firmware/efi/vars.c +5 -5
@@ -7,6 +7,7 @@*/ #include <linux/types.h> +#include <linux/sizes.h> #include <linux/errno.h> #include <linux/init.h> #include <linux/module.h>
@@ -20,19 +21,19 @@ static struct efivars *__efivars;static DEFINE_SEMAPHORE (efivars_lock); -efi_status_t check_var_size (u32 attributes,unsigned long size) +static efi_status_t check_var_size (u32 attributes,unsigned long size) {const struct efivar_operations *fops; fops = __efivars->ops;if (!fops->query_variable_store) -return EFI_UNSUPPORTED ; +return (size <=SZ_64K ) ?EFI_SUCCESS :EFI_OUT_OF_RESOURCES ;return fops->query_variable_store (attributes, size, false); } -EXPORT_SYMBOL_NS_GPL (check_var_size,EFIVAR ); +static efi_status_t check_var_size_nonblocking (u32 attributes,unsigned long size) {const struct efivar_operations *fops;
@@ -40,11 +41,10 @@ efi_status_t check_var_size_nonblocking( fops = __efivars->ops;if (!fops->query_variable_store) -return EFI_UNSUPPORTED ; +return (size <=SZ_64K ) ?EFI_SUCCESS :EFI_OUT_OF_RESOURCES ;return fops->query_variable_store (attributes, size, true); } -EXPORT_SYMBOL_NS_GPL (check_var_size_nonblocking,EFIVAR );/** * efivars_kobject - get the kobject for the registered efivars
fs/efivarfs/vars.c +0 -16
@@ -651,22 +651,6 @@ int efivar_entry_set_get_size(struct efiif (err)return err; -/* -* Ensure that the available space hasn't shrunk below the safe level -*/ - status =check_var_size (attributes, *size +ucs2_strsize (name,1024 )); -if (status !=EFI_SUCCESS ) { -if (status !=EFI_UNSUPPORTED ) { - err =efi_status_to_err (status); - goto out; - } - -if (*size >65536 ) { - err = -ENOSPC ; - goto out; - } - } - status =efivar_set_variable_locked (name, vendor, attributes, *size, data, false);if (status !=EFI_SUCCESS ) {
include/linux/efi.h +0 -3
@@ -1055,9 +1055,6 @@ efi_status_t efivar_set_variable_locked(efi_status_t efivar_set_variable (efi_char16_t *name,efi_guid_t *vendor,u32 attr,unsigned long data_size,void *data); -efi_status_t check_var_size (u32 attributes,unsigned long size); -efi_status_t check_var_size_nonblocking (u32 attributes,unsigned long size); -#if IS_ENABLED (CONFIG_EFI_CAPSULE_LOADER )extern bool efi_capsule_pending (int *reset_type);
Greg Kroah-Hartman
maintainerPATCH 16/20 efi: ssdt: Dont free memory if ACPI table was loaded successfully
In reply to Greg Kroah-HartmanFrom: Ard Biesheuvel <[email protected]>
commit 4b017e59f01097f19b938f6dc4dc2c4720701610 upstream.
Amadeusz reports KASAN use-after-free errors introduced by commit 3881ee0b1edc ("efi: avoid efivars layer when loading SSDTs from variables"). The problem appears to be that the memory that holds the new ACPI table is now freed unconditionally, instead of only when the ACPI core reported a failure to load the table.
So let's fix this, by omitting the kfree() on success.
--- drivers/firmware/efi/efi.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/firmware/efi/efi.c +2 -0
@@ -269,6 +269,8 @@ static __init int efivar_ssdt_load(void)acpi_status ret =acpi_load_table (data,NULL );if (ret)pr_err ("failed to load table: %u\n" , ret); +else +continue ; }else {pr_err ("failed to get var data: 0x%lx\n" , status); }
Greg Kroah-Hartman
maintainerPATCH 17/20 gcov: support GCC 12.1 and newer compilers
In reply to Greg Kroah-HartmanFrom: Martin Liska <[email protected]>
commit 977ef30a7d888eeb52fb6908f99080f33e5309a8 upstream.
Starting with GCC 12.1, the created .gcda format can't be read by gcov tool. There are 2 significant changes to the .gcda file format that need to be supported:
a) [gcov: Use system IO buffering] (23eb66d1d46a34cb28c4acbdf8a1deb80a7c5a05) changed that all sizes in the format are in bytes and not in words (4B)
b) [gcov: make profile merging smarter] (72e0c742bd01f8e7e6dcca64042b9ad7e75979de) add a new checksum to the file header.
Tested with GCC 7.5, 10.4, 12.2 and the current master.
--- kernel/gcov/gcc_4_7.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-)
kernel/gcov/gcc_4_7.c +16 -2
@@ -30,6 +30,13 @@#define GCOV_TAG_FUNCTION_LENGTH 3 +/* Since GCC 12.1 sizes are in BYTES and not in WORDS (4B). */ +#if (__GNUC__ >=12 ) +#define GCOV_UNIT_SIZE 4 +#else +#define GCOV_UNIT_SIZE 1 +#endif +static struct gcov_info *gcov_info_head;/**
@@ -383,12 +390,18 @@ size_t convert_to_gcda(char *buffer, str pos +=store_gcov_u32 (buffer, pos, info->version); pos +=store_gcov_u32 (buffer, pos, info->stamp); +#if (__GNUC__ >=12 ) +/* Use zero as checksum of the compilation unit. */ + pos +=store_gcov_u32 (buffer, pos,0 ); +#endif +for (fi_idx =0 ; fi_idx < info->n_functions; fi_idx++) { fi_ptr = info->functions[fi_idx];/* Function record. */ pos +=store_gcov_u32 (buffer, pos,GCOV_TAG_FUNCTION ); - pos +=store_gcov_u32 (buffer, pos,GCOV_TAG_FUNCTION_LENGTH ); + pos +=store_gcov_u32 (buffer, pos, +GCOV_TAG_FUNCTION_LENGTH *GCOV_UNIT_SIZE ); pos +=store_gcov_u32 (buffer, pos, fi_ptr->ident); pos +=store_gcov_u32 (buffer, pos, fi_ptr->lineno_checksum); pos +=store_gcov_u32 (buffer, pos, fi_ptr->cfg_checksum);
@@ -402,7 +415,8 @@ size_t convert_to_gcda(char *buffer, str/* Counter record. */ pos +=store_gcov_u32 (buffer, pos,GCOV_TAG_FOR_COUNTER (ct_idx)); - pos +=store_gcov_u32 (buffer, pos, ci_ptr->num *2 ); + pos +=store_gcov_u32 (buffer, pos, + ci_ptr->num *2 *GCOV_UNIT_SIZE );for (cv_idx =0 ; cv_idx < ci_ptr->num; cv_idx++) { pos += store_gcov_u64(buffer, pos,
Greg Kroah-Hartman
maintainerPATCH 18/20 io-wq: Fix memory leak in worker creation
In reply to Greg Kroah-HartmanFrom: Rafael Mendonca <[email protected]>
commit 996d3efeb091c503afd3ee6b5e20eabf446fd955 upstream.
If the CPU mask allocation for a node fails, then the memory allocated for the 'io_wqe' struct of the current node doesn't get freed on the error handling path, since it has not yet been added to the 'wqes' array.
This was spotted when fuzzing v6.1-rc1 with Syzkaller:
BUG: memory leak
unreferenced object 0xffff8880093d5000 (size 1024):
comm "syz-executor.2", pid 7701, jiffies 4295048595 (age 13.900s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000cb463369>] __kmem_cache_alloc_node+0x18e/0x720
[<00000000147a3f9c>] kmalloc_node_trace+0x2a/0x130
[<000000004e107011>] io_wq_create+0x7b9/0xdc0
[<00000000c38b2018>] io_uring_alloc_task_context+0x31e/0x59d
[<00000000867399da>] __io_uring_add_tctx_node.cold+0x19/0x1ba
[<000000007e0e7a79>] io_uring_setup.cold+0x1b80/0x1dce
[<00000000b545e9f6>] __x64_sys_io_uring_setup+0x5d/0x80
[<000000008a8a7508>] do_syscall_64+0x5d/0x90
[<000000004ac08bec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd--- io_uring/io-wq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
io_uring/io-wq.c +1 -1
@@ -1164,10 +1164,10 @@ struct io_wq *io_wq_create(unsigned boun wqe =kzalloc_node (sizeof (struct io_wqe ),GFP_KERNEL , alloc_node);if (!wqe) goto err; + wq->wqes[node] = wqe;if (!alloc_cpumask_var (&wqe->cpu_mask,GFP_KERNEL )) goto err;cpumask_copy (wqe->cpu_mask,cpumask_of_node (node)); - wq->wqes[node] = wqe; wqe->node = alloc_node; wqe->acct[IO_WQ_ACCT_BOUND ].max_workers = bounded; wqe->acct[IO_WQ_ACCT_UNBOUND].max_workers =
Greg Kroah-Hartman
maintainerPATCH 19/20 mm/huge_memory: do not clobber swp_entry_t during THP split
In reply to Greg Kroah-HartmanFrom: Mel Gorman <[email protected]>
commit 71e2d666ef85d51834d658830f823560c402b8b6 upstream.
The following has been observed when running stressng mmap since commit b653db77350c ("mm: Clear page->private when splitting or migrating a page")
watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546]
CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374
Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016
RIP: 0010:xas_descend+0x28/0x80
Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2
RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246
RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002
RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0
RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0
R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000
R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88
FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
xas_load+0x3a/0x50
__filemap_get_folio+0x80/0x370
? put_swap_page+0x163/0x360
pagecache_get_page+0x13/0x90
__try_to_reclaim_swap+0x50/0x190
scan_swap_map_slots+0x31e/0x670
get_swap_pages+0x226/0x3c0
folio_alloc_swap+0x1cc/0x240
add_to_swap+0x14/0x70
shrink_page_list+0x968/0xbc0
reclaim_page_list+0x70/0xf0
reclaim_pages+0xdd/0x120
madvise_cold_or_pageout_pte_range+0x814/0xf30
walk_pgd_range+0x637/0xa30
__walk_page_range+0x142/0x170
walk_page_range+0x146/0x170
madvise_pageout+0xb7/0x280
? asm_common_interrupt+0x22/0x40
madvise_vma_behavior+0x3b7/0xac0
? find_vma+0x4a/0x70
? find_vma+0x64/0x70
? madvise_vma_anon_name+0x40/0x40
madvise_walk_vmas+0xa6/0x130
do_madvise+0x2f4/0x360
__x64_sys_madvise+0x26/0x30
do_syscall_64+0x5b/0x80
? do_syscall_64+0x67/0x80
? syscall_exit_to_user_mode+0x17/0x40
? do_syscall_64+0x67/0x80
? syscall_exit_to_user_mode+0x17/0x40
? do_syscall_64+0x67/0x80
? do_syscall_64+0x67/0x80
? common_interrupt+0x8b/0xa0
entry_SYSCALL_64_after_hwframe+0x63/0xcdThe problem can be reproduced with the mmtests config config-workload-stressng-mmap. It does not always happen and when it triggers is variable but it has happened on multiple machines.
The intent of commit b653db77350c patch was to avoid the case where PG_private is clear but folio->private is not-NULL. However, THP tail pages uses page->private for "swp_entry_t if folio_test_swapcache()" as stated in the documentation for struct folio. This patch only clobbers page->private for tail pages if the head page was not in swapcache and warns once if page->private had an unexpected value.
--- mm/huge_memory.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
mm/huge_memory.c +10 -1
@@ -2445,7 +2445,16 @@ static void __split_huge_page_tail(struc page_tail); page_tail->mapping = head->mapping; page_tail->index = head->index + tail; - page_tail->private =0 ; + +/* +* page->private should not be set in tail pages with the exception +* of swap cache pages that store the swp_entry_t in tail pages. +* Fix up and warn once if private is unexpectedly set. +*/ +if (!folio_test_swapcache (page_folio (head))) { +VM_WARN_ON_ONCE_PAGE (page_tail->private !=0 , head); + page_tail->private =0 ; + }/* Page flags must be visible before we make the page non-compound. */ smp_wmb ();
Re: [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split
Quoted 71 lines · Greg Kroah-Hartman
From: Mel Gorman <[email protected]>
commit
71e2d666ef85d51834d658830f823560c402b8b6upstream.The following has been observed when running stressng mmap since commit
b653db77350c("mm: Clearpage->privatewhen splitting or migrating a page")watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546] CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374 Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016 RIP: 0010:xas_descend+0x28/0x80 Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2 RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246 RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002 RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0 RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0 R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000 R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88 FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xas_load+0x3a/0x50 __filemap_get_folio+0x80/0x370 ? put_swap_page+0x163/0x360 pagecache_get_page+0x13/0x90 __try_to_reclaim_swap+0x50/0x190 scan_swap_map_slots+0x31e/0x670 get_swap_pages+0x226/0x3c0 folio_alloc_swap+0x1cc/0x240 add_to_swap+0x14/0x70 shrink_page_list+0x968/0xbc0 reclaim_page_list+0x70/0xf0 reclaim_pages+0xdd/0x120 madvise_cold_or_pageout_pte_range+0x814/0xf30 walk_pgd_range+0x637/0xa30 __walk_page_range+0x142/0x170 walk_page_range+0x146/0x170 madvise_pageout+0xb7/0x280 ? asm_common_interrupt+0x22/0x40 madvise_vma_behavior+0x3b7/0xac0 ? find_vma+0x4a/0x70 ? find_vma+0x64/0x70 ? madvise_vma_anon_name+0x40/0x40 madvise_walk_vmas+0xa6/0x130 do_madvise+0x2f4/0x360 __x64_sys_madvise+0x26/0x30 do_syscall_64+0x5b/0x80 ? do_syscall_64+0x67/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 ? do_syscall_64+0x67/0x80 ? common_interrupt+0x8b/0xa0 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe problem can be reproduced with the mmtests config config-workload-stressng-mmap. It does not always happen and when it triggers is variable but it has happened on multiple machines.
The intent of commit
b653db77350cpatch was to avoid the case wherePG_privateis clear butfolio->privateis not-NULL. However, THP tail pages usespage->privatefor "swp_entry_tiffolio_test_swapcache()" as stated in the documentation for struct folio. This patch only clobberspage->privatefor tail pages if the head page was not in swapcache and warns once ifpage->privatehad an unexpected value.
Quoted 15 lines
Fixes b653db77350c ("mm: Clear page->private when splitting or migrating a page")Signed-off-by Mel Gorman <[email protected]>Cc Matthew Wilcox (Oracle) <[email protected]>Cc Mel Gorman <[email protected]>Cc Yang Shi <[email protected]>Cc Brian Foster <[email protected]>Cc Dan Streetman <[email protected]>Cc Miaohe Lin <[email protected]>Cc Oleksandr Natalenko <[email protected]>Cc Seth Jennings <[email protected]>Cc Vitaly Wool <[email protected]>Cc <[email protected]>Signed-off-by Andrew Morton <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>
Greg, this patch from Mel is important,
but introduces a warning which is giving Tvrtko trouble - see linux-mm
https://lore.kernel.org/linux-mm/[email protected]/
We already have the fix for the warning, it's making its way through the system, and is marked for stable, but it has not reached Linus's tree yet.
Please drop this 19/20 from 6.0.4, then I'll reply to this to let you know when the fix does reach Linus's tree - hopefully the two can go together in the next 6.0-stable.
I apologize for not writing yesterday: gmail had gathered together different threads with the same subject, I thought you and stable were Cc'ed on the linux-mm mail and you would immediately drop it yourself, but in fact you were not on that thread at all.
Thanks,
Hugh
Greg Kroah-Hartman
maintainerRe: [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split
Quoted 95 lines · Hugh Dickins
Quoted 71 lines · Greg Kroah-Hartman
From: Mel Gorman <[email protected]>
commit
71e2d666ef85d51834d658830f823560c402b8b6upstream.The following has been observed when running stressng mmap since commit
b653db77350c("mm: Clearpage->privatewhen splitting or migrating a page")watchdog: BUG: soft lockup - CPU#75 stuck for 26s! [stress-ng:9546] CPU: 75 PID: 9546 Comm: stress-ng Tainted: G E 6.0.0-revert-b653db77-fix+ #29 0357d79b60fb09775f678e4f3f64ef0579ad1374 Hardware name: SGI.COM C2112-4GP3/X10DRT-P-Series, BIOS 2.0a 05/09/2016 RIP: 0010:xas_descend+0x28/0x80 Code: cc cc 0f b6 0e 48 8b 57 08 48 d3 ea 83 e2 3f 89 d0 48 83 c0 04 48 8b 44 c6 08 48 89 77 18 48 89 c1 83 e1 03 48 83 f9 02 75 08 <48> 3d fd 00 00 00 76 08 88 57 12 c3 cc cc cc cc 48 c1 e8 02 89 c2 RSP: 0018:ffffbbf02a2236a8 EFLAGS: 00000246 RAX: ffff9cab7d6a0002 RBX: ffffe04b0af88040 RCX: 0000000000000002 RDX: 0000000000000030 RSI: ffff9cab60509b60 RDI: ffffbbf02a2236c0 RBP: 0000000000000000 R08: ffff9cab60509b60 R09: ffffbbf02a2236c0 R10: 0000000000000001 R11: ffffbbf02a223698 R12: 0000000000000000 R13: ffff9cab4e28da80 R14: 0000000000039c01 R15: ffff9cab4e28da88 FS: 00007fab89b85e40(0000) GS:ffff9cea3fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fab84e00000 CR3: 00000040b73a4003 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xas_load+0x3a/0x50 __filemap_get_folio+0x80/0x370 ? put_swap_page+0x163/0x360 pagecache_get_page+0x13/0x90 __try_to_reclaim_swap+0x50/0x190 scan_swap_map_slots+0x31e/0x670 get_swap_pages+0x226/0x3c0 folio_alloc_swap+0x1cc/0x240 add_to_swap+0x14/0x70 shrink_page_list+0x968/0xbc0 reclaim_page_list+0x70/0xf0 reclaim_pages+0xdd/0x120 madvise_cold_or_pageout_pte_range+0x814/0xf30 walk_pgd_range+0x637/0xa30 __walk_page_range+0x142/0x170 walk_page_range+0x146/0x170 madvise_pageout+0xb7/0x280 ? asm_common_interrupt+0x22/0x40 madvise_vma_behavior+0x3b7/0xac0 ? find_vma+0x4a/0x70 ? find_vma+0x64/0x70 ? madvise_vma_anon_name+0x40/0x40 madvise_walk_vmas+0xa6/0x130 do_madvise+0x2f4/0x360 __x64_sys_madvise+0x26/0x30 do_syscall_64+0x5b/0x80 ? do_syscall_64+0x67/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 ? syscall_exit_to_user_mode+0x17/0x40 ? do_syscall_64+0x67/0x80 ? do_syscall_64+0x67/0x80 ? common_interrupt+0x8b/0xa0 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe problem can be reproduced with the mmtests config config-workload-stressng-mmap. It does not always happen and when it triggers is variable but it has happened on multiple machines.
The intent of commit
b653db77350cpatch was to avoid the case wherePG_privateis clear butfolio->privateis not-NULL. However, THP tail pages usespage->privatefor "swp_entry_tiffolio_test_swapcache()" as stated in the documentation for struct folio. This patch only clobberspage->privatefor tail pages if the head page was not in swapcache and warns once ifpage->privatehad an unexpected value.Quoted 15 lines
Fixes b653db77350c ("mm: Clear page->private when splitting or migrating a page")Signed-off-by Mel Gorman <[email protected]>Cc Matthew Wilcox (Oracle) <[email protected]>Cc Mel Gorman <[email protected]>Cc Yang Shi <[email protected]>Cc Brian Foster <[email protected]>Cc Dan Streetman <[email protected]>Cc Miaohe Lin <[email protected]>Cc Oleksandr Natalenko <[email protected]>Cc Seth Jennings <[email protected]>Cc Vitaly Wool <[email protected]>Cc <[email protected]>Signed-off-by Andrew Morton <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>Greg, this patch from Mel is important,
but introduces a warning which is giving Tvrtko trouble - see linux-mm
https://lore.kernel.org/linux-mm/[email protected]/We already have the fix for the warning, it's making its way through the system, and is marked for stable, but it has not reached Linus's tree yet.
Quoted 8 lines
Please drop this 19/20 from 6.0.4, then I'll reply to this to let you know when the fix does reach Linus's tree - hopefully the two can go together in the next 6.0-stable.
I apologize for not writing yesterday: gmail had gathered together different threads with the same subject, I thought you and stable were Cc'ed on the linux-mm mail and you would immediately drop it yourself, but in fact you were not on that thread at all.
No worries, now dropped, thanks.
greg k-h
Re: [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split
Quoted 18 lines · Greg Kroah-Hartman
Quoted 17 lines · Hugh Dickins
Quoted 4 lines · Greg Kroah-Hartman
From: Mel Gorman <[email protected]>
commit
71e2d666ef85d51834d658830f823560c402b8b6upstream.
...Greg, this patch from Mel is important,
but introduces a warning which is giving Tvrtko trouble - see linux-mm
https://lore.kernel.org/linux-mm/[email protected]/We already have the fix for the warning, it's making its way through the system, and is marked for stable, but it has not reached Linus's tree yet.
Please drop this 19/20 from 6.0.4, then I'll reply to this to let you know when the fix does reach Linus's tree - hopefully the two can go together in the next 6.0-stable.
Quoted 6 lines
Quoted 4 lines
I apologize for not writing yesterday: gmail had gathered together different threads with the same subject, I thought you and stable were Cc'ed on the linux-mm mail and you would immediately drop it yourself, but in fact you were not on that thread at all.
No worries, now dropped, thanks.
Thanks Greg. Linus's tree now contains my fix5aae9265ee1a ("mm: prep_compound_tail() clear page->private")
to Mel's fix71e2d666ef85 ("mm/huge_memory: do not clobber swp_entry_t during THP split") so they can now go on together into 6.0 stable.
They would also have been good in 5.19 stable: but too late now, it's EOL.
Hugh
Greg Kroah-Hartman
maintainerRe: [PATCH 6.0 19/20] mm/huge_memory: do not clobber swp_entry_t during THP split
Quoted 26 lines · Hugh Dickins
Quoted 18 lines · Greg Kroah-Hartman
Quoted 17 lines · Hugh Dickins
Quoted 4 lines · Greg Kroah-Hartman
From: Mel Gorman <[email protected]>
commit
71e2d666ef85d51834d658830f823560c402b8b6upstream.
...Greg, this patch from Mel is important,
but introduces a warning which is giving Tvrtko trouble - see linux-mm
https://lore.kernel.org/linux-mm/[email protected]/We already have the fix for the warning, it's making its way through the system, and is marked for stable, but it has not reached Linus's tree yet.
Please drop this 19/20 from 6.0.4, then I'll reply to this to let you know when the fix does reach Linus's tree - hopefully the two can go together in the next 6.0-stable.
Quoted 6 lines
Quoted 4 lines
I apologize for not writing yesterday: gmail had gathered together different threads with the same subject, I thought you and stable were Cc'ed on the linux-mm mail and you would immediately drop it yourself, but in fact you were not on that thread at all.
No worries, now dropped, thanks.
Quoted 7 lines
Thanks Greg. Linus's tree now contains my fix
5aae9265ee1a("mm:prep_compound_tail()clearpage->private")
to Mel's fix71e2d666ef85("mm/huge_memory: do not clobberswp_entry_tduring THP split") so they can now go on together into 6.0 stable.They would also have been good in 5.19 stable: but too late now, it's EOL.
Thanks, both now queued up for 6.0
greg k-h
Greg Kroah-Hartman
maintainerPATCH 20/20 fbdev/core: Remove remove_conflicting_pci_framebuffers()
In reply to Greg Kroah-HartmanFrom: Thomas Zimmermann <[email protected]>
commit 9d69ef1838150c7d87afc1a87aa658c637217585 upstream.
Remove remove_conflicting_pci_framebuffers() and implement similar functionality in aperture_remove_conflicting_pci_device(), which was the only caller. Removes an otherwise unused interface and streamlines the aperture helper. No functional changes.
--- drivers/video/aperture.c | 30 ++++++++++++++---------- drivers/video/fbdev/core/fbmem.c | 48 --------------------------------------- include/linux/fb.h | 2 - 3 files changed, 18 insertions(+), 62 deletions(-)
drivers/video/aperture.c +18 -12
@@ -335,30 +335,36 @@ EXPORT_SYMBOL(aperture_remove_conflictin*/ int aperture_remove_conflicting_pci_devices (struct pci_dev *pdev,const char *name) { +bool primary = false;resource_size_t base, size;int bar, ret; -/* -* WARNING: Apparently we must kick fbdev drivers before vgacon, -* otherwise the vga fbdev driver falls over. -*/ -#if IS_REACHABLE (CONFIG_FB ) - ret =remove_conflicting_pci_framebuffers (pdev, name); -if (ret) -return ret; +#ifdef CONFIG_X86 + primary = pdev->resource[PCI_ROM_RESOURCE ].flags &IORESOURCE_ROM_SHADOW ;#endif - ret =vga_remove_vgacon (pdev); -if (ret) -return ret;for (bar =0 ; bar <PCI_STD_NUM_BARS ; ++bar) {if (!(pci_resource_flags (pdev, bar) &IORESOURCE_MEM ))continue ; + base =pci_resource_start (pdev, bar); size =pci_resource_len (pdev, bar); -aperture_detach_devices (base, size); + ret =aperture_remove_conflicting_devices (base, size, primary, name); +if (ret) +break ; } +if (ret) +return ret; + +/* +* WARNING: Apparently we must kick fbdev drivers before vgacon, +* otherwise the vga fbdev driver falls over. +*/ + ret =vga_remove_vgacon (pdev); +if (ret) +return ret; +return 0 ; }
drivers/video/fbdev/core/fbmem.c +0 -48
54 lines not on this page · raw message
include/linux/fb.h +0 -2
@@ -615,8 +615,6 @@ extern ssize_t fb_sys_write(struct fb_in/* drivers/video/fbmem.c */ extern int register_framebuffer (struct fb_info *fb_info);extern void unregister_framebuffer (struct fb_info *fb_info); -extern int remove_conflicting_pci_framebuffers (struct pci_dev *pdev, -const char *name);extern int remove_conflicting_framebuffers (struct apertures_struct *a,const char *name,bool primary);extern int fb_prepare_logo (struct fb_info *fb_info,int rotate);
Re: [PATCH 6.0 20/20] fbdev/core: Remove remove_conflicting_pci_framebuffers()
Quoted 134 lines · Greg Kroah-Hartman
From: Thomas Zimmermann <[email protected]>
commit
9d69ef1838150c7d87afc1a87aa658c637217585upstream.Remove
remove_conflicting_pci_framebuffers()and implement similar functionality inaperture_remove_conflicting_pci_device(), which was the only caller. Removes an otherwise unused interface and streamlines the aperture helper. No functional changes.Signed-off-by Thomas Zimmermann <[email protected]>Reviewed-by Javier Martinez Canillas <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- drivers/video/aperture.c | 30 ++++++++++++++---------- drivers/video/fbdev/core/fbmem.c | 48 --------------------------------------- include/linux/fb.h | 2 - 3 files changed, 18 insertions(+), 62 deletions(-)drivers/video/aperture.c +18
-12@@ -335,30 +335,36 @@ EXPORT_SYMBOL(aperture_remove_conflictin*/ int aperture_remove_conflicting_pci_devices (struct pci_dev *pdev,const char *name) { +bool primary = false;resource_size_t base, size;int bar, ret; -/* -* WARNING: Apparently we must kick fbdev drivers before vgacon, -* otherwise the vga fbdev driver falls over. -*/ -#if IS_REACHABLE (CONFIG_FB ) - ret =remove_conflicting_pci_framebuffers (pdev, name); -if (ret) -return ret; +#ifdef CONFIG_X86 + primary = pdev->resource[PCI_ROM_RESOURCE ].flags &IORESOURCE_ROM_SHADOW ;#endif - ret =vga_remove_vgacon (pdev); -if (ret) -return ret;for (bar =0 ; bar <PCI_STD_NUM_BARS ; ++bar) {if (!(pci_resource_flags (pdev, bar) &IORESOURCE_MEM ))continue ; + base =pci_resource_start (pdev, bar); size =pci_resource_len (pdev, bar); -aperture_detach_devices (base, size); + ret =aperture_remove_conflicting_devices (base, size, primary, name); +if (ret) +break ; } +if (ret) +return ret; + +/* +* WARNING: Apparently we must kick fbdev drivers before vgacon, +* otherwise the vga fbdev driver falls over. +*/ + ret =vga_remove_vgacon (pdev); +if (ret) +return ret; +return 0 ; }drivers/video/fbdev/core/fbmem.c +0
-48@@ -1788,54 +1788,6 @@ int remove_conflicting_framebuffers(struEXPORT_SYMBOL (remove_conflicting_framebuffers);/** -* remove_conflicting_pci_framebuffers - remove firmware-configured framebuffers for PCI devices -* @pdev: PCI device -* @name: requesting driver name -* -* This function removes framebuffer devices (eg. initialized by firmware) -* using memory range configured for any of @pdev's memory bars. -* -* The function assumes that PCI device with shadowed ROM drives a primary -* display and so kicks out vga16fb. -*/ -int remove_conflicting_pci_framebuffers (struct pci_dev *pdev,const char *name) -{ -struct apertures_struct *ap; -bool primary = false; -int err, idx, bar; - -for (idx =0 , bar =0 ; bar <PCI_STD_NUM_BARS ; bar++) { -if (!(pci_resource_flags (pdev, bar) &IORESOURCE_MEM )) -continue ; - idx++; - } - - ap =alloc_apertures (idx); -if (!ap) -return -ENOMEM ; - -for (idx =0 , bar =0 ; bar <PCI_STD_NUM_BARS ; bar++) { -if (!(pci_resource_flags (pdev, bar) &IORESOURCE_MEM )) -continue ; - ap->ranges[idx].base =pci_resource_start (pdev, bar); - ap->ranges[idx].size =pci_resource_len (pdev, bar); -pci_dbg (pdev,"%s: bar %d: 0x%lx -> 0x%lx\n" , __func__, bar, - (unsigned long )pci_resource_start (pdev, bar), - (unsigned long )pci_resource_end (pdev, bar)); - idx++; - } - -#ifdef CONFIG_X86 - primary = pdev->resource[PCI_ROM_RESOURCE ].flags & -IORESOURCE_ROM_SHADOW ; -#endif - err =remove_conflicting_framebuffers (ap, name, primary); -kfree (ap); -return err; -} -EXPORT_SYMBOL (remove_conflicting_pci_framebuffers); - -/** * register_framebuffer - registers a frame buffer device * @fb_info: frame buffer info structure *
include/linux/fb.h extern ssize_t fb_sys_write(struct fb_in · line 620
Quoted 8 lines
include/linux/fb.h +0
-2@@ -615,8 +615,6 @@ extern ssize_t fb_sys_write(struct fb_in/* drivers/video/fbmem.c */ extern int register_framebuffer (struct fb_info *fb_info);extern void unregister_framebuffer (struct fb_info *fb_info); -extern int remove_conflicting_pci_framebuffers (struct pci_dev *pdev, -const char *name);extern int remove_conflicting_framebuffers (struct apertures_struct *a,const char *name,bool primary);extern int fb_prepare_logo (struct fb_info *fb_info,int rotate);
Hello,
this patch seems to disable console/framebuffer when vfio-pci is used.
I hava 2 nvidia GPUs one is used for host and other is passed through to VM.
Now after this patch, when vfio-pci module is loaded with parameter ids=10de:2486,10de:228b,
console is lost/frozen, last message is that vfio-pci module was loaded and then there is no more output.
This PCI IDs (10de:2486,10de:228b) are for secondary GPU, primary/boot GPU is used for host and boot messages are displayed on primary/boot GPU.
Using dmesg I see this messages after vfio-pci is loaded:
[ 3.993601] VFIO - User Level meta-driver version: 0.3
[ 4.020239] Console: switching to colour dummy device 80x25
[ 4.020335] vfio-pci 0000:1a:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [ 4.020722] vfio_pci: add [10de:2486[ffffffff:ffffffff]] class 0x000000/00000000
[ 4.116616] vfio_pci: add [10de:228b[ffffffff:ffffffff]] class 0x000000/00000000
I guess the problem here is "Console: switching to colour dummy device 80x25", but I don't know why this happens. Last working kernel is 6.0.3, after upgrading to 6.0.4 (and 6.0.5, 6.0.6), console is no longer working. By git bisecting it seems bad commit is af9ac541e88390d97b01d5e8c77309d2637c1d4c.
Re: [PATCH 6.0 20/20] fbdev/core: Remove remove_conflicting_pci_framebuffers()
(cc: Alex Williamson)
Hi
Am 01.11.22 um 09:42 schrieb Boris V.:
Quoted 148 lines · Greg Kroah-Hartman
Quoted 136 lines
From: Thomas Zimmermann <[email protected]>
commit
9d69ef1838150c7d87afc1a87aa658c637217585upstream.Remove
remove_conflicting_pci_framebuffers()and implement similar functionality inaperture_remove_conflicting_pci_device(), which was the only caller. Removes an otherwise unused interface and streamlines the aperture helper. No functional changes.Signed-off-by Thomas Zimmermann <[email protected]>Reviewed-by Javier Martinez Canillas <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
drivers/video/aperture.c | 30 ++++++++++++++----------drivers/video/fbdev/core/fbmem.c| 48
---------------------------------------
include/linux/fb.h | 2 -3 files changed, 18 insertions(+), 62 deletions(-)drivers/video/aperture.c +18
-12@@ -335,30 +335,36 @@ EXPORT_SYMBOL(aperture_remove_conflictin*/ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *name) { + bool primary = false; resource_size_t base, size; int bar, ret; - /* -* WARNING: Apparently we must kick fbdev drivers before vgacon, -* otherwise the vga fbdev driver falls over. -*/ -#if IS_REACHABLE (CONFIG_FB ) - ret = remove_conflicting_pci_framebuffers(pdev, name); - if (ret) - return ret; +#ifdef CONFIG_X86 + primary = pdev->resource[PCI_ROM_RESOURCE].flags &IORESOURCE_ROM_SHADOW ; #endif - ret = vga_remove_vgacon(pdev); - if (ret) - return ret; for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) { if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) continue; + base = pci_resource_start(pdev, bar); size = pci_resource_len(pdev, bar); - aperture_detach_devices(base, size); + ret = aperture_remove_conflicting_devices(base, size, primary, name); + if (ret) + break; } + if (ret) + return ret; + + /* + * WARNING: Apparently we must kick fbdev drivers before vgacon, + * otherwise the vga fbdev driver falls over. + */ + ret = vga_remove_vgacon(pdev); + if (ret) + return ret; + return 0; }drivers/video/fbdev/core/fbmem.c +0
-1@@ -1788,54 +1788,6 @@ int remove_conflicting_framebuffers(stru EXPORT_SYMBOL(remove_conflicting_framebuffers); /** -* remove_conflicting_pci_framebuffers - remove firmware-configured framebuffers for PCI devices
- * @pdev: PCI device
- * @name: requesting driver name
- *
- * This function removes framebuffer devices (eg. initialized by firmware)
- * using memory range configured for any of @pdev's memory bars.
- *
- * The function assumes that PCI device with shadowed ROM drives a primary
- * display and so kicks out vga16fb.
- */
-intremove_conflicting_pci_framebuffers(struct pci_dev *pdev, const char *name)drivers/video/fbdev/core/fbmem.c +0
-37-{ - struct apertures_struct *ap; - bool primary = false; - int err, idx, bar; - - for (idx = 0, bar = 0; bar < PCI_STD_NUM_BARS; bar++) { - if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) - continue; - idx++; - } - - ap = alloc_apertures(idx); - if (!ap) - return -ENOMEM; - - for (idx = 0, bar = 0; bar < PCI_STD_NUM_BARS; bar++) { - if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) - continue; - ap->ranges[idx].base = pci_resource_start(pdev, bar); - ap->ranges[idx].size = pci_resource_len(pdev, bar); - pci_dbg(pdev, "%s: bar %d: 0x%lx -> 0x%lx\n", __func__, bar, - (unsigned long)pci_resource_start(pdev, bar), - (unsigned long)pci_resource_end(pdev, bar)); - idx++; - } - -#ifdef CONFIG_X86 - primary = pdev->resource[PCI_ROM_RESOURCE].flags & - IORESOURCE_ROM_SHADOW; -#endif - err = remove_conflicting_framebuffers(ap, name, primary); - kfree(ap); - return err; -} -EXPORT_SYMBOL (remove_conflicting_pci_framebuffers); - -/** *
register_framebuffer- registers a frame buffer device * @fb_info: frame buffer info structure
*include/linux/fb.h extern ssize_t fb_sys_write(struct fb_in · line 620
Quoted 8 lines
include/linux/fb.h +0
-2@@ -615,8 +615,6 @@ extern ssize_t fb_sys_write(struct fb_in /* drivers/video/fbmem.c */ extern int register_framebuffer(struct fb_info *fb_info); extern void unregister_framebuffer(struct fb_info *fb_info); -extern int remove_conflicting_pci_framebuffers (struct pci_dev *pdev, - const char *name); extern int remove_conflicting_framebuffers(struct apertures_struct *a, const char *name, bool primary); extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);Hello,
Quoted 2 lines
this patch seems to disable console/framebuffer when vfio-pci is used. I hava 2 nvidia GPUs one is used for host and other is passed through to VM.
Vfio uses this helper to unload the driver before passing it to a VM AFAIU. But unless you're using nouveau, you're on your own.
Best regards
Thomas
Quoted 16 lines
Now after this patch, when vfio-pci module is loaded with parameter ids=10de:2486,10de:228b,
console is lost/frozen, last message is that vfio-pci module was loaded and then there is no more output.
This PCI IDs (10de:2486,10de:228b) are for secondary GPU, primary/boot GPU is used for host and boot messages are displayed on primary/boot GPU.Using dmesg I see this messages after vfio-pci is loaded:
[ 3.993601] VFIO - User Level meta-driver version: 0.3
[ 4.020239] Console: switching to colour dummy device 80x25
[ 4.020335] vfio-pci 0000:1a:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [ 4.020722]vfio_pci: add [10de:2486[ffffffff:ffffffff]] class 0x000000/00000000
[ 4.116616]vfio_pci: add [10de:228b[ffffffff:ffffffff]] class 0x000000/00000000I guess the problem here is "Console: switching to colour dummy device 80x25", but I don't know why this happens. Last working kernel is 6.0.3, after upgrading to 6.0.4 (and 6.0.5, 6.0.6), console is no longer working. By git bisecting it seems bad commit is
af9ac541e88390d97b01d5e8c77309d2637c1d4c.
Signature · 6 lines
Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
Re: [PATCH 6.0 20/20] fbdev/core: Remove remove_conflicting_pci_framebuffers()
Quoted 153 lines · Thomas Zimmermann
(cc: Alex Williamson)
Hi
Am 01.11.22 um 09:42 schrieb Boris V.:
Quoted 148 lines · Greg Kroah-Hartman
Quoted 136 lines
From: Thomas Zimmermann <[email protected]>
commit
9d69ef1838150c7d87afc1a87aa658c637217585upstream.Remove
remove_conflicting_pci_framebuffers()and implement similar functionality inaperture_remove_conflicting_pci_device(), which was the only caller. Removes an otherwise unused interface and streamlines the aperture helper. No functional changes.Signed-off-by Thomas Zimmermann <[email protected]>Reviewed-by Javier Martinez Canillas <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>---
drivers/video/aperture.c | 30 ++++++++++++++----------drivers/video/fbdev/core/fbmem.c| 48
---------------------------------------
include/linux/fb.h | 2 -3 files changed, 18 insertions(+), 62 deletions(-)drivers/video/aperture.c +18
-12@@ -335,30 +335,36 @@ EXPORT_SYMBOL(aperture_remove_conflictin*/ int aperture_remove_conflicting_pci_devices(struct pci_dev *pdev, const char *name) { + bool primary = false; resource_size_t base, size; int bar, ret; - /* -* WARNING: Apparently we must kick fbdev drivers before vgacon, -* otherwise the vga fbdev driver falls over. -*/ -#if IS_REACHABLE (CONFIG_FB ) - ret = remove_conflicting_pci_framebuffers(pdev, name); - if (ret) - return ret; +#ifdef CONFIG_X86 + primary = pdev->resource[PCI_ROM_RESOURCE].flags &IORESOURCE_ROM_SHADOW ; #endif - ret = vga_remove_vgacon(pdev); - if (ret) - return ret; for (bar = 0; bar < PCI_STD_NUM_BARS; ++bar) { if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) continue; + base = pci_resource_start(pdev, bar); size = pci_resource_len(pdev, bar); - aperture_detach_devices(base, size); + ret = aperture_remove_conflicting_devices(base, size, primary, name); + if (ret) + break; } + if (ret) + return ret; + + /* + * WARNING: Apparently we must kick fbdev drivers before vgacon, + * otherwise the vga fbdev driver falls over. + */ + ret = vga_remove_vgacon(pdev); + if (ret) + return ret; + return 0; }drivers/video/fbdev/core/fbmem.c +0
-1@@ -1788,54 +1788,6 @@ int remove_conflicting_framebuffers(stru EXPORT_SYMBOL(remove_conflicting_framebuffers); /** -* remove_conflicting_pci_framebuffers - remove firmware-configured framebuffers for PCI devices
- * @pdev: PCI device
- * @name: requesting driver name
- *
- * This function removes framebuffer devices (eg. initialized by firmware)
- * using memory range configured for any of @pdev's memory bars.
- *
- * The function assumes that PCI device with shadowed ROM drives a primary
- * display and so kicks out vga16fb.
- */
-intremove_conflicting_pci_framebuffers(struct pci_dev *pdev, const char *name)drivers/video/fbdev/core/fbmem.c +0
-37-{ - struct apertures_struct *ap; - bool primary = false; - int err, idx, bar; - - for (idx = 0, bar = 0; bar < PCI_STD_NUM_BARS; bar++) { - if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) - continue; - idx++; - } - - ap = alloc_apertures(idx); - if (!ap) - return -ENOMEM; - - for (idx = 0, bar = 0; bar < PCI_STD_NUM_BARS; bar++) { - if (!(pci_resource_flags(pdev, bar) & IORESOURCE_MEM)) - continue; - ap->ranges[idx].base = pci_resource_start(pdev, bar); - ap->ranges[idx].size = pci_resource_len(pdev, bar); - pci_dbg(pdev, "%s: bar %d: 0x%lx -> 0x%lx\n", __func__, bar, - (unsigned long)pci_resource_start(pdev, bar), - (unsigned long)pci_resource_end(pdev, bar)); - idx++; - } - -#ifdef CONFIG_X86 - primary = pdev->resource[PCI_ROM_RESOURCE].flags & - IORESOURCE_ROM_SHADOW; -#endif - err = remove_conflicting_framebuffers(ap, name, primary); - kfree(ap); - return err; -} -EXPORT_SYMBOL (remove_conflicting_pci_framebuffers); - -/** *
register_framebuffer- registers a frame buffer device * @fb_info: frame buffer info structure
*include/linux/fb.h extern ssize_t fb_sys_write(struct fb_in · line 620
Quoted 8 lines
include/linux/fb.h +0
-2@@ -615,8 +615,6 @@ extern ssize_t fb_sys_write(struct fb_in /* drivers/video/fbmem.c */ extern int register_framebuffer(struct fb_info *fb_info); extern void unregister_framebuffer(struct fb_info *fb_info); -extern int remove_conflicting_pci_framebuffers (struct pci_dev *pdev, - const char *name); extern int remove_conflicting_framebuffers(struct apertures_struct *a, const char *name, bool primary); extern int fb_prepare_logo(struct fb_info *fb_info, int rotate);Hello,
Quoted 8 lines
Quoted 2 lines
this patch seems to disable console/framebuffer when vfio-pci is used. I hava 2 nvidia GPUs one is used for host and other is passed through to VM.
Vfio uses this helper to unload the driver before passing it to a VM AFAIU. But unless you're using nouveau, you're on your own.
Best regards
Thomas
But this happens at boot, when vfio-pci module is loaded. Not when VM is started.
And console/framebuffer is unloaded for primary/boot GPU, not the one passed to VM.
Also no GPU driver is loaded at this point. And there was no problem before, it stopped working with 6.0.4 kernel.
Works on my Arch Linux Server with Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.4 release. There are 20 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, 26 Oct 2022 11:29:24 +0000.
Hi Greg,
6.0.4-rc1 tested.
Run tested on:
- Intel Alder Lake x86_64 (nuc12 i7-1260P)
In addition - build tested for:
- Allwinner A64
- Allwinner H3
- Allwinner H5
- Allwinner H6
- NXP iMX6
- NXP iMX8
- Qualcomm Dragonboard
- Rockchip RK3288
- Rockchip RK3328
- Rockchip RK3399pro
- Samsung Exynos5422
--
Rudi
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.4 release. There are 20 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, 26 Oct 2022 11:29:24 +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/v6.x/stable-review/patch-6.0.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.4 release. There are 20 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, 26 Oct 2022 11:29:24 +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/v6.x/stable-review/patch-6.0.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.y
and the diffstat can be found below.thanks,
greg k-h
No new regressions for Tegra ...
Test results for stable-v6.0:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
130 tests: 128 pass, 2 failLinux version: 6.0.4-rc1-gd4150c7b49be
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Test failures: tegra194-p2972-0000: boot.py
tegra210-p3450-0000: devices
Jon
Signature · 1 line
nvpublic
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.4 release. There are 20 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, 26 Oct 2022 11:29:24 +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/v6.x/stable-review/patch-6.0.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.4 release. There are 20 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, 26 Oct 2022 11:29:24 +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/v6.x/stable-review/patch-6.0.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.4 release. There are 20 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, 26 Oct 2022 11:29:24 +0000. Anything received after that time might be too late.
6.0.4-rc1 compiled and booted on my x86_64 test system. No errors or regressions.
All the best,
-srw
Hey Greg,
Ran tests and boot tested on my system, no regressions found
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.4 release. There are 20 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.
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 10.2.0) and powerpc (ps3_defconfig, GCC 12.1.0).
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.4 release. There are 20 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, 26 Oct 2022 11:29:24 +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/v6.x/stable-review/patch-6.0.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro's test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.0.4-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-6.0.y
* git commit: [None, 'd4150c7b49be8290e2a00c80f2bb2a534a627ad6']
* git describe: v6.0.3-22-gd4150c7b49be
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.0.y/build/v6.0.3-22-gd4150c7b49be
## No sTest Regressions (compared to v6.0.3)
## No Metric Regressions (compared to v6.0.3)
## No Test Fixes (compared to v6.0.3)
## No Metric Fixes (compared to v6.0.3)
## Test result summary
total: 144226, pass: 123359, fail: 5726, skip: 14716, xfail: 425
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 329 total, 325 passed, 4 failed
* arm64: 61 total, 61 passed, 0 failed
* i386: 53 total, 53 passed, 0 failed
* mips: 54 total, 53 passed, 1 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 67 total, 61 passed, 6 failed
* riscv: 26 total, 26 passed, 0 failed
* s390: 14 total, 14 passed, 0 failed
* sh: 23 total, 23 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 58 total, 58 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-at
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.4 release. There are 20 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, 26 Oct 2022 11:29:24 +0000. Anything received after that time might be too late.
Teest results are for 6.0.3-22-gd4150c7.
Build results:
total: 152 pass: 152 fail: 0 Qemu test results: total: 499 pass: 499 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.4 release. There are 20 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, 26 Oct 2022 11:29:24 +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/v6.x/stable-review/patch-6.0.4-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, armv7, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Missed a patch?
Problematic patch in v6.0.3 :
Quoted 8 lines
commit
3ea7c50339859394dd667184b5b16eee1ebb53bcAuthor: Josef Bacik <[email protected]> Date: Mon Aug 8 16:10:26 2022 -0400btrfs: call
__btrfs_remove_free_space_cache_lockedon cache load failure [ Upstream commit8a1ae2781dee9fc21ca82db682d37bea4bd074ad] Now that lockdep is staying enabled through our entire CI runs I started seeing the following stack in generic/475
See:
https://lore.kernel.org/stable/Y1aeWdHd4%[email protected]/
Quoted 15 lines
Well I definitely fucked this patch up, because I should have used the
_lockedvariant, but this was part of a series where I did the correct thing in the next patchbtrfs: remove use
btrfs_remove_free_space_cacheinstead of variantso this problem doesn't exist in linus. So either we need to pull that back into stable as well, or drop this patch from stable. I'm good either way, this was just to fix a lockdep splat so it's not really stable material, but I'll leave that decision up to y'all. Thanks,
Josef
Greg Kroah-Hartman
maintainerQuoted 14 lines · Ernst Herzberg
Missed a patch?
Problematic patch in v6.0.3 :
Quoted 8 lines
commit
3ea7c50339859394dd667184b5b16eee1ebb53bcAuthor: Josef Bacik <[email protected]> Date: Mon Aug 8 16:10:26 2022 -0400btrfs: call
__btrfs_remove_free_space_cache_lockedon cache load failure [ Upstream commit8a1ae2781dee9fc21ca82db682d37bea4bd074ad] Now that lockdep is staying enabled through our entire CI runs I started seeing the following stack in generic/475
Quoted 3 lines
See:
That will be resolved in the next release, give us a chance to get this one out first...
thanks,
greg k-h