6.1.22-rc1 review
Subsystems (6)
Greg Kroah-Hartman
maintainerPATCH 158/224 selftests/x86/amx: Add a ptrace test
In reply to Greg Kroah-HartmanFrom: Chang S. Bae <[email protected]>
commit 62faca1ca10cc84e99ae7f38aa28df2bc945369b upstream.
Include a test case to validate the XTILEDATA injection to the target.
Also, it ensures the kernel's ability to copy states between different XSAVE formats.
Refactor the memcmp() code to be usable for the state validation.
--- tools/testing/selftests/x86/amx.c | 108 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 105 insertions(+), 3 deletions(-)
tools/testing/selftests/x86/amx.c +105 -3
@@ -14,8 +14,10 @@#include <sys/auxv.h> #include <sys/mman.h> #include <sys/shm.h> +#include <sys/ptrace.h> #include <sys/syscall.h> #include <sys/wait.h> +#include <sys/uio.h> #include "../kselftest.h" /* For __cpuid_count() */
@@ -583,6 +585,13 @@ static void test_dynamic_state(void)_exit (0 ); } +static inline int __compare_tiledata_state (struct xsave_buffer *xbuf1,struct xsave_buffer *xbuf2) +{ +return memcmp (&xbuf1->bytes[xtiledata.xbuf_offset], + &xbuf2->bytes[xtiledata.xbuf_offset], + xtiledata.size); +} +/* * Save current register state and compare it to @xbuf1.' *
@@ -599,9 +608,7 @@ static inline bool __validate_tiledata_rfatal_error ("failed to allocate XSAVE buffer\n" );xsave (xbuf2,XFEATURE_MASK_XTILEDATA ); - ret =memcmp (&xbuf1->bytes[xtiledata.xbuf_offset], - &xbuf2->bytes[xtiledata.xbuf_offset], - xtiledata.size); + ret =__compare_tiledata_state (xbuf1, xbuf2);free (xbuf2);
@@ -826,6 +833,99 @@ static void test_context_switch(void)free (finfo); } +/* Ptrace test */ + +/* +* Make sure the ptracee has the expanded kernel buffer on the first +* use. Then, initialize the state before performing the state +* injection from the ptracer. +*/ +static inline void ptracee_firstuse_tiledata (void ) +{ +load_rand_tiledata (stashed_xsave); +init_xtiledata (); +} + +/* +* Ptracer injects the randomized tile data state. It also reads +* before and after that, which will execute the kernel's state copy +* functions. So, the tester is advised to double-check any emitted +* kernel messages. +*/ +static void ptracer_inject_tiledata (pid_t target) +{ +struct xsave_buffer *xbuf; +struct iovec iov; + + xbuf =alloc_xbuf (); +if (!xbuf) +fatal_error ("unable to allocate XSAVE buffer" ); + +printf ("\tRead the init'ed tiledata via ptrace().\n" ); + + iov.iov_base = xbuf; + iov.iov_len = xbuf_size; + +memset (stashed_xsave,0 , xbuf_size); + +if (ptrace (PTRACE_GETREGSET , target, (uint32_t )NT_X86_XSTATE , &iov)) +fatal_error ("PTRACE_GETREGSET" ); + +if (!__compare_tiledata_state (stashed_xsave, xbuf)) +printf ("[OK]\tThe init'ed tiledata was read from ptracee.\n" ); +else +printf ("[FAIL]\tThe init'ed tiledata was not read from ptracee.\n" ); + +printf ("\tInject tiledata via ptrace().\n" ); + +load_rand_tiledata (xbuf); + +memcpy (&stashed_xsave->bytes[xtiledata.xbuf_offset], + &xbuf->bytes[xtiledata.xbuf_offset], + xtiledata.size); + +if (ptrace (PTRACE_SETREGSET , target, (uint32_t )NT_X86_XSTATE , &iov)) +fatal_error ("PTRACE_SETREGSET" ); + +if (ptrace (PTRACE_GETREGSET , target, (uint32_t )NT_X86_XSTATE , &iov)) +fatal_error ("PTRACE_GETREGSET" ); + +if (!__compare_tiledata_state (stashed_xsave, xbuf)) +printf ("[OK]\tTiledata was correctly written to ptracee.\n" ); +else +printf ("[FAIL]\tTiledata was not correctly written to ptracee.\n" ); +} + +static void test_ptrace (void ) +{ +pid_t child; +int status; + + child =fork (); +if (child <0 ) { +err (1 ,"fork" ); + }else if (!child) { +if (ptrace (PTRACE_TRACEME ,0 ,NULL ,NULL )) +err (1 ,"PTRACE_TRACEME" ); + +ptracee_firstuse_tiledata (); + +raise (SIGTRAP ); +_exit (0 ); + } + +do { +wait (&status); + }while (WSTOPSIG (status) !=SIGTRAP ); + +ptracer_inject_tiledata (child); + +ptrace (PTRACE_DETACH , child,NULL ,NULL ); +wait (&status); +if (!WIFEXITED (status) ||WEXITSTATUS (status)) +err (1 ,"ptrace test" ); +} +int main (void ) {/* Check hardware availability at first */
@@ -846,6 +946,8 @@ int main(void) ctxtswtest_config.num_threads =5 ;test_context_switch (); +test_ptrace (); +clearhandler (SIGILL );free_stashed_xsave ();
Greg Kroah-Hartman
maintainerPATCH 159/224 scsi: core: Add BLIST_SKIP_VPD_PAGES for SKhynix H28U74301AMR
In reply to Greg Kroah-HartmanFrom: Joel Selvaraj <[email protected]>
commit a204b490595de71016b2360a1886ec8c12d0afac upstream.
Xiaomi Poco F1 (qcom/sdm845-xiaomi-beryllium*.dts) comes with a SKhynix H28U74301AMR UFS. The sd_read_cpr() operation leads to a 120 second timeout, making the device bootup very slow:
[ 121.457736] sd 0:0:0:1: [sdb] tag#23 timing out command, waited 120s
Setting the BLIST_SKIP_VPD_PAGES allows the device to skip the failing sd_read_cpr operation and boot normally.
--- drivers/scsi/scsi_devinfo.c | 1 + 1 file changed, 1 insertion(+)
drivers/scsi/scsi_devinfo.c +1 -0
@@ -234,6 +234,7 @@ static struct { {"SGI", "RAID5", "*", BLIST_SPARSELUN}, {"SGI", "TP9100", "*", BLIST_REPORTLUN2}, {"SGI", "Universal Xport", "*", BLIST_NO_ULD_ATTACH}, + {"SKhynix", "H28U74301AMR", NULL, BLIST_SKIP_VPD_PAGES}, {"IBM", "Universal Xport", "*", BLIST_NO_ULD_ATTACH}, {"SUN", "Universal Xport", "*", BLIST_NO_ULD_ATTACH}, {"DELL", "Universal Xport", "*", BLIST_NO_ULD_ATTACH},
Greg Kroah-Hartman
maintainerPATCH 160/224 usb: misc: onboard-hub: add support for Microchip USB2517 USB 2.0 hub
In reply to Greg Kroah-HartmanFrom: Alexander Stein <[email protected]>
commit f7c13cb48e85538709850589b496c4ddb3d3898e upstream.
Add support for Microchip USB2517 USB 2.0 hub to the onboard usb hub driver. Adopt the generic usb-device compatible ("usbVID,PID"). This hub has the same reset timings as USB2514, so reuse that one. There is also an USB2517I which just has industrial temperature range.
--- drivers/usb/misc/onboard_usb_hub.c | 1 + drivers/usb/misc/onboard_usb_hub.h | 1 + 2 files changed, 2 insertions(+)
drivers/usb/misc/onboard_usb_hub.c +1 -0
@@ -406,6 +406,7 @@ static void onboard_hub_usbdev_disconnecstatic const struct usb_device_id onboard_hub_id_table[] = { {USB_DEVICE (VENDOR_ID_MICROCHIP ,0x2514 ) },/* USB2514B USB 2.0 */ + {USB_DEVICE (VENDOR_ID_MICROCHIP ,0x2517 ) },/* USB2517 USB 2.0 */ {USB_DEVICE (VENDOR_ID_REALTEK ,0x0411 ) },/* RTS5411 USB 3.1 */ {USB_DEVICE (VENDOR_ID_REALTEK ,0x5411 ) },/* RTS5411 USB 2.1 */ {USB_DEVICE (VENDOR_ID_REALTEK ,0x0414 ) },/* RTS5414 USB 3.2 */
drivers/usb/misc/onboard_usb_hub.h +1 -0
@@ -24,6 +24,7 @@ static const struct onboard_hub_pdata tistatic const struct of_device_id onboard_hub_match[] = { { .compatible ="usb424,2514" , .data = µchip_usb424_data, }, + { .compatible ="usb424,2517" , .data = µchip_usb424_data, }, { .compatible ="usb451,8140" , .data = &ti_tusb8041_data, }, { .compatible ="usb451,8142" , .data = &ti_tusb8041_data, }, { .compatible ="usbbda,411" , .data = &realtek_rts5411_data, },
Greg Kroah-Hartman
maintainerPATCH 161/224 usb: dwc2: drd: fix inconsistent mode if role-switch-default-mode="host"
In reply to Greg Kroah-HartmanFrom: Ziyang Huang <[email protected]>
commit 82f5332d3b9872ab5b287e85c57b76d8bb640cd1 upstream.
Some boards might use USB-A female connector for USB ports, however, the port could be connected to a dual-mode USB controller, making it also behaves as a peripheral device if male-to-male cable is connected.
In this case, the dts looks like this:
&usb0 {
status = "okay";
dr_mode = "otg";
usb-role-switch;
role-switch-default-mode = "host";
};After boot, dwc2_ovr_init() sets GOTGCTL to GOTGCTL_AVALOVAL and call dwc2_force_mode() with parameter host=false, which causes inconsistent mode - The hardware is in peripheral mode while the kernel status is in host mode.
What we can do now is to call dwc2_drd_role_sw_set() to switch to device mode, and everything should work just fine now, even switching back to none(default) mode afterwards.
--- drivers/usb/dwc2/drd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/dwc2/drd.c +2 -1
@@ -35,7 +35,8 @@ static void dwc2_ovr_init(struct dwc2_hsspin_unlock_irqrestore (&hsotg->lock, flags); -dwc2_force_mode (hsotg, (hsotg->dr_mode ==USB_DR_MODE_HOST )); +dwc2_force_mode (hsotg, (hsotg->dr_mode ==USB_DR_MODE_HOST ) || + (hsotg->role_sw_default_mode ==USB_DR_MODE_HOST )); }static int dwc2_ovr_avalid (struct dwc2_hsotg *hsotg,bool valid)
Greg Kroah-Hartman
maintainerPATCH 162/224 usb: dwc2: fix a devres leak in hw_enable upon suspend resume
In reply to Greg Kroah-HartmanFrom: Fabrice Gasnier <[email protected]>
commit f747313249b74f323ddf841a9c8db14d989f296a upstream.
Each time the platform goes to low power, PM suspend / resume routines
call: __dwc2_lowlevel_hw_enable -> devm_add_action_or_reset(). This adds a new devres each time.
This may also happen at runtime, as dwc2_lowlevel_hw_enable() can be called from udc_start().
This can be seen with tracing:
- echo 1 > /sys/kernel/debug/tracing/events/dev/devres_log/enable
- go to low power
- cat /sys/kernel/debug/tracing/trace
A new "ADD" entry is found upon each low power cycle:
... devres_log: 49000000.usb-otg ADD 82a13bba devm_action_release (8 bytes) ... devres_log: 49000000.usb-otg ADD 49889daf devm_action_release (8 bytes)
...
A second issue is addressed here:
- regulator_bulk_enable() is called upon each PM cycle (suspend/resume).
- regulator_bulk_disable() never gets called.
So the reference count for these regulators constantly increase, by one upon each low power cycle, due to missing regulator_bulk_disable() call in __dwc2_lowlevel_hw_disable().
The original fix that introduced the devm_add_action_or_reset() call, fixed an issue during probe, that happens due to other errors in dwc2_driver_probe() -> dwc2_core_reset(). Then the probe fails without disabling regulators, when dr_mode == USB_DR_MODE_PERIPHERAL.
Rather fix the error path: disable all the low level hardware in the error path, by using the "hsotg->ll_hw_enabled" flag. Checking dr_mode has been introduced to avoid a dual call to dwc2_lowlevel_hw_disable(). "ll_hw_enabled" should achieve the same (and is used currently in the remove() routine).
--- drivers/usb/dwc2/platform.c | 16 ++-------------- 1 file changed, 2 insertions(+), 14 deletions(-)
drivers/usb/dwc2/platform.c +2 -14
@@ -91,13 +91,6 @@ static int dwc2_get_dr_mode(struct dwc2_return 0 ; } -static void __dwc2_disable_regulators (void *data) -{ -struct dwc2_hsotg *hsotg = data; - -regulator_bulk_disable (ARRAY_SIZE (hsotg->supplies), hsotg->supplies); -} -static int __dwc2_lowlevel_hw_enable (struct dwc2_hsotg *hsotg) {struct platform_device *pdev =to_platform_device (hsotg->dev);
@@ -108,11 +101,6 @@ static int __dwc2_lowlevel_hw_enable(strif (ret)return ret; - ret =devm_add_action_or_reset (&pdev->dev, - __dwc2_disable_regulators, hsotg); -if (ret) -return ret; -if (hsotg->clk) { ret =clk_prepare_enable (hsotg->clk);if (ret)
@@ -168,7 +156,7 @@ static int __dwc2_lowlevel_hw_disable(stif (hsotg->clk)clk_disable_unprepare (hsotg->clk); -return 0 ; +return regulator_bulk_disable (ARRAY_SIZE (hsotg->supplies), hsotg->supplies); }/**
@@ -607,7 +595,7 @@ error_init:if (hsotg->params.activate_stm_id_vb_detection)regulator_disable (hsotg->usb33d); error: -if (hsotg->dr_mode !=USB_DR_MODE_PERIPHERAL ) +if (hsotg->ll_hw_enabled)dwc2_lowlevel_hw_disable (hsotg);return retval; }
Greg Kroah-Hartman
maintainerPATCH 163/224 usb: gadget: u_audio: dont let userspace block driver unbind
In reply to Greg Kroah-HartmanFrom: Alvin Šipraga <[email protected]>
commit 6c67ed9ad9b83e453e808f9b31a931a20a25629b upstream.
In the unbind callback for f_uac1 and f_uac2, a call to snd_card_free() via g_audio_cleanup() will disconnect the card and then wait for all resources to be released, which happens when the refcount falls to zero. Since userspace can keep the refcount incremented by not closing the relevant file descriptor, the call to unbind may block indefinitely. This can cause a deadlock during reboot, as evidenced by the following blocked task observed on my machine:
task:reboot state:D stack:0 pid:2827 ppid:569 flags:0x0000000c
Call trace: __switch_to+0xc8/0x140 __schedule+0x2f0/0x7c0 schedule+0x60/0xd0 schedule_timeout+0x180/0x1d4 wait_for_completion+0x78/0x180 snd_card_free+0x90/0xa0 g_audio_cleanup+0x2c/0x64 afunc_unbind+0x28/0x60 ... kernel_restart+0x4c/0xac __do_sys_reboot+0xcc/0x1ec __arm64_sys_reboot+0x28/0x30 invoke_syscall+0x4c/0x110 ...
The issue can also be observed by opening the card with arecord and then stopping the process through the shell before unbinding:
# arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null Recording WAVE '/dev/null' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo ^Z[1]+ Stopped arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null # echo gadget.0 > /sys/bus/gadget/drivers/configfs-gadget/unbind (observe that the unbind command never finishes)
Fix the problem by using snd_card_free_when_closed() instead, which will still disconnect the card as desired, but defer the task of freeing the resources to the core once userspace closes its file descriptor.
--- drivers/usb/gadget/function/u_audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/function/u_audio.c +1 -1
@@ -1422,7 +1422,7 @@ void g_audio_cleanup(struct g_audio *g_a uac = g_audio->uac; card = uac->card;if (card) -snd_card_free (card); +snd_card_free_when_closed (card);kfree (uac->p_prm.reqs);kfree (uac->c_prm.reqs);
Greg Kroah-Hartman
maintainerPATCH 164/224 btrfs: zoned: fix btrfs_can_activate_zone() to support DUP profile
In reply to Greg Kroah-HartmanFrom: Naohiro Aota <[email protected]>
commit 9e1cdf0c354e46e428c0e0cab008abbe81b6013d upstream.
btrfs_can_activate_zone() returns true if at least one device has one zone available for activation. This is OK for the single profile, but not OK for DUP profile. We need two zones to create a DUP block group. Fix it by properly handling the case with the profile flags.
--- fs/btrfs/zoned.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
fs/btrfs/zoned.c +12 -2
@@ -2113,11 +2113,21 @@ bool btrfs_can_activate_zone(struct btrfif (!device->bdev)continue ; -if (!zinfo->max_active_zones || -atomic_read (&zinfo->active_zones_left)) { +if (!zinfo->max_active_zones) { ret = true;break ; } + +switch (flags &BTRFS_BLOCK_GROUP_PROFILE_MASK ) { +case 0 :/* single */ + ret = (atomic_read (&zinfo->active_zones_left) >=1 ); +break ; +case BTRFS_BLOCK_GROUP_DUP : + ret = (atomic_read (&zinfo->active_zones_left) >=2 ); +break ; + } +if (ret) +break ; }mutex_unlock (&fs_info->chunk_mutex);
Greg Kroah-Hartman
maintainerPATCH 165/224 Bluetooth: Fix race condition in hci_cmd_sync_clear
In reply to Greg Kroah-HartmanFrom: Min Li <[email protected]>
commit 1c66bee492a5fe00ae3fe890bb693bfc99f994c6 upstream.
There is a potential race condition in hci_cmd_sync_work and hci_cmd_sync_clear, and could lead to use-after-free. For instance, hci_cmd_sync_work is added to the 'req_workqueue' after cancel_work_sync The entry of 'cmd_sync_work_list' may be freed in hci_cmd_sync_clear, and causing kernel panic when it is used in 'hci_cmd_sync_work'.
Here's the call trace:
dump_stack_lvl+0x49/0x63 print_report.cold+0x5e/0x5d3 ? hci_cmd_sync_work+0x282/0x320 kasan_report+0xaa/0x120 ? hci_cmd_sync_work+0x282/0x320 __asan_report_load8_noabort+0x14/0x20 hci_cmd_sync_work+0x282/0x320 process_one_work+0x77b/0x11c0 ? _raw_spin_lock_irq+0x8e/0xf0 worker_thread+0x544/0x1180 ? poll_idle+0x1e0/0x1e0 kthread+0x285/0x320 ? process_one_work+0x11c0/0x11c0 ? kthread_complete_and_exit+0x30/0x30 ret_from_fork+0x22/0x30 </TASK> Allocated by task 266: kasan_save_stack+0x26/0x50 __kasan_kmalloc+0xae/0xe0 kmem_cache_alloc_trace+0x191/0x350 hci_cmd_sync_queue+0x97/0x2b0 hci_update_passive_scan+0x176/0x1d0 le_conn_complete_evt+0x1b5/0x1a00 hci_le_conn_complete_evt+0x234/0x340 hci_le_meta_evt+0x231/0x4e0 hci_event_packet+0x4c5/0xf00 hci_rx_work+0x37d/0x880 process_one_work+0x77b/0x11c0 worker_thread+0x544/0x1180 kthread+0x285/0x320 ret_from_fork+0x22/0x30 Freed by task 269: kasan_save_stack+0x26/0x50 kasan_set_track+0x25/0x40 kasan_set_free_info+0x24/0x40 ____kasan_slab_free+0x176/0x1c0 __kasan_slab_free+0x12/0x20 slab_free_freelist_hook+0x95/0x1a0 kfree+0xba/0x2f0 hci_cmd_sync_clear+0x14c/0x210 hci_unregister_dev+0xff/0x440 vhci_release+0x7b/0xf0 __fput+0x1f3/0x970 ____fput+0xe/0x20 task_work_run+0xd4/0x160 do_exit+0x8b0/0x22a0 do_group_exit+0xba/0x2a0 get_signal+0x1e4a/0x25b0 arch_do_signal_or_restart+0x93/0x1f80 exit_to_user_mode_prepare+0xf5/0x1a0 syscall_exit_to_user_mode+0x26/0x50 ret_from_fork+0x15/0x30
--- net/bluetooth/hci_sync.c | 2 ++ 1 file changed, 2 insertions(+)
net/bluetooth/hci_sync.c +2 -0
@@ -643,6 +643,7 @@ void hci_cmd_sync_clear(struct hci_dev *cancel_work_sync (&hdev->cmd_sync_work);cancel_work_sync (&hdev->reenable_adv_work); +mutex_lock (&hdev->cmd_sync_work_lock);list_for_each_entry_safe (entry, tmp, &hdev->cmd_sync_work_list, list) {if (entry->destroy) entry->destroy (hdev, entry->data, -ECANCELED );
@@ -650,6 +651,7 @@ void hci_cmd_sync_clear(struct hci_dev *list_del (&entry->list);kfree (entry); } +mutex_unlock (&hdev->cmd_sync_work_lock); }void __hci_cmd_sync_cancel (struct hci_dev *hdev,int err)
Greg Kroah-Hartman
maintainerPATCH 166/224 efi: sysfb_efi: Fix DMI quirks not working for simpledrm
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
commit 3615c78673c332b69aaacefbcde5937c5c706686 upstream.
Commit 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") moved the sysfb_apply_efi_quirks() call in sysfb_init() from before the [sysfb_]parse_mode() call to after it.
But sysfb_apply_efi_quirks() modifies the global screen_info struct which [sysfb_]parse_mode() parses, so doing it later is too late.
This has broken all DMI based quirks for correcting wrong firmware efifb settings when simpledrm is used.
To fix this move the sysfb_apply_efi_quirks() call back to its old place and split the new setup of the efifb_fwnode (which requires the platform_device) into its own function and call that at the place of the moved sysfb_apply_efi_quirks(pd) calls.
--- drivers/firmware/efi/sysfb_efi.c | 5 ++++- drivers/firmware/sysfb.c | 4 +++- drivers/firmware/sysfb_simplefb.c | 2 +- include/linux/sysfb.h | 9 +++++++-- 4 files changed, 15 insertions(+), 5 deletions(-)
drivers/firmware/efi/sysfb_efi.c +4 -1
@@ -341,7 +341,7 @@ static const struct fwnode_operations ef#ifdef CONFIG_EFI static struct fwnode_handle efifb_fwnode; -__init void sysfb_apply_efi_quirks (struct platform_device *pd) +__init void sysfb_apply_efi_quirks (void ) {if (screen_info.orig_video_isVGA !=VIDEO_TYPE_EFI || !(screen_info.capabilities &VIDEO_CAPABILITY_SKIP_QUIRKS ))
@@ -355,7 +355,10 @@ __init void sysfb_apply_efi_quirks(struc screen_info.lfb_height = temp; screen_info.lfb_linelength =4 * screen_info.lfb_width; } +} +__init void sysfb_set_efifb_fwnode (struct platform_device *pd) +{if (screen_info.orig_video_isVGA ==VIDEO_TYPE_EFI &&IS_ENABLED (CONFIG_PCI )) {fwnode_init (&efifb_fwnode, &efifb_fwnode_ops); pd->dev.fwnode = &efifb_fwnode;
drivers/firmware/sysfb.c +3 -1
@@ -81,6 +81,8 @@ static __init int sysfb_init(void)if (disabled) goto unlock_mutex; +sysfb_apply_efi_quirks (); +/* try to create a simple-framebuffer device */ compatible =sysfb_parse_mode (si, &mode);if (compatible) {
@@ -107,7 +109,7 @@ static __init int sysfb_init(void) goto unlock_mutex; } -sysfb_apply_efi_quirks (pd); +sysfb_set_efifb_fwnode (pd); ret =platform_device_add_data (pd, si,sizeof (*si));if (ret)
drivers/firmware/sysfb_simplefb.c +1 -1
@@ -110,7 +110,7 @@ __init struct platform_device *sysfb_creif (!pd)return ERR_PTR (-ENOMEM ); -sysfb_apply_efi_quirks (pd); +sysfb_set_efifb_fwnode (pd); ret =platform_device_add_resources (pd, &res,1 );if (ret)
include/linux/sysfb.h +7 -2
@@ -70,11 +70,16 @@ static inline void sysfb_disable(void)#ifdef CONFIG_EFI extern struct efifb_dmi_info efifb_dmi_list[]; -void sysfb_apply_efi_quirks (struct platform_device *pd); +void sysfb_apply_efi_quirks (void ); +void sysfb_set_efifb_fwnode (struct platform_device *pd);#else /* CONFIG_EFI */ -static inline void sysfb_apply_efi_quirks (struct platform_device *pd) +static inline void sysfb_apply_efi_quirks (void ) +{ +} + +static inline void sysfb_set_efifb_fwnode (struct platform_device *pd) { }
Greg Kroah-Hartman
maintainerPATCH 167/224 mm/slab: Fix undefined init_cache_node_node() for NUMA and !SMP
In reply to Greg Kroah-HartmanFrom: Geert Uytterhoeven <[email protected]>
commit 66a1c22b709178e7b823d44465d0c2e5ed7492fb upstream.
sh/migor_defconfig:
mm/slab.c: In function ‘slab_memory_callback’:
mm/slab.c:1127:23: error: implicit declaration of function ‘init_cache_node_node’; did you mean ‘drain_cache_node_node’? [-Werror=implicit-function-declaration]
1127 | ret = init_cache_node_node(nid);
| ^~~~~~~~~~~~~~~~~~~~
| drain_cache_node_node
The #ifdef condition protecting the definition of init_cache_node_node() no longer matches the conditions protecting the (multiple) users.
Fix this by syncing the conditions.
--- mm/slab.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/slab.c +1 -1
@@ -840,7 +840,7 @@ static int init_cache_node(struct kmem_creturn 0 ; } -#if (defined(CONFIG_NUMA ) && defined(CONFIG_MEMORY_HOTPLUG )) || defined(CONFIG_SMP ) +#if defined(CONFIG_NUMA ) || defined(CONFIG_SMP )/* * Allocates and initializes node for a node on each slab cache, used for * either memory or cpu hotplug. If memory is being hot-added, the kmem_cache_node
Greg Kroah-Hartman
maintainerPATCH 168/224 fscrypt: destroy keyring after security_sb_delete()
In reply to Greg Kroah-HartmanFrom: Eric Biggers <[email protected]>
commit ccb820dc7d2236b1af0d54ae038a27b5b6d5ae5a upstream.
fscrypt_destroy_keyring() must be called after all potentially-encrypted inodes were evicted; otherwise it cannot safely destroy the keyring. Since inodes that are in-use by the Landlock LSM don't get evicted until security_sb_delete(), this means that fscrypt_destroy_keyring() must be called *after* security_sb_delete().
This fixes a WARN_ON followed by a NULL dereference, only possible if Landlock was being used on encrypted files.
--- fs/super.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
fs/super.c +12 -3
@@ -476,13 +476,22 @@ void generic_shutdown_super(struct supercgroup_writeback_umount (); -/* evict all inodes with zero refcount */ +/* Evict all inodes with zero refcount. */ evict_inodes (sb); -/* only nonzero refcount inodes can have marks */ + +/* +* Clean up and evict any inodes that still have references due +* to fsnotify or the security policy. +*/ fsnotify_sb_delete (sb); -fscrypt_destroy_keyring (sb);security_sb_delete (sb); +/* +* Now that all potentially-encrypted inodes have been evicted, +* the fscrypt keyring can be destroyed. +*/ +fscrypt_destroy_keyring (sb); +if (sb->s_dio_done_wq) {destroy_workqueue (sb->s_dio_done_wq); sb->s_dio_done_wq =NULL ;
Greg Kroah-Hartman
maintainerPATCH 169/224 fsverity: Remove WQ_UNBOUND from fsverity read workqueue
In reply to Greg Kroah-HartmanFrom: Nathan Huckleberry <[email protected]>
commit f959325e6ac3f499450088b8d9c626d1177be160 upstream.
WQ_UNBOUND causes significant scheduler latency on ARM64/Android. This is problematic for latency sensitive workloads, like I/O post-processing.
Removing WQ_UNBOUND gives a 96% reduction in fsverity workqueue related scheduler latency and improves app cold startup times by ~30ms. WQ_UNBOUND was also removed from the dm-verity workqueue for the same reason [1].
This code was tested by running Android app startup benchmarks and measuring how long the fsverity workqueue spent in the runnable state.
Before
Total workqueue scheduler latency: 553800us
After
Total workqueue scheduler latency: 18962us
[1]: https://lore.kernel.org/all/[email protected]/
--- fs/verity/verify.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)
fs/verity/verify.c +6 -6
@@ -269,15 +269,15 @@ EXPORT_SYMBOL_GPL(fsverity_enqueue_verifint __init fsverity_init_workqueue (void ) {/* -* Use an unbound workqueue to allow bios to be verified in parallel -* even when they happen to complete on the same CPU. This sacrifices -* locality, but it's worthwhile since hashing is CPU-intensive. +* Use a high-priority workqueue to prioritize verification work, which +* blocks reads from completing, over regular application tasks. * -* Also use a high-priority workqueue to prioritize verification work, -* which blocks reads from completing, over regular application tasks. +* For performance reasons, don't use an unbound workqueue. Using an +* unbound workqueue for crypto operations causes excessive scheduler +* latency on ARM64. */ fsverity_read_workqueue =alloc_workqueue ("fsverity_read_queue" , -WQ_UNBOUND |WQ_HIGHPRI , +WQ_HIGHPRI ,num_online_cpus ());if (!fsverity_read_workqueue)return -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 170/224 lockd: set file_lock start and end when decoding nlm4 testargs
In reply to Greg Kroah-HartmanFrom: Jeff Layton <[email protected]>
commit 7ff84910c66c9144cc0de9d9deed9fb84c03aff0 upstream.
Commit 6930bcbfb6ce dropped the setting of the file_lock range when decoding a nlm_lock off the wire. This causes the client side grant callback to miss matching blocks and reject the lock, only to rerequest it 30s later.
Add a helper function to set the file_lock range from the start and end values that the protocol uses, and have the nlm_lock decoder call that to set up the file_lock args properly.
--- fs/lockd/clnt4xdr.c | 9 +-------- fs/lockd/xdr4.c | 13 ++++++++++++- include/linux/lockd/xdr4.h | 1 + 3 files changed, 14 insertions(+), 9 deletions(-)
fs/lockd/clnt4xdr.c +1 -8
@@ -261,7 +261,6 @@ static int decode_nlm4_holder(struct xdru32 exclusive;int error;__be32 *p; -s32 end;memset (lock,0 ,sizeof (*lock));locks_init_lock (fl);
@@ -285,13 +284,7 @@ static int decode_nlm4_holder(struct xdr fl->fl_type = exclusive !=0 ?F_WRLCK :F_RDLCK ; p =xdr_decode_hyper (p, &l_offset);xdr_decode_hyper (p, &l_len); - end = l_offset + l_len -1 ; - - fl->fl_start = (loff_t )l_offset; -if (l_len ==0 || end <0 ) - fl->fl_end =OFFSET_MAX ; -else - fl->fl_end = (loff_t )end; +nlm4svc_set_file_lock_range (fl, l_offset, l_len); error =0 ; out:return error;
fs/lockd/xdr4.c +12 -1
@@ -33,6 +33,17 @@ loff_t_to_s64(loff_t offset)return res; } +void nlm4svc_set_file_lock_range (struct file_lock *fl,u64 off,u64 len) +{ +s64 end = off + len -1 ; + + fl->fl_start = off; +if (len ==0 || end <0 ) + fl->fl_end =OFFSET_MAX ; +else + fl->fl_end = end; +} +/* * NLM file handles are defined by specification to be a variable-length * XDR opaque no longer than 1024 bytes. However, this implementation
@@ -80,7 +91,7 @@ svcxdr_decode_lock(struct xdr_stream *xdlocks_init_lock (fl); fl->fl_flags =FL_POSIX ; fl->fl_type =F_RDLCK ; - +nlm4svc_set_file_lock_range (fl, lock->lock_start, lock->lock_len);return true; }
include/linux/lockd/xdr4.h +1 -0
@@ -22,6 +22,7 @@#define nlm4_fbig cpu_to_be32(NLM_FBIG)#define nlm4_failed cpu_to_be32(NLM_FAILED) +void nlm4svc_set_file_lock_range (struct file_lock *fl,u64 off,u64 len);bool nlm4svc_decode_void (struct svc_rqst *rqstp,struct xdr_stream *xdr);bool nlm4svc_decode_testargs (struct svc_rqst *rqstp,struct xdr_stream *xdr);bool nlm4svc_decode_lockargs (struct svc_rqst *rqstp,struct xdr_stream *xdr);
Greg Kroah-Hartman
maintainerPATCH 171/224 arm64: dts: imx8mm-nitrogen-r2: fix WM8960 clock name
In reply to Greg Kroah-HartmanFrom: Krzysztof Kozlowski <[email protected]>
commit 32f86da7c86b27ebed31c24453a0713f612e43fb upstream.
The WM8960 Linux driver expects the clock to be named "mclk". Otherwise the clock will be ignored and not prepared/enabled by the driver.
--- arch/arm64/boot/dts/freescale/imx8mm-nitrogen-r2.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/freescale/imx8mm-nitrogen-r2.dts +1 -1
@@ -247,7 +247,7 @@ compatible = "wlf,wm8960"; reg = <0x1a>; clocks = <&clk IMX8MM_CLK_SAI1_ROOT>; - clock-names = "mclk1"; + clock-names = "mclk"; wlf,shared-lrclk; #sound-dai-cells = <0>; };
Greg Kroah-Hartman
maintainerPATCH 172/224 igb: revert rtnl_lock() that causes deadlock
In reply to Greg Kroah-HartmanFrom: Lin Ma <[email protected]>
commit 65f69851e44d71248b952a687e44759a7abb5016 upstream.
The commit 6faee3d4ee8b ("igb: Add lock to avoid data race") adds rtnl_lock to eliminate a false data race shown below
(FREE from device detaching) | (USE from netdev core)
igb_remove | igb_ndo_get_vf_config
igb_disable_sriov | vf >= adapter->vfs_allocated_count?
kfree(adapter->vf_data) |
adapter->vfs_allocated_count = 0 |
| memcpy(... adapter->vf_data[vf]The above race will never happen and the extra rtnl_lock causes deadlock below
[ 141.420169] <TASK> [ 141.420672] __schedule+0x2dd/0x840 [ 141.421427] schedule+0x50/0xc0 [ 141.422041] schedule_preempt_disabled+0x11/0x20 [ 141.422678] __mutex_lock.isra.13+0x431/0x6b0 [ 141.423324] unregister_netdev+0xe/0x20 [ 141.423578] igbvf_remove+0x45/0xe0 [igbvf] [ 141.423791] pci_device_remove+0x36/0xb0 [ 141.423990] device_release_driver_internal+0xc1/0x160 [ 141.424270] pci_stop_bus_device+0x6d/0x90 [ 141.424507] pci_stop_and_remove_bus_device+0xe/0x20 [ 141.424789] pci_iov_remove_virtfn+0xba/0x120 [ 141.425452] sriov_disable+0x2f/0xf0 [ 141.425679] igb_disable_sriov+0x4e/0x100 [igb] [ 141.426353] igb_remove+0xa0/0x130 [igb] [ 141.426599] pci_device_remove+0x36/0xb0 [ 141.426796] device_release_driver_internal+0xc1/0x160 [ 141.427060] driver_detach+0x44/0x90 [ 141.427253] bus_remove_driver+0x55/0xe0 [ 141.427477] pci_unregister_driver+0x2a/0xa0 [ 141.428296] __x64_sys_delete_module+0x141/0x2b0 [ 141.429126] ? mntput_no_expire+0x4a/0x240 [ 141.429363] ? syscall_trace_enter.isra.19+0x126/0x1a0 [ 141.429653] do_syscall_64+0x5b/0x80 [ 141.429847] ? exit_to_user_mode_prepare+0x14d/0x1c0 [ 141.430109] ? syscall_exit_to_user_mode+0x12/0x30 [ 141.430849] ? do_syscall_64+0x67/0x80 [ 141.431083] ? syscall_exit_to_user_mode_prepare+0x183/0x1b0 [ 141.431770] ? syscall_exit_to_user_mode+0x12/0x30 [ 141.432482] ? do_syscall_64+0x67/0x80 [ 141.432714] ? exc_page_fault+0x64/0x140 [ 141.432911] entry_SYSCALL_64_after_hwframe+0x72/0xdc
Since the igb_disable_sriov() will call pci_disable_sriov() before releasing any resources, the netdev core will synchronize the cleanup to avoid any races. This patch removes the useless rtnl_(un)lock to guarantee correctness.
--- drivers/net/ethernet/intel/igb/igb_main.c | 2 -- 1 file changed, 2 deletions(-)
drivers/net/ethernet/intel/igb/igb_main.c +0 -2
@@ -3841,9 +3841,7 @@ static void igb_remove(struct pci_dev *pigb_release_hw_control (adapter);#ifdef CONFIG_PCI_IOV -rtnl_lock ();igb_disable_sriov (pdev); -rtnl_unlock ();#endif unregister_netdev (netdev);
Greg Kroah-Hartman
maintainerPATCH 173/224 dm thin: fix deadlock when swapping to thin device
In reply to Greg Kroah-HartmanFrom: Coly Li <[email protected]>
commit 9bbf5feecc7eab2c370496c1c161bbfe62084028 upstream.
This is an already known issue that dm-thin volume cannot be used as swap, otherwise a deadlock may happen when dm-thin internal memory demand triggers swap I/O on the dm-thin volume itself.
But thanks to commit a666e5c05e7c ("dm: fix deadlock when swapping to encrypted device"), the limit_swap_bios target flag can also be used for dm-thin to avoid the recursive I/O when it is used as swap.
Fix is to simply set ti->limit_swap_bios to true in both pool_ctr() and thin_ctr().
In my test, I create a dm-thin volume /dev/vg/swap and use it as swap device. Then I run fio on another dm-thin volume /dev/vg/main and use large --blocksize to trigger swap I/O onto /dev/vg/swap.
The following fio command line is used in my test,
fio --name recursive-swap-io --lockmem 1 --iodepth 128 \
--ioengine libaio --filename /dev/vg/main --rw randrw \
--blocksize 1M --numjobs 32 --time_based --runtime=12hWithout this fix, the whole system can be locked up within 15 seconds.
With this fix, there is no any deadlock or hung task observed after 2 hours of running fio.
Furthermore, if blocksize is changed from 1M to 128M, after around 30 seconds fio has no visible I/O, and the out-of-memory killer message shows up in kernel message. After around 20 minutes all fio processes are killed and the whole system is back to being alive.
This is exactly what is expected when recursive I/O happens on dm-thin volume when it is used as swap.
Depends-on: a666e5c05e7c ("dm: fix deadlock when swapping to encrypted device")
--- drivers/md/dm-thin.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/md/dm-thin.c +2 -0
@@ -3357,6 +3357,7 @@ static int pool_ctr(struct dm_target *ti pt->low_water_blocks = low_water_blocks; pt->adjusted_pf = pt->requested_pf = pf; ti->num_flush_bios =1 ; + ti->limit_swap_bios = true;/* * Only need to enable discards if the pool should pass
@@ -4235,6 +4236,7 @@ static int thin_ctr(struct dm_target *ti goto bad; ti->num_flush_bios =1 ; + ti->limit_swap_bios = true; ti->flush_supported = true; ti->accounts_remapped_io = true; ti->per_io_data_size =sizeof (struct dm_thin_endio_hook );
Greg Kroah-Hartman
maintainerPATCH 174/224 usb: typec: tcpm: fix create duplicate source-capabilities file
In reply to Greg Kroah-HartmanFrom: Xu Yang <[email protected]>
commit a826492fc9dfe32afd70fff93955ae8174bbf14b upstream.
The kernel will dump in the below cases:
sysfs: cannot create duplicate filename '/devices/virtual/usb_power_delivery/pd1/source-capabilities'
1. After soft reset has completed, an Explicit Contract negotiation occurs. The sink device will receive source capabilitys again. This will cause a duplicate source-capabilities file be created.
2. Power swap twice on a device that is initailly sink role.
This will unregister existing capabilities when above cases occurs.
--- drivers/usb/typec/tcpm/tcpm.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/usb/typec/tcpm/tcpm.c +9 -0
@@ -4547,6 +4547,9 @@ static void run_state_machine(struct tcpcase SOFT_RESET : port->message_id =0 ; port->rx_msgid =-1 ; +/* remove existing capabilities */ +usb_power_delivery_unregister_capabilities (port->partner_source_caps); + port->partner_source_caps =NULL ;tcpm_pd_send_control (port,PD_CTRL_ACCEPT );tcpm_ams_finish (port);if (port->pwr_role ==TYPEC_SOURCE ) {
@@ -4566,6 +4569,9 @@ static void run_state_machine(struct tcpcase SOFT_RESET_SEND : port->message_id =0 ; port->rx_msgid =-1 ; +/* remove existing capabilities */ +usb_power_delivery_unregister_capabilities (port->partner_source_caps); + port->partner_source_caps =NULL ;if (tcpm_pd_send_control (port,PD_CTRL_SOFT_RESET ))tcpm_set_state_cond (port,hard_reset_state (port),0 );else
@@ -4695,6 +4701,9 @@ static void run_state_machine(struct tcptcpm_set_state (port,SNK_STARTUP ,0 );break ;case PR_SWAP_SNK_SRC_SINK_OFF : +/* will be source, remove existing capabilities */ +usb_power_delivery_unregister_capabilities (port->partner_source_caps); + port->partner_source_caps =NULL ;/* * Prevent vbus discharge circuit from turning on during PR_SWAP * as this is not a disconnect.
Greg Kroah-Hartman
maintainerPATCH 175/224 usb: typec: tcpm: fix warning when handle discover_identity message
In reply to Greg Kroah-HartmanFrom: Xu Yang <[email protected]>
commit abfc4fa28f0160df61c7149567da4f6494dfb488 upstream.
Since both source and sink device can send discover_identity message in PD3, kernel may dump below warning:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 169 at drivers/usb/typec/tcpm/tcpm.c:1446 tcpm_queue_vdm+0xe0/0xf0 Modules linked in: CPU: 0 PID: 169 Comm: 1-0050 Not tainted 6.1.1-00038-g6a3c36cf1da2-dirty #567 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : tcpm_queue_vdm+0xe0/0xf0 lr : tcpm_queue_vdm+0x2c/0xf0
sp : ffff80000c19bcd0
x29: ffff80000c19bcd0 x28: 0000000000000001 x27: ffff0000d11c8ab8
x26: ffff0000d11cc000 x25: 0000000000000000 x24: 00000000ff008081
x23: 0000000000000001 x22: 00000000ff00a081 x21: ffff80000c19bdbc
x20: 0000000000000000 x19: ffff0000d11c8080 x18: ffffffffffffffff
x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000d716f580
x14: 0000000000000001 x13: ffff0000d716f507 x12: 0000000000000001
x11: 0000000000000000 x10: 0000000000000020 x9 : 00000000000ee098 x8 : 00000000ffffffff x7 : 000000000000001c x6 : ffff0000d716f580 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff80000c19bdbc x1 : 00000000ff00a081 x0 : 0000000000000004
Call trace: tcpm_queue_vdm+0xe0/0xf0 tcpm_pd_rx_handler+0x340/0x1ab0 kthread_worker_fn+0xcc/0x18c kthread+0x10c/0x110 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]---
Below sequences may trigger this warning:
tcpm_send_discover_work(work)
tcpm_send_vdm(port, USB_SID_PD, CMD_DISCOVER_IDENT, NULL, 0);
tcpm_queue_vdm(port, header, data, count);
port->vdm_state = VDM_STATE_READY;vdm_state_machine_work(work);
<-- received discover_identity from partner
vdm_run_state_machine(port);
port->vdm_state = VDM_STATE_SEND_MESSAGE;
mod_vdm_delayed_work(port, x);
tcpm_pd_rx_handler(work);
tcpm_pd_data_request(port, msg);
tcpm_handle_vdm_request(port, msg->payload, cnt);
tcpm_queue_vdm(port, response[0], &response[1], rlen - 1);
--> WARN_ON(port->vdm_state > VDM_STATE_DONE);
For this case, the state machine could still send out discover identity message later if we skip current discover_identity message. So we should handle the received message firstly and override the pending discover_identity message without warning in this case. Then, a delayed send_discover work will send discover_identity message again.
--- drivers/usb/typec/tcpm/tcpm.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-)
drivers/usb/typec/tcpm/tcpm.c +15 -4
@@ -1436,10 +1436,18 @@ static int tcpm_ams_start(struct tcpm_postatic void tcpm_queue_vdm (struct tcpm_port *port,const u32 header,const u32 *data,int cnt) { +u32 vdo_hdr = port->vdo_data[0 ]; +WARN_ON (!mutex_is_locked (&port->lock)); -/* Make sure we are not still processing a previous VDM packet */ -WARN_ON (port->vdm_state >VDM_STATE_DONE ); +/* If is sending discover_identity, handle received message first */ +if (PD_VDO_SVDM (vdo_hdr) &&PD_VDO_CMD (vdo_hdr) ==CMD_DISCOVER_IDENT ) { + port->send_discover = true; +mod_send_discover_delayed_work (port,SEND_DISCOVER_RETRY_MS ); + }else { +/* Make sure we are not still processing a previous VDM packet */ +WARN_ON (port->vdm_state >VDM_STATE_DONE ); + } port->vdo_count = cnt +1 ; port->vdo_data[0 ] = header;
@@ -1942,11 +1950,13 @@ static void vdm_run_state_machine(structswitch (PD_VDO_CMD (vdo_hdr)) {case CMD_DISCOVER_IDENT : res =tcpm_ams_start (port,DISCOVER_IDENTITY ); -if (res ==0 ) +if (res ==0 ) { port->send_discover = false; -else if (res == -EAGAIN ) + }else if (res == -EAGAIN ) { + port->vdo_data[0 ] =0 ;mod_send_discover_delayed_work (port,SEND_DISCOVER_RETRY_MS ); + }break ;case CMD_DISCOVER_SVID : res =tcpm_ams_start (port,DISCOVER_SVIDS );
@@ -2029,6 +2039,7 @@ static void vdm_run_state_machine(structunsigned long timeout; port->vdm_retries =0 ; + port->vdo_data[0 ] =0 ; port->vdm_state =VDM_STATE_BUSY ; timeout =vdm_ready_timeout (vdo_hdr);mod_vdm_delayed_work (port, timeout);
Greg Kroah-Hartman
maintainerPATCH 176/224 usb: cdns3: Fix issue with using incorrect PCI device function
In reply to Greg Kroah-HartmanFrom: Pawel Laszczak <[email protected]>
commit 1272fd652a226ccb34e9f47371b6121948048438 upstream.
PCI based platform can have more than two PCI functions. USBSS PCI Glue driver during initialization should consider only DRD/HOST/DEVICE PCI functions and all other should be ignored. This patch adds additional condition which causes that only DRD and HOST/DEVICE function will be accepted.
--- drivers/usb/cdns3/cdns3-pci-wrap.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/usb/cdns3/cdns3-pci-wrap.c +5 -0
@@ -60,6 +60,11 @@ static struct pci_dev *cdns3_get_second_return NULL ; } +if (func->devfn !=PCI_DEV_FN_HOST_DEVICE && + func->devfn !=PCI_DEV_FN_OTG ) { +return NULL ; + } +return func; }
Greg Kroah-Hartman
maintainerPATCH 177/224 usb: cdnsp: Fixes issue with redundant Status Stage
In reply to Greg Kroah-HartmanFrom: Pawel Laszczak <[email protected]>
commit 5bc38d33a5a1209fd4de65101d1ae8255ea12c6e upstream.
In some cases, driver trees to send Status Stage twice. The first one from upper layer of gadget usb subsystem and second time from controller driver.
This patch fixes this issue and remove tricky handling of SET_INTERFACE from controller driver which is no longer needed.
--- drivers/usb/cdns3/cdnsp-ep0.c | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-)
drivers/usb/cdns3/cdnsp-ep0.c +1 -18
@@ -403,20 +403,6 @@ static int cdnsp_ep0_std_request(structcase USB_REQ_SET_ISOCH_DELAY : ret =cdnsp_ep0_set_isoch_delay (pdev, ctrl);break ; -case USB_REQ_SET_INTERFACE : -/* -* Add request into pending list to block sending status stage -* by libcomposite. -*/ -list_add_tail (&pdev->ep0_preq.list, - &pdev->ep0_preq.pep->pending_list); - - ret =cdnsp_ep0_delegate_req (pdev, ctrl); -if (ret == -EBUSY ) - ret =0 ; - -list_del (&pdev->ep0_preq.list); -break ;default : ret =cdnsp_ep0_delegate_req (pdev, ctrl);break ;
@@ -474,9 +460,6 @@ void cdnsp_setup_analyze(struct cdnsp_deelse ret =cdnsp_ep0_delegate_req (pdev, ctrl); -if (!len) - pdev->ep0_stage =CDNSP_STATUS_STAGE ; -if (ret ==USB_GADGET_DELAYED_STATUS ) {trace_cdnsp_ep0_status_stage ("delayed" );return ;
@@ -484,6 +467,6 @@ void cdnsp_setup_analyze(struct cdnsp_de out:if (ret <0 )cdnsp_ep0_stall (pdev); -else if (pdev->ep0_stage ==CDNSP_STATUS_STAGE ) +else if (!len && pdev->ep0_stage !=CDNSP_STATUS_STAGE )cdnsp_status_stage (pdev); }
Greg Kroah-Hartman
maintainerPATCH 178/224 usb: cdnsp: changes PCI Device ID to fix conflict with CNDS3 driver
In reply to Greg Kroah-HartmanFrom: Pawel Laszczak <[email protected]>
commit 96b96b2a567fb34dd41c87e6cf01f6902ce8cae4 upstream.
Patch changes CDNS_DEVICE_ID in USBSSP PCI Glue driver to remove the conflict with Cadence USBSS driver.
--- drivers/usb/cdns3/cdnsp-pci.c | 27 +++++++++++---------------- 1 file changed, 11 insertions(+), 16 deletions(-)
drivers/usb/cdns3/cdnsp-pci.c +11 -16
@@ -29,30 +29,23 @@#define PLAT_DRIVER_NAME "cdns-usbssp"#define CDNS_VENDOR_ID 0x17cd -#define CDNS_DEVICE_ID 0x0100 +#define CDNS_DEVICE_ID 0x0200 +#define CDNS_DRD_ID 0x0100#define CDNS_DRD_IF (PCI_CLASS_SERIAL_USB << 8 | 0x80)static struct pci_dev *cdnsp_get_second_fun (struct pci_dev *pdev) { -struct pci_dev *func; -/* * Gets the second function. -* It's little tricky, but this platform has two function. -* The fist keeps resources for Host/Device while the second -* keeps resources for DRD/OTG. +* Platform has two function. The fist keeps resources for +* Host/Device while the secon keeps resources for DRD/OTG. */ - func =pci_get_device (pdev->vendor, pdev->device,NULL ); -if (!func) -return NULL ; +if (pdev->device ==CDNS_DEVICE_ID ) +return pci_get_device (pdev->vendor,CDNS_DRD_ID ,NULL ); +else if (pdev->device ==CDNS_DRD_ID ) +return pci_get_device (pdev->vendor,CDNS_DEVICE_ID ,NULL ); -if (func->devfn == pdev->devfn) { - func =pci_get_device (pdev->vendor, pdev->device, func); -if (!func) -return NULL ; - } - -return func; +return NULL ; } static int cdnsp_pci_probe(struct pci_dev *pdev,
@@ -232,6 +225,8 @@ static const struct pci_device_id cdnsp_ PCI_CLASS_SERIAL_USB_DEVICE, PCI_ANY_ID }, { PCI_VENDOR_ID_CDNS, CDNS_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID, CDNS_DRD_IF, PCI_ANY_ID }, + { PCI_VENDOR_ID_CDNS, CDNS_DRD_ID, PCI_ANY_ID, PCI_ANY_ID, + CDNS_DRD_IF, PCI_ANY_ID }, { 0, } };
Greg Kroah-Hartman
maintainerPATCH 179/224 usb: chipdea: core: fix return -EINVAL if request role is the same with current role
In reply to Greg Kroah-HartmanFrom: Xu Yang <[email protected]>
commit 3670de80678961eda7fa2220883fc77c16868951 upstream.
It should not return -EINVAL if the request role is the same with current role, return non-error and without do anything instead.
--- drivers/usb/chipidea/core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/usb/chipidea/core.c +4 -1
@@ -977,9 +977,12 @@ static ssize_t role_store(struct device strlen(ci->roles[role]->name)))break ; -if (role ==CI_ROLE_END || role == ci->role) +if (role ==CI_ROLE_END )return -EINVAL ; +if (role == ci->role) +return n; +pm_runtime_get_sync (dev);disable_irq (ci->irq);ci_role_stop (ci);
Greg Kroah-Hartman
maintainerPATCH 180/224 usb: chipidea: core: fix possible concurrent when switch role
In reply to Greg Kroah-HartmanFrom: Xu Yang <[email protected]>
commit 451b15ed138ec15bffbebb58a00ebdd884c3e659 upstream.
The user may call role_store() when driver is handling ci_handle_id_switch() which is triggerred by otg event or power lost event. Unfortunately, the controller may go into chaos in this case. Fix this by protecting it with mutex lock.
--- drivers/usb/chipidea/ci.h | 2 ++ drivers/usb/chipidea/core.c | 8 +++++++- drivers/usb/chipidea/otg.c | 5 ++++- 3 files changed, 13 insertions(+), 2 deletions(-)
drivers/usb/chipidea/ci.h +2 -0
@@ -204,6 +204,7 @@ struct hw_bank {* @in_lpm: if the core in low power mode * @wakeup_int: if wakeup interrupt occur * @rev: The revision number for controller +* @mutex: protect code from concorrent running when doing role switch */ struct ci_hdrc {struct device *dev;
@@ -256,6 +257,7 @@ struct ci_hdrc {bool in_lpm;bool wakeup_int;enum ci_revision rev; +struct mutex mutex; };static inline struct ci_role_driver *ci_role (struct ci_hdrc *ci)
drivers/usb/chipidea/core.c +7 -1
@@ -980,8 +980,12 @@ static ssize_t role_store(struct deviceif (role ==CI_ROLE_END )return -EINVAL ; -if (role == ci->role) +mutex_lock (&ci->mutex); + +if (role == ci->role) { +mutex_unlock (&ci->mutex);return n; + }pm_runtime_get_sync (dev);disable_irq (ci->irq);
@@ -991,6 +995,7 @@ static ssize_t role_store(struct deviceci_handle_vbus_change (ci);enable_irq (ci->irq);pm_runtime_put_sync (dev); +mutex_unlock (&ci->mutex);return (ret ==0 ) ? n : ret; }
@@ -1026,6 +1031,7 @@ static int ci_hdrc_probe(struct platformreturn -ENOMEM ;spin_lock_init (&ci->lock); +mutex_init (&ci->mutex); ci->dev = dev; ci->platdata =dev_get_platdata (dev); ci->imx28_write_fix = !!(ci->platdata->flags &
drivers/usb/chipidea/otg.c +4 -1
@@ -167,8 +167,10 @@ static int hw_wait_vbus_lower_bsv(structstatic void ci_handle_id_switch (struct ci_hdrc *ci) { -enum ci_role role =ci_otg_role (ci); +enum ci_role role; +mutex_lock (&ci->mutex); + role =ci_otg_role (ci);if (role != ci->role) {dev_dbg (ci->dev,"switching from %s to %s\n" ,ci_role (ci)->name, ci->roles[role]->name);
@@ -198,6 +200,7 @@ static void ci_handle_id_switch(struct cif (role ==CI_ROLE_GADGET )ci_handle_vbus_change (ci); } +mutex_unlock (&ci->mutex); }/** * ci_otg_work - perform otg (vbus/id) event handle
Greg Kroah-Hartman
maintainerPATCH 181/224 usb: dwc3: gadget: Add 1ms delay after end transfer command without IOC
In reply to Greg Kroah-HartmanFrom: Wesley Cheng <[email protected]>
commit d8a2bb4eb75866275b5cf7de2e593ac3449643e2 upstream.
Previously, there was a 100uS delay inserted after issuing an end transfer command for specific controller revisions. This was due to the fact that there was a GUCTL2 bit field which enabled synchronous completion of the end transfer command once the CMDACT bit was cleared in the DEPCMD register. Since this bit does not exist for all controller revisions and the current implementation heavily relies on utizling the EndTransfer command completion interrupt, add the delay back in for uses where the interrupt on completion bit is not set, and increase the duration to 1ms for the controller to complete the command.
An issue was seen where the USB request buffer was unmapped while the DWC3 controller was still accessing the TRB. However, it was confirmed that the end transfer command was successfully submitted. (no end transfer timeout) In situations, such as dwc3_gadget_soft_disconnect() and __dwc3_gadget_ep_disable(), the dwc3_remove_request() is utilized, which will issue the end transfer command, and follow up with dwc3_gadget_giveback(). At least for the USB ep disable path, it is required for any pending and started requests to be completed and returned to the function driver in the same context of the disable call. Without the GUCTL2 bit, it is not ensured that the end transfer is completed before the buffers are unmapped.
--- drivers/usb/dwc3/gadget.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
drivers/usb/dwc3/gadget.c +11 -3
@@ -1689,6 +1689,7 @@ static int __dwc3_gadget_get_frame(struc*/ static int __dwc3_stop_active_transfer (struct dwc3_ep *dep,bool force,bool interrupt) { +struct dwc3 *dwc = dep->dwc;struct dwc3_gadget_ep_cmd_params params;u32 cmd;int ret;
@@ -1712,10 +1713,13 @@ static int __dwc3_stop_active_transfer(sWARN_ON_ONCE (ret); dep->resource_index =0 ; -if (!interrupt) +if (!interrupt) { + if (!DWC3_IP_IS(DWC3) || DWC3_VER_IS_PRIOR(DWC3, 310A)) +mdelay (1 ); dep->flags &= ~DWC3_EP_TRANSFER_STARTED ; -else if (!ret) + }else if (!ret) { dep->flags |=DWC3_EP_END_TRANSFER_PENDING ; + } dep->flags &= ~DWC3_EP_DELAY_STOP ;return ret;
@@ -3764,7 +3768,11 @@ void dwc3_stop_active_transfer(struct dw* enabled, the EndTransfer command will have completed upon * returning from this function. * -* This mode is NOT available on the DWC_usb31 IP. +* This mode is NOT available on the DWC_usb31 IP. In this +* case, if the IOC bit is not set, then delay by 1ms +* after issuing the EndTransfer command. This allows for the +* controller to handle the command completely before DWC3 +* remove requests attempts to unmap USB request buffers. */ __dwc3_stop_active_transfer (dep, force, interrupt);
Greg Kroah-Hartman
maintainerPATCH 182/224 usb: ucsi: Fix NULL pointer deref in ucsi_connector_change()
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
commit f87fb985452ab2083967103ac00bfd68fb182764 upstream.
When ucsi_init() fails, ucsi->connector is NULL, yet in case of ucsi_acpi we may still get events which cause the ucs_acpi code to call ucsi_connector_change(), which then derefs the NULL ucsi->connector pointer.
Fix this by not setting ucsi->ntfy inside ucsi_init() until ucsi_init() has succeeded, so that ucsi_connector_change() ignores the events because UCSI_ENABLE_NTFY_CONNECTOR_CHANGE is not set in the ntfy mask.
--- drivers/usb/typec/ucsi/ucsi.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/usb/typec/ucsi/ucsi.c +6 -5
@@ -1205,7 +1205,7 @@ out_unlock:static int ucsi_init (struct ucsi *ucsi) {struct ucsi_connector *con; -u64 command; +u64 command, ntfy;int ret;int i;
@@ -1217,8 +1217,8 @@ static int ucsi_init(struct ucsi *ucsi) }/* Enable basic notifications */ - ucsi->ntfy =UCSI_ENABLE_NTFY_CMD_COMPLETE |UCSI_ENABLE_NTFY_ERROR ; - command =UCSI_SET_NOTIFICATION_ENABLE | ucsi->ntfy; + ntfy =UCSI_ENABLE_NTFY_CMD_COMPLETE |UCSI_ENABLE_NTFY_ERROR ; + command =UCSI_SET_NOTIFICATION_ENABLE | ntfy; ret =ucsi_send_command (ucsi, command,NULL ,0 );if (ret <0 ) goto err_reset;
@@ -1250,12 +1250,13 @@ static int ucsi_init(struct ucsi *ucsi) }/* Enable all notifications */ - ucsi->ntfy =UCSI_ENABLE_NTFY_ALL ; - command =UCSI_SET_NOTIFICATION_ENABLE | ucsi->ntfy; + ntfy =UCSI_ENABLE_NTFY_ALL ; + command =UCSI_SET_NOTIFICATION_ENABLE | ntfy; ret =ucsi_send_command (ucsi, command,NULL ,0 );if (ret <0 ) goto err_unregister; + ucsi->ntfy = ntfy;return 0 ; err_unregister:
Greg Kroah-Hartman
maintainerPATCH 183/224 usb: ucsi_acpi: Increase the command completion timeout
In reply to Greg Kroah-HartmanFrom: Hans de Goede <[email protected]>
commit 02d210f434249a7edbc160969b75df030dc6934d upstream.
Commit 130a96d698d7 ("usb: typec: ucsi: acpi: Increase command completion timeout value") increased the timeout from 5 seconds to 60 seconds due to issues related to alternate mode discovery.
After the alternate mode discovery switch to polled mode the timeout was reduced, but instead of being set back to 5 seconds it was reduced to 1 second.
This is causing problems when using a Lenovo ThinkPad X1 yoga gen7 connected over Type-C to a LG 27UL850-W (charging DP over Type-C).
When the monitor is already connected at boot the following error is logged: "PPM init failed (-110)", /sys/class/typec is empty and on unplugging the NULL pointer deref fixed earlier in this series happens.
When the monitor is connected after boot the following error is logged instead: "GET_CONNECTOR_STATUS failed (-110)".
Setting the timeout back to 5 seconds fixes both cases.
--- drivers/usb/typec/ucsi/ucsi_acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/typec/ucsi/ucsi_acpi.c +1 -1
@@ -78,7 +78,7 @@ static int ucsi_acpi_sync_write(struct uif (ret) goto out_clear_bit; -if (!wait_for_completion_timeout (&ua->complete,HZ )) +if (!wait_for_completion_timeout (&ua->complete,5 *HZ )) ret = -ETIMEDOUT ; out_clear_bit:
Greg Kroah-Hartman
maintainerPATCH 184/224 mm: kfence: fix using kfence_metadata without initialization in show_object()
In reply to Greg Kroah-HartmanFrom: Muchun Song <[email protected]>
commit 1c86a188e03156223a34d09ce290b49bd4dd0403 upstream.
The variable kfence_metadata is initialized in kfence_init_pool(), then, it is not initialized if kfence is disabled after booting. In this case, kfence_metadata will be used (e.g. ->lock and ->state fields) without initialization when reading /sys/kernel/debug/kfence/objects. There will be a warning if you enable CONFIG_DEBUG_SPINLOCK. Fix it by creating debugfs files when necessary.
--- mm/kfence/core.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
mm/kfence/core.c +8 -2
@@ -727,10 +727,14 @@ static const struct seq_operations objec };DEFINE_SEQ_ATTRIBUTE (objects); -static int __init kfence_debugfs_init (void ) +static int kfence_debugfs_init (void ) { -struct dentry *kfence_dir =debugfs_create_dir ("kfence" ,NULL ); +struct dentry *kfence_dir; +if (!READ_ONCE (kfence_enabled)) +return 0 ; + + kfence_dir =debugfs_create_dir ("kfence" ,NULL );debugfs_create_file ("stats" ,0444 , kfence_dir,NULL , &stats_fops);debugfs_create_file ("objects" ,0400 , kfence_dir,NULL , &objects_fops);return 0 ;
@@ -893,6 +897,8 @@ static int kfence_init_late(void) }kfence_init_enable (); +kfence_debugfs_init (); +return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 185/224 kfence: avoid passing -g for test
In reply to Greg Kroah-HartmanFrom: Marco Elver <[email protected]>
commit 2e08ca1802441224f5b7cc6bffbb687f7406de95 upstream.
Nathan reported that when building with GNU as and a version of clang that defaults to DWARF5:
$ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- \ LLVM=1 LLVM_IAS=0 O=build \ mrproper allmodconfig mm/kfence/kfence_test.o /tmp/kfence_test-08a0a0.s: Assembler messages: /tmp/kfence_test-08a0a0.s:14627: Error: non-constant .uleb128 is not supported /tmp/kfence_test-08a0a0.s:14628: Error: non-constant .uleb128 is not supported /tmp/kfence_test-08a0a0.s:14632: Error: non-constant .uleb128 is not supported /tmp/kfence_test-08a0a0.s:14633: Error: non-constant .uleb128 is not supported /tmp/kfence_test-08a0a0.s:14639: Error: non-constant .uleb128 is not supported ...
This is because -g defaults to the compiler debug info default. If the assembler does not support some of the directives used, the above errors occur. To fix, remove the explicit passing of -g.
All the test wants is that stack traces print valid function names, and debug info is not required for that. (I currently cannot recall why I added the explicit -g.)
--- mm/kfence/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/kfence/Makefile +1 -1
@@ -2,5 +2,5 @@ obj-y := core.o report.o -CFLAGS_kfence_test.o := -g -fno-omit-frame-pointer -fno-optimize-sibling-calls +CFLAGS_kfence_test.o := -fno-omit-frame-pointer -fno-optimize-sibling-calls obj-$(CONFIG_KFENCE_KUNIT_TEST) += kfence_test.o
Greg Kroah-Hartman
maintainerPATCH 186/224 io_uring/net: avoid sending -ECONNABORTED on repeated connection requests
In reply to Greg Kroah-HartmanFrom: Jens Axboe <[email protected]>
commit 74e2e17ee1f8d8a0928b90434ad7e2df70f8483e upstream.
Since io_uring does nonblocking connect requests, if we do two repeated ones without having a listener, the second will get -ECONNABORTED rather than the expected -ECONNREFUSED. Treat -ECONNABORTED like a normal retry condition if we're nonblocking, if we haven't already seen it.
--- io_uring/net.c | 25 ++++++++++++++++--------- 1 file changed, 16 insertions(+), 9 deletions(-)
io_uring/net.c +16 -9
@@ -47,6 +47,7 @@ struct io_connect {struct sockaddr __user *addr;int addr_len;bool in_progress; +bool seen_econnaborted; };struct io_sr_msg {
@@ -1404,7 +1405,7 @@ int io_connect_prep(struct io_kiocb *req conn->addr =u64_to_user_ptr (READ_ONCE (sqe->addr)); conn->addr_len =READ_ONCE (sqe->addr2); - conn->in_progress = false; + conn->in_progress = conn->seen_econnaborted = false;return 0 ; }
@@ -1441,18 +1442,24 @@ int io_connect(struct io_kiocb *req, uns ret =__sys_connect_file (req->file, &io->address, connect->addr_len, file_flags); -if ((ret == -EAGAIN || ret == -EINPROGRESS ) && force_nonblock) { +if ((ret == -EAGAIN || ret == -EINPROGRESS || ret == -ECONNABORTED ) + && force_nonblock) {if (ret == -EINPROGRESS ) { connect->in_progress = true; - }else { -if (req_has_async_data (req)) -return -EAGAIN ; -if (io_alloc_async_data (req)) { - ret = -ENOMEM ; +return -EAGAIN ; + } +if (ret == -ECONNABORTED ) { +if (connect->seen_econnaborted) goto out; - } -memcpy (req->async_data, &__io,sizeof (__io)); + connect->seen_econnaborted = true; + } +if (req_has_async_data (req)) +return -EAGAIN ; +if (io_alloc_async_data (req)) { + ret = -ENOMEM ; + goto out; } +memcpy (req->async_data, &__io,sizeof (__io));return -EAGAIN ; }if (ret == -ERESTARTSYS )
Greg Kroah-Hartman
maintainerPATCH 187/224 io_uring/rsrc: fix null-ptr-deref in io_file_bitmap_get()
In reply to Greg Kroah-HartmanFrom: Savino Dicanosa <[email protected]>
commit 02a4d923e4400a36d340ea12d8058f69ebf3a383 upstream.
When fixed files are unregistered, file_alloc_end and alloc_hint are not cleared. This can later cause a NULL pointer dereference in io_file_bitmap_get() if auto index selection is enabled via IORING_FILE_INDEX_ALLOC:
[ 6.519129] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] [ 6.541468] RIP: 0010:_find_next_zero_bit+0x1a/0x70 [...] [ 6.560906] Call Trace: [ 6.561322] <TASK> [ 6.561672] io_file_bitmap_get+0x38/0x60 [ 6.562281] io_fixed_fd_install+0x63/0xb0 [ 6.562851] ? __pfx_io_socket+0x10/0x10 [ 6.563396] io_socket+0x93/0xf0 [ 6.563855] ? __pfx_io_socket+0x10/0x10 [ 6.564411] io_issue_sqe+0x5b/0x3d0 [ 6.564914] io_submit_sqes+0x1de/0x650 [ 6.565452] __do_sys_io_uring_enter+0x4fc/0xb20 [ 6.566083] ? __do_sys_io_uring_register+0x11e/0xd80 [ 6.566779] do_syscall_64+0x3c/0x90 [ 6.567247] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[...]
To fix the issue, set file alloc range and alloc_hint to zero after file tables are freed.
--- io_uring/filetable.c | 3 +++ io_uring/rsrc.c | 1 + 2 files changed, 4 insertions(+)
io_uring/filetable.c +3 -0
@@ -19,6 +19,9 @@ static int io_file_bitmap_get(struct io_unsigned long nr = ctx->file_alloc_end;int ret; +if (!table->bitmap) +return -ENFILE ; + do { ret = find_next_zero_bit(table->bitmap, nr, table->alloc_hint); if (ret != nr)
io_uring/rsrc.c +1 -0
@@ -779,6 +779,7 @@ void __io_sqe_files_unregister(struct io }#endif io_free_file_tables (&ctx->file_table); +io_file_table_set_alloc_range (ctx,0 ,0 );io_rsrc_data_free (ctx->file_data); ctx->file_data =NULL ; ctx->nr_user_files =0 ;
Greg Kroah-Hartman
maintainerPATCH 188/224 Revert "kasan: drop skip_kasan_poison variable in free_pages_prepare"
In reply to Greg Kroah-HartmanFrom: Peter Collingbourne <[email protected]>
commit f446883d12b8bfa486f7c98d403054d61d38c989 upstream.
This reverts commit 487a32ec24be819e747af8c2ab0d5c515508086a.
should_skip_kasan_poison() reads the PG_skip_kasan_poison flag from page->flags. However, this line of code in free_pages_prepare():
page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
clears most of page->flags, including PG_skip_kasan_poison, before calling should_skip_kasan_poison(), which meant that it would never return true as a result of the page flag being set. Therefore, fix the code to call should_skip_kasan_poison() before clearing the flags, as we were doing before the reverted patch.
This fixes a measurable performance regression introduced in the reverted commit, where munmap() takes longer than intended if HW tags KASAN is supported and enabled at runtime. Without this patch, we see a single-digit percentage performance regression in a particular mmap()-heavy benchmark when enabling HW tags KASAN, and with the patch, there is no statistically significant performance impact when enabling HW tags KASAN.
--- mm/page_alloc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
mm/page_alloc.c +2 -1
@@ -1402,6 +1402,7 @@ static __always_inline bool free_pages_p unsigned int order, bool check_free, fpi_t fpi_flags) { int bad = 0; +bool skip_kasan_poison =should_skip_kasan_poison (page, fpi_flags);bool init =want_init_on_free ();VM_BUG_ON_PAGE (PageTail (page), page);
@@ -1476,7 +1477,7 @@ static __always_inline bool free_pages_p* With hardware tag-based KASAN, memory tags must be set before the * page becomes unavailable via debug_pagealloc or arch_free_page. */ -if (!should_skip_kasan_poison (page, fpi_flags)) { +if (!skip_kasan_poison) {kasan_poison_pages (page, order, init);/* Memory is already initialized if KASAN did it internally. */
Greg Kroah-Hartman
maintainerPATCH 189/224 test_maple_tree: add more testing for mas_empty_area()
In reply to Greg Kroah-HartmanFrom: Liam R. Howlett <[email protected]>
commit 4bd6dded6318dc8e2514d74868c1f8fb38b61a60 upstream.
Test robust filling of an entire area of the tree, then test one beyond. This is to test the walking back up the tree at the end of nodes and error condition. Test inspired by the reproducer code provided by Snild Dolkow.
The last test in the function tests for the case of a corrupted maple state caused by the incorrect limits set during mas_skip_node(). There needs to be a gap in the second last child and last child, but the search must rule out the second last child's gap. This would avoid correcting the maple state to the correct max limit and return an error.
--- lib/test_maple_tree.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+)
lib/test_maple_tree.c +48 -0
@@ -2602,6 +2602,49 @@ static noinline void check_empty_area_wircu_read_unlock (); } +static noinline void check_empty_area_fill(struct maple_tree *mt) +{ +const unsigned long max =0x25D78000 ; +unsigned long size; +int loop, shift; +MA_STATE (mas, mt,0 ,0 ); + +mt_set_non_kernel (99999 ); +for (shift =12 ; shift <=16 ; shift++) { + loop =5000 ; + size =1 << shift; +while (loop--) { +mas_set (&mas,0 ); +mas_lock (&mas); +MT_BUG_ON (mt,mas_empty_area (&mas,0 , max, size) !=0 ); +MT_BUG_ON (mt, mas.last != mas.index + size -1 ); +mas_store_gfp (&mas, (void *)size,GFP_KERNEL ); +mas_unlock (&mas); +mas_reset (&mas); + } + } + +/* No space left. */ + size =0x1000 ; +rcu_read_lock (); +MT_BUG_ON (mt,mas_empty_area (&mas,0 , max, size) != -EBUSY ); +rcu_read_unlock (); + +/* Fill a depth 3 node to the maximum */ +for (unsigned long i =629440511 ; i <=629440800 ; i +=6 ) +mtree_store_range (mt, i, i +5 , (void *)i,GFP_KERNEL ); +/* Make space in the second-last depth 4 node */ +mtree_erase (mt,631668735 ); +/* Make space in the last depth 4 node */ +mtree_erase (mt,629506047 ); +mas_reset (&mas); +/* Search from just after the gap in the second-last depth 4 */ +rcu_read_lock (); +MT_BUG_ON (mt,mas_empty_area (&mas,629506048 ,690000000 ,0x5000 ) !=0 ); +rcu_read_unlock (); +mt_set_non_kernel (0 ); +} +static DEFINE_MTREE (tree);static int maple_tree_seed (void ) {
@@ -2854,6 +2897,11 @@ static int maple_tree_seed(void)check_empty_area_window (&tree);mtree_destroy (&tree); +mt_init_flags (&tree,MT_FLAGS_ALLOC_RANGE ); +check_empty_area_fill (&tree); +mtree_destroy (&tree); + +#if defined(BENCH ) skip:#endif
Greg Kroah-Hartman
maintainerPATCH 190/224 maple_tree: fix mas_skip_node() end slot detection
In reply to Greg Kroah-HartmanFrom: Liam R. Howlett <[email protected]>
commit 0fa99fdfe1b38da396d0b2d1496a823bcd0ebea0 upstream.
Patch series "Fix mas_skip_node() for mas_empty_area()", v2.
mas_empty_area() was incorrectly returning an error when there was room. The issue was tracked down to mas_skip_node() using the incorrect end-of-slot count. Instead of using the nodes hard limit, the limit of data should be used.
mas_skip_node() was also setting the min and max to that of the child node, which was unnecessary. Within these limits being set, there was also a bug that corrupted the maple state's max if the offset was set to the maximum node pivot. The bug was without consequence unless there was a sufficient gap in the next child node which would cause an error to be returned.
This patch set fixes these errors by removing the limit setting from mas_skip_node() and uses the mas_data_end() for slot limits, and adds tests for all failures discovered.
This patch (of 2):
mas_skip_node() is used to move the maple state to the node with a higher limit. It does this by walking up the tree and increasing the slot count. Since slot count may not be able to be increased, it may need to walk up multiple times to find room to walk right to a higher limit node. The limit of slots that was being used was the node limit and not the last location of data in the node. This would cause the maple state to be shifted outside actual data and enter an error state, thus returning -EBUSY.
The result of the incorrect error state means that mas_awalk() would return an error instead of finding the allocation space.
The fix is to use mas_data_end() in mas_skip_node() to detect the nodes data end point and continue walking the tree up until it is safe to move to a node with a higher limit.
The walk up the tree also sets the maple state limits so remove the buggy code from mas_skip_node(). Setting the limits had the unfortunate side effect of triggering another bug if the parent node was full and the there was no suitable gap in the second last child, but room in the next child.
mas_skip_node() may also be passed a maple state in an error state from mas_anode_descend() when no allocations are available. Return on such an error state immediately.
--- lib/maple_tree.c | 24 +++++------------------- 1 file changed, 5 insertions(+), 19 deletions(-)
lib/maple_tree.c +5 -19
@@ -5088,35 +5088,21 @@ static inline bool mas_rewind_node(struc*/ static inline bool mas_skip_node (struct ma_state *mas) { -unsigned char slot, slot_count; -unsigned long *pivots; -enum maple_type mt; +if (mas_is_err (mas)) +return false; - mt =mte_node_type (mas->node); - slot_count = mt_slots[mt] -1 ;do {if (mte_is_root (mas->node)) { - slot = mas->offset; -if (slot > slot_count) { +if (mas->offset >=mas_data_end (mas)) {mas_set_err (mas, -EBUSY );return false; } }else {mas_ascend (mas); - slot = mas->offset; - mt =mte_node_type (mas->node); - slot_count = mt_slots[mt] -1 ; } - }while (slot > slot_count); - - mas->offset = ++slot; - pivots =ma_pivots (mas_mn (mas), mt); -if (slot >0 ) - mas->min = pivots[slot -1 ] +1 ; - -if (slot <= slot_count) - mas->max = pivots[slot]; + }while (mas->offset >=mas_data_end (mas)); + mas->offset++;return true; }
Greg Kroah-Hartman
maintainerPATCH 191/224 ksmbd: fix wrong signingkey creation when encryption is AES256
In reply to Greg Kroah-HartmanFrom: Namjae Jeon <[email protected]>
commit 7a891d4b62d62566323676cb0e922ded4f37afe1 upstream.
MacOS and Win11 support AES256 encrytion and it is included in the cipher array of encryption context. Especially on macOS, The most preferred cipher is AES256. Connecting to ksmbd fails on newer MacOS clients that support AES256 encryption. MacOS send disconnect request after receiving final session setup response from ksmbd. Because final session setup is signed with signing key was generated incorrectly.
For signging key, 'L' value should be initialized to 128 if key size is 16bytes.
--- fs/ksmbd/auth.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
fs/ksmbd/auth.c +3 -2
@@ -727,8 +727,9 @@ static int generate_key(struct ksmbd_con goto smb3signkey_ret; } -if (conn->cipher_type ==SMB2_ENCRYPTION_AES256_CCM || - conn->cipher_type ==SMB2_ENCRYPTION_AES256_GCM ) +if (key_size ==SMB3_ENC_DEC_KEY_SIZE && + (conn->cipher_type ==SMB2_ENCRYPTION_AES256_CCM || + conn->cipher_type ==SMB2_ENCRYPTION_AES256_GCM )) rc =crypto_shash_update (CRYPTO_HMACSHA256 (ctx),L256 ,4 );else rc =crypto_shash_update (CRYPTO_HMACSHA256 (ctx),L128 ,4 );
Greg Kroah-Hartman
maintainerPATCH 192/224 ksmbd: set FILE_NAMED_STREAMS attribute in FS_ATTRIBUTE_INFORMATION
In reply to Greg Kroah-HartmanFrom: Namjae Jeon <[email protected]>
commit 728f14c72b71a19623df329c1c7c9d1452e56f1e upstream.
If vfs objects = streams_xattr in ksmbd.conf FILE_NAMED_STREAMS should be set to Attributes in FS_ATTRIBUTE_INFORMATION. MacOS client show "Format: SMB (Unknown)" on faked NTFS and no streams support.
--- fs/ksmbd/smb2pdu.c | 4 ++++ 1 file changed, 4 insertions(+)
fs/ksmbd/smb2pdu.c +4 -0
@@ -4954,6 +4954,10 @@ static int smb2_get_info_filesystem(stru info->Attributes |=cpu_to_le32 (server_conf.share_fake_fscaps); +if (test_share_config_flag (work->tcon->share_conf, +KSMBD_SHARE_FLAG_STREAMS )) + info->Attributes |=cpu_to_le32 (FILE_NAMED_STREAMS ); + info->MaxPathNameComponentLength =cpu_to_le32 (stfs.f_namelen); len =smbConvertToUTF16 ((__le16 *)info->FileSystemName,"NTFS" ,PATH_MAX , conn->local_nls,0 );
Greg Kroah-Hartman
maintainerPATCH 193/224 ksmbd: dont terminate inactive sessions after a few seconds
In reply to Greg Kroah-HartmanFrom: Namjae Jeon <[email protected]>
commit be6f42fad5f5fd1fea9d562df82c38ad6ed3bfe9 upstream.
Steve reported that inactive sessions are terminated after a few seconds. ksmbd terminate when receiving -EAGAIN error from kernel_recvmsg(). -EAGAIN means there is no data available in timeout. So ksmbd should keep connection with unlimited retries instead of terminating inactive sessions.
--- fs/ksmbd/connection.c | 4 ++-- fs/ksmbd/connection.h | 3 ++- fs/ksmbd/transport_rdma.c | 2 +- fs/ksmbd/transport_tcp.c | 35 +++++++++++++++++++++++------------ 4 files changed, 28 insertions(+), 16 deletions(-)
fs/ksmbd/connection.c +2 -2
@@ -298,7 +298,7 @@ int ksmbd_conn_handler_loop(void *p)kvfree (conn->request_buf); conn->request_buf =NULL ; - size = t->ops->read (t, hdr_buf,sizeof (hdr_buf)); + size = t->ops->read (t, hdr_buf,sizeof (hdr_buf),-1 );if (size !=sizeof (hdr_buf))break ;
@@ -344,7 +344,7 @@ int ksmbd_conn_handler_loop(void *p)* We already read 4 bytes to find out PDU size, now * read in PDU */ - size = t->ops->read (t, conn->request_buf +4 , pdu_size); + size = t->ops->read (t, conn->request_buf +4 , pdu_size,2 );if (size <0 ) {pr_err ("sock_read failed: %d\n" , size);break ;
fs/ksmbd/connection.h +2 -1
@@ -114,7 +114,8 @@ struct ksmbd_transport_ops {int (*prepare)(struct ksmbd_transport *t);void (*disconnect)(struct ksmbd_transport *t);void (*shutdown)(struct ksmbd_transport *t); -int (*read)(struct ksmbd_transport *t,char *buf,unsigned int size); +int (*read)(struct ksmbd_transport *t,char *buf, +unsigned int size,int max_retries);int (*writev)(struct ksmbd_transport *t,struct kvec *iovs,int niov,int size,bool need_invalidate_rkey,unsigned int remote_key);
fs/ksmbd/transport_rdma.c +1 -1
@@ -670,7 +670,7 @@ static int smb_direct_post_recv(struct s }static int smb_direct_read (struct ksmbd_transport *t,char *buf, -unsigned int size) +unsigned int size,int unused) {struct smb_direct_recvmsg *recvmsg;struct smb_direct_data_transfer *data_transfer;
fs/ksmbd/transport_tcp.c +23 -12
@@ -291,16 +291,18 @@ static int ksmbd_tcp_run_kthread(struct/** * ksmbd_tcp_readv() - read data from socket in given iovec -* @t: TCP transport instance -* @iov_orig: base IO vector -* @nr_segs: number of segments in base iov -* @to_read: number of bytes to read from socket +* @t: TCP transport instance +* @iov_orig: base IO vector +* @nr_segs: number of segments in base iov +* @to_read: number of bytes to read from socket +* @max_retries: maximum retry count * * Return: on success return number of bytes read from socket, * otherwise return error number */ static int ksmbd_tcp_readv (struct tcp_transport *t,struct kvec *iov_orig, -unsigned int nr_segs,unsigned int to_read) +unsigned int nr_segs,unsigned int to_read, +int max_retries) {int length =0 ;int total_read;
@@ -308,7 +310,6 @@ static int ksmbd_tcp_readv(struct tcp_trstruct msghdr ksmbd_msg;struct kvec *iov;struct ksmbd_conn *conn =KSMBD_TRANS (t)->conn; -int max_retry =2 ; iov =get_conn_iovec (t, nr_segs);if (!iov)
@@ -335,14 +336,23 @@ static int ksmbd_tcp_readv(struct tcp_tr }else if (conn->status ==KSMBD_SESS_NEED_RECONNECT ) { total_read = -EAGAIN ;break ; - }else if ((length == -ERESTARTSYS || length == -EAGAIN ) && - max_retry) { + }else if (length == -ERESTARTSYS || length == -EAGAIN ) { +/* +* If max_retries is negative, Allow unlimited +* retries to keep connection with inactive sessions. +*/ +if (max_retries ==0 ) { + total_read = length; +break ; + }else if (max_retries >0 ) { + max_retries--; + } +usleep_range (1000 ,2000 ); length =0 ; - max_retry--;continue ; }else if (length <=0 ) { - total_read = -EAGAIN ; + total_read = length;break ; } }
@@ -358,14 +368,15 @@ static int ksmbd_tcp_readv(struct tcp_tr* Return: on success return number of bytes read from socket, * otherwise return error number */ -static int ksmbd_tcp_read (struct ksmbd_transport *t,char *buf,unsigned int to_read) +static int ksmbd_tcp_read (struct ksmbd_transport *t,char *buf, +unsigned int to_read,int max_retries) {struct kvec iov; iov.iov_base = buf; iov.iov_len = to_read; -return ksmbd_tcp_readv (TCP_TRANS (t), &iov,1 , to_read); +return ksmbd_tcp_readv (TCP_TRANS (t), &iov,1 , to_read, max_retries); } static int ksmbd_tcp_writev(struct ksmbd_transport *t, struct kvec *iov,
Greg Kroah-Hartman
maintainerPATCH 194/224 ksmbd: return STATUS_NOT_SUPPORTED on unsupported smb2.0 dialect
In reply to Greg Kroah-HartmanFrom: Namjae Jeon <[email protected]>
commit b53e8cfec30b93c120623232ba27c041b1ef8f1a upstream.
ksmbd returned "Input/output error" when mounting with vers=2.0 to ksmbd. It should return STATUS_NOT_SUPPORTED on unsupported smb2.0 dialect.
--- fs/ksmbd/smb_common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/ksmbd/smb_common.c +2 -2
@@ -434,7 +434,7 @@ int ksmbd_extract_shortname(struct ksmbdstatic int __smb2_negotiate (struct ksmbd_conn *conn) { -return (conn->dialect >=SMB21_PROT_ID && +return (conn->dialect >=SMB20_PROT_ID && conn->dialect <=SMB311_PROT_ID ); }
@@ -465,7 +465,7 @@ int ksmbd_smb_negotiate_common(struct ks } } -if (command ==SMB2_NEGOTIATE_HE &&__smb2_negotiate (conn)) { +if (command ==SMB2_NEGOTIATE_HE ) { ret =smb2_handle_negotiate (work);init_smb2_neg_rsp (work);return ret;
Greg Kroah-Hartman
maintainerPATCH 195/224 ksmbd: return unsupported error on smb1 mount
In reply to Greg Kroah-HartmanFrom: Namjae Jeon <[email protected]>
commit 39b291b86b5988bf8753c3874d5c773399d09b96 upstream.
ksmbd disconnect connection when mounting with vers=smb1. ksmbd should send smb1 negotiate response to client for correct unsupported error return. This patch add needed SMB1 macros and fill NegProt part of the response for smb1 negotiate response.
--- fs/ksmbd/connection.c | 7 ++----- fs/ksmbd/smb_common.c | 23 ++++++++++++++++++++--- fs/ksmbd/smb_common.h | 30 ++++++++---------------------- 3 files changed, 30 insertions(+), 30 deletions(-)
fs/ksmbd/connection.c +2 -5
@@ -319,13 +319,10 @@ int ksmbd_conn_handler_loop(void *p) }/* -* Check if pdu size is valid (min : smb header size, -* max : 0x00FFFFFF). +* Check maximum pdu size(0x00FFFFFF). */ -if (pdu_size < __SMB2_HEADER_STRUCTURE_SIZE || - pdu_size >MAX_STREAM_PROT_LEN ) { +if (pdu_size >MAX_STREAM_PROT_LEN )break ; - }/* 4 for rfc1002 length field */ size = pdu_size +4 ;
fs/ksmbd/smb_common.c +20 -3
@@ -442,9 +442,26 @@ static int smb_handle_negotiate(struct k {struct smb_negotiate_rsp *neg_rsp = work->response_buf; -ksmbd_debug (SMB ,"Unsupported SMB protocol\n" ); - neg_rsp->hdr.Status.CifsError =STATUS_INVALID_LOGON_TYPE ; -return -EINVAL ; +ksmbd_debug (SMB ,"Unsupported SMB1 protocol\n" ); + +/* +* Remove 4 byte direct TCP header, add 2 byte bcc and +* 2 byte DialectIndex. +*/ + *(__be32 *)work->response_buf = +cpu_to_be32 (sizeof (struct smb_hdr ) -4 +2 +2 ); + neg_rsp->hdr.Status.CifsError =STATUS_SUCCESS ; + + neg_rsp->hdr.Command =SMB_COM_NEGOTIATE ; + *(__le32 *)neg_rsp->hdr.Protocol =SMB1_PROTO_NUMBER ; + neg_rsp->hdr.Flags =SMBFLG_RESPONSE ; + neg_rsp->hdr.Flags2 =SMBFLG2_UNICODE |SMBFLG2_ERR_STATUS | +SMBFLG2_EXT_SEC |SMBFLG2_IS_LONG_NAME ; + + neg_rsp->hdr.WordCount =1 ; + neg_rsp->DialectIndex =cpu_to_le16 (work->conn->dialect); + neg_rsp->ByteCount =0 ; +return 0 ; }int ksmbd_smb_negotiate_common (struct ksmbd_work *work,unsigned int command)
fs/ksmbd/smb_common.h +8 -22
@@ -158,8 +158,15 @@#define SMB1_PROTO_NUMBER cpu_to_le32(0x424d53ff)#define SMB_COM_NEGOTIATE 0x72 -#define SMB1_CLIENT_GUID_SIZE (16) + +#define SMBFLG_RESPONSE 0x80/* this PDU is a response from server */ + +#define SMBFLG2_IS_LONG_NAME cpu_to_le16(0x40) +#define SMBFLG2_EXT_SEC cpu_to_le16(0x800) +#define SMBFLG2_ERR_STATUS cpu_to_le16(0x4000) +#define SMBFLG2_UNICODE cpu_to_le16(0x8000) +struct smb_hdr {__be32 smb_buf_length;__u8 Protocol[4 ];
@@ -199,28 +206,7 @@ struct smb_negotiate_req {struct smb_negotiate_rsp {struct smb_hdr hdr;/* wct = 17 */ __le16 DialectIndex;/* 0xFFFF = no dialect acceptable */ -__u8 SecurityMode; -__le16 MaxMpxCount; -__le16 MaxNumberVcs; -__le32 MaxBufferSize; -__le32 MaxRawSize; -__le32 SessionKey; -__le32 Capabilities;/* see below */ -__le32 SystemTimeLow; -__le32 SystemTimeHigh; -__le16 ServerTimeZone; -__u8 EncryptionKeyLength;__le16 ByteCount; -union { -unsigned char EncryptionKey[8 ];/* cap extended security off */ -/* followed by Domain name - if extended security is off */ -/* followed by 16 bytes of server GUID */ -/* then security blob if cap_extended_security negotiated */ -struct { -unsigned char GUID[SMB1_CLIENT_GUID_SIZE ]; -unsigned char SecurityBlob[1 ]; - } __packed extended_response; - } __packed u; } __packed;struct filesystem_attribute_info {
Greg Kroah-Hartman
maintainerPATCH 196/224 wifi: mac80211: fix qos on mesh interfaces
In reply to Greg Kroah-HartmanFrom: Felix Fietkau <[email protected]>
commit 4e348c6c6e23491ae6eb5e077848a42d0562339c upstream.
When ieee80211_select_queue is called for mesh, the sta pointer is usually NULL, since the nexthop is looked up much later in the tx path. Explicitly check for unicast address in that case in order to make qos work again.
--- net/mac80211/wme.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
net/mac80211/wme.c +4 -2
@@ -144,12 +144,14 @@ u16 ieee80211_select_queue_80211(structu16 __ieee80211_select_queue (struct ieee80211_sub_if_data *sdata,struct sta_info *sta,struct sk_buff *skb) { +const struct ethhdr *eth = (void *)skb->data;struct mac80211_qos_map *qos_map;bool qos;/* all mesh/ocb stations are required to support WME */ -if (sta && (sdata->vif.type ==NL80211_IFTYPE_MESH_POINT || - sdata->vif.type ==NL80211_IFTYPE_OCB )) +if ((sdata->vif.type ==NL80211_IFTYPE_MESH_POINT && + !is_multicast_ether_addr (eth->h_dest)) || + (sdata->vif.type ==NL80211_IFTYPE_OCB && sta)) qos = true;else if (sta) qos = sta->sta.wme;
Greg Kroah-Hartman
maintainerPATCH 197/224 nilfs2: fix kernel-infoleak in nilfs_ioctl_wrap_copy()
In reply to Greg Kroah-HartmanFrom: Ryusuke Konishi <[email protected]>
commit 003587000276f81d0114b5ce773d80c119d8cb30 upstream.
The ioctl helper function nilfs_ioctl_wrap_copy(), which exchanges a metadata array to/from user space, may copy uninitialized buffer regions to user space memory for read-only ioctl commands NILFS_IOCTL_GET_SUINFO and NILFS_IOCTL_GET_CPINFO.
This can occur when the element size of the user space metadata given by the v_size member of the argument nilfs_argv structure is larger than the size of the metadata element (nilfs_suinfo structure or nilfs_cpinfo structure) on the file system side.
KMSAN-enabled kernels detect this issue as follows:
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xc0/0x100 lib/usercopy.c:33 instrument_copy_to_user include/linux/instrumented.h:121 [inline] _copy_to_user+0xc0/0x100 lib/usercopy.c:33 copy_to_user include/linux/uaccess.h:169 [inline] nilfs_ioctl_wrap_copy+0x6fa/0xc10 fs/nilfs2/ioctl.c:99 nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline] nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290 nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343 __do_compat_sys_ioctl fs/ioctl.c:968 [inline] __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910 __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82
Uninit was created at:
__alloc_pages+0x9f6/0xe90 mm/page_alloc.c:5572 alloc_pages+0xab0/0xd80 mm/mempolicy.c:2287 __get_free_pages+0x34/0xc0 mm/page_alloc.c:5599 nilfs_ioctl_wrap_copy+0x223/0xc10 fs/nilfs2/ioctl.c:74 nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline] nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290 nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343 __do_compat_sys_ioctl fs/ioctl.c:968 [inline] __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910 __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82
Bytes 16-127 of 3968 are uninitialized
...
This eliminates the leak issue by initializing the page allocated as buffer using get_zeroed_page().
--- fs/nilfs2/ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nilfs2/ioctl.c +1 -1
@@ -71,7 +71,7 @@ static int nilfs_ioctl_wrap_copy(structif (argv->v_index > ~(__u64 )0 - argv->v_nmembs)return -EINVAL ; - buf = (void *)__get_free_pages (GFP_NOFS ,0 ); + buf = (void *)get_zeroed_page (GFP_NOFS );if (unlikely (!buf))return -ENOMEM ; maxmembs =PAGE_SIZE / argv->v_size;
Greg Kroah-Hartman
maintainerPATCH 198/224 drm/bridge: lt8912b: return EPROBE_DEFER if bridge is not found
In reply to Greg Kroah-HartmanFrom: Matheus Castello <[email protected]>
commit 1a70ca89d59c7c8af006d29b965a95ede0abb0da upstream.
Returns EPROBE_DEFER when of_drm_find_bridge() fails, this is consistent with what all the other DRM bridge drivers are doing and this is required since the bridge might not be there when the driver is probed and this should not be a fatal failure.
--- drivers/gpu/drm/bridge/lontium-lt8912b.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/bridge/lontium-lt8912b.c +2 -2
@@ -659,8 +659,8 @@ static int lt8912_parse_dt(struct lt8912 lt->hdmi_port =of_drm_find_bridge (port_node);if (!lt->hdmi_port) { -dev_err (lt->dev,"%s: Failed to get hdmi port\n" , __func__); - ret = -ENODEV ; + ret = -EPROBE_DEFER ; +dev_err_probe (lt->dev, ret,"%s: Failed to get hdmi port\n" , __func__); goto err_free_host_node; }
Greg Kroah-Hartman
maintainerPATCH 199/224 drm/amd/display: fix wrong index used in dccg32_set_dpstreamclk
In reply to Greg Kroah-HartmanFrom: Hersen Wu <[email protected]>
commit 4c94e57c258cb7800aa5f3a9d9597d91291407a9 upstream.
[Why & How]
When merging commit 9af611f29034 ("drm/amd/display: Fix DCN32 DPSTREAMCLK_CNTL programming"), index change was not picked up.
--- drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dccg.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/gpu/drm/amd/display/dc/dcn32/dcn32_dccg.c +1 -2
@@ -271,8 +271,7 @@ static void dccg32_set_dpstreamclk(dccg32_set_dtbclk_p_src (dccg, src, otg_inst);/* enabled to select one of the DTBCLKs for pipe */ -switch (otg_inst) - { +switch (dp_hpo_inst) {case 0 : REG_UPDATE_2(DPSTREAMCLK_CNTL, DPSTREAMCLK0_EN,
Signature · 1 line
2.40.0
Greg Kroah-Hartman
maintainerPATCH 200/224 drm/meson: fix missing component unbind on bind errors
In reply to Greg Kroah-HartmanFrom: Johan Hovold <[email protected]>
commit ba98413bf45edbf33672e2539e321b851b2cfbd1 upstream.
Make sure to unbind all subcomponents when binding the aggregate device fails.
--- drivers/gpu/drm/meson/meson_drv.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
drivers/gpu/drm/meson/meson_drv.c +8 -5
@@ -325,23 +325,23 @@ static int meson_drv_bind_master(struct ret =meson_encoder_hdmi_init (priv);if (ret) - goto exit_afbcd; + goto unbind_all; ret =meson_plane_create (priv);if (ret) - goto exit_afbcd; + goto unbind_all; ret =meson_overlay_create (priv);if (ret) - goto exit_afbcd; + goto unbind_all; ret =meson_crtc_create (priv);if (ret) - goto exit_afbcd; + goto unbind_all; ret =request_irq (priv->vsync_irq, meson_irq,0 , drm->driver->name, drm);if (ret) - goto exit_afbcd; + goto unbind_all;drm_mode_config_reset (drm);
@@ -359,6 +359,9 @@ static int meson_drv_bind_master(struct uninstall_irq:free_irq (priv->vsync_irq, drm); +unbind_all: +if (has_components) +component_unbind_all (drm->dev, drm); exit_afbcd:if (priv->afbcd.ops) priv->afbcd.ops->exit (priv);
Greg Kroah-Hartman
maintainerPATCH 201/224 drm/amdgpu/nv: Apply ASPM quirk on Intel ADL + AMD Navi
In reply to Greg Kroah-HartmanFrom: Kai-Heng Feng <[email protected]>
commit 2b072442f4962231a8516485012bb2d2551ef2fe upstream.
S2idle resume freeze can be observed on Intel ADL + AMD WX5500. This is caused by commit 0064b0ce85bb ("drm/amd/pm: enable ASPM by default").
The root cause is still not clear for now.
So extend and apply the ASPM quirk from commit e02fe3bc7aba ("drm/amdgpu: vi: disable ASPM on Intel Alder Lake based systems"), to workaround the issue on Navi cards too.
--- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +++++++++++++++ drivers/gpu/drm/amd/amdgpu/nv.c | 2 +- drivers/gpu/drm/amd/amdgpu/vi.c | 17 +---------------- 4 files changed, 18 insertions(+), 17 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu.h +1 -0
@@ -1263,6 +1263,7 @@ void amdgpu_device_pci_config_reset(struint amdgpu_device_pci_reset (struct amdgpu_device *adev);bool amdgpu_device_need_post (struct amdgpu_device *adev);bool amdgpu_device_should_use_aspm (struct amdgpu_device *adev); +bool amdgpu_device_aspm_support_quirk (void );void amdgpu_cs_report_moved_bytes (struct amdgpu_device *adev,u64 num_bytes,u64 num_vis_bytes);
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +15 -0
@@ -78,6 +78,10 @@#include <drm/drm_drv.h> +#if IS_ENABLED (CONFIG_X86 ) +#include <asm/intel-family.h> +#endif +MODULE_FIRMWARE ("amdgpu/vega10_gpu_info.bin" );MODULE_FIRMWARE ("amdgpu/vega12_gpu_info.bin" );MODULE_FIRMWARE ("amdgpu/raven_gpu_info.bin" );
@@ -1353,6 +1357,17 @@ bool amdgpu_device_should_use_aspm(strucreturn pcie_aspm_enabled (adev->pdev); } +bool amdgpu_device_aspm_support_quirk (void ) +{ +#if IS_ENABLED (CONFIG_X86 ) +struct cpuinfo_x86 *c = &cpu_data (0 ); + +return !(c->x86 ==6 && c->x86_model ==INTEL_FAM6_ALDERLAKE ); +#else +return true; +#endif +} +/* if we get transitioned to only one device, take VGA back */ /** * amdgpu_device_vga_set_decode - enable/disable vga decode
drivers/gpu/drm/amd/amdgpu/nv.c +1 -1
@@ -527,7 +527,7 @@ static void nv_pcie_gen3_enable(struct astatic void nv_program_aspm (struct amdgpu_device *adev) { -if (!amdgpu_device_should_use_aspm (adev)) +if (!amdgpu_device_should_use_aspm (adev) || !amdgpu_device_aspm_support_quirk ())return ; if (!(adev->flags & AMD_IS_APU) &&
drivers/gpu/drm/amd/amdgpu/vi.c +1 -16
@@ -81,10 +81,6 @@#include "mxgpu_vi.h" #include "amdgpu_dm.h" -#if IS_ENABLED (CONFIG_X86 ) -#include <asm/intel-family.h> -#endif -#define ixPCIE_LC_L1_PM_SUBSTATE 0x100100C6#define PCIE_LC_L1_PM_SUBSTATE__LC_L1_SUBSTATES_OVERRIDE_EN_MASK 0x00000001L#define PCIE_LC_L1_PM_SUBSTATE__LC_PCI_PM_L1_2_OVERRIDE_MASK 0x00000002L
@@ -1138,24 +1134,13 @@ static void vi_enable_aspm(struct amdgpuWREG32_PCIE (ixPCIE_LC_CNTL, data); } -static bool aspm_support_quirk_check (void ) -{ -#if IS_ENABLED (CONFIG_X86 ) -struct cpuinfo_x86 *c = &cpu_data (0 ); - -return !(c->x86 ==6 && c->x86_model ==INTEL_FAM6_ALDERLAKE ); -#else -return true; -#endif -} -static void vi_program_aspm (struct amdgpu_device *adev) {u32 data, data1, orig;bool bL1SS = false;bool bClkReqSupport = true; -if (!amdgpu_device_should_use_aspm (adev) || !aspm_support_quirk_check ()) +if (!amdgpu_device_should_use_aspm (adev) || !amdgpu_device_aspm_support_quirk ())return ; if (adev->flags & AMD_IS_APU ||
Greg Kroah-Hartman
maintainerPATCH 202/224 drm/i915/active: Fix missing debug object activation
In reply to Greg Kroah-HartmanFrom: Nirmoy Das <[email protected]>
commit e92eb246feb9019b0b137706c934b8891cdfe3c2 upstream.
debug_active_activate() expected ref->count to be zero which is not true anymore as __i915_active_activate() calls debug_active_activate() after incrementing the count.
v2: No need to check for "ref->count == 1" as __i915_active_activate() already make sure of that(Janusz).
--- drivers/gpu/drm/i915/i915_active.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/gpu/drm/i915/i915_active.c +1 -2
@@ -92,8 +92,7 @@ static void debug_active_init(struct i91static void debug_active_activate (struct i915_active *ref) {lockdep_assert_held (&ref->tree_lock); -if (!atomic_read (&ref->count))/* before the first inc */ -debug_object_activate (ref, &active_debug_desc); +debug_object_activate (ref, &active_debug_desc); }static void debug_active_deactivate (struct i915_active *ref)
Greg Kroah-Hartman
maintainerPATCH 203/224 drm/i915: Preserve crtc_state->inherited during state clearing
In reply to Greg Kroah-HartmanFrom: Ville Syrjälä <[email protected]>
commit 3a84f2c6c9558c554a90ec26ad25df92fc5e05b7 upstream.
intel_crtc_prepare_cleared_state() is unintentionally losing the "inherited" flag. This will happen if intel_initial_commit() is forced to go through the full modeset calculations for whatever reason.
Afterwards the first real commit from userspace will not get forced to the full modeset path, and thus eg. audio state may not get recomputed properly. So if the monitor was already enabled during boot audio will not work until userspace itself does an explicit full modeset.
--- drivers/gpu/drm/i915/display/intel_display.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/i915/display/intel_display.c +1 -0
@@ -5186,6 +5186,7 @@ intel_crtc_prepare_cleared_state(struct* only fields that are know to not cause problems are preserved. */ saved_state->uapi = crtc_state->uapi; + saved_state->inherited = crtc_state->inherited; saved_state->scaler_state = crtc_state->scaler_state; saved_state->shared_dpll = crtc_state->shared_dpll; saved_state->dpll_hw_state = crtc_state->dpll_hw_state;
Greg Kroah-Hartman
maintainerPATCH 204/224 drm/amdgpu: skip ASIC reset for APUs when go to S4
In reply to Greg Kroah-HartmanFrom: Tim Huang <[email protected]>
commit b589626674de94d977e81c99bf7905872b991197 upstream.
For GC IP v11.0.4/11, PSP TMR need to be reserved for ASIC mode2 reset. But for S4, when psp suspend, it will destroy the TMR that fails the ASIC reset.
[ 96.006101] amdgpu 0000:62:00.0: amdgpu: MODE2 reset [ 100.409717] amdgpu 0000:62:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000011 SMN_C2PMSG_82:0x00000002 [ 100.411593] amdgpu 0000:62:00.0: amdgpu: Mode2 reset failed! [ 100.412470] amdgpu 0000:62:00.0: PM: pci_pm_freeze(): amdgpu_pmops_freeze+0x0/0x50 [amdgpu] returns -62 [ 100.414020] amdgpu 0000:62:00.0: PM: dpm_run_callback(): pci_pm_freeze+0x0/0xd0 returns -62 [ 100.415311] amdgpu 0000:62:00.0: PM: pci_pm_freeze+0x0/0xd0 returned -62 after 4623202 usecs [ 100.416608] amdgpu 0000:62:00.0: PM: failed to freeze async: error -62
We can skip the reset on APUs, assuming we can resume them properly. Verified on some GFX11, GFX10 and old GFX9 APUs.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +4 -1
@@ -2447,7 +2447,10 @@ static int amdgpu_pmops_freeze(struct de adev->in_s4 = false;if (r)return r; -return amdgpu_asic_reset (adev); + +if (amdgpu_acpi_should_gpu_reset (adev)) +return amdgpu_asic_reset (adev); +return 0 ; }static int amdgpu_pmops_thaw (struct device *dev)
Greg Kroah-Hartman
maintainerPATCH 205/224 drm/amdgpu: reposition the gpu reset checking for reuse
In reply to Greg Kroah-HartmanFrom: Tim Huang <[email protected]>
commit aaee0ce460b954e08b6e630d7e54b2abb672feb8 upstream.
Move the amdgpu_acpi_should_gpu_reset out of CONFIG_SUSPEND to share it with hibernate case.
--- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 41 +++++++++++++++++-------------- 2 files changed, 25 insertions(+), 20 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu.h +2 -2
@@ -1383,10 +1383,12 @@ int amdgpu_acpi_smart_shift_update(strucint amdgpu_acpi_pcie_notify_device_ready (struct amdgpu_device *adev);void amdgpu_acpi_get_backlight_caps (struct amdgpu_dm_backlight_caps *caps); +bool amdgpu_acpi_should_gpu_reset (struct amdgpu_device *adev);void amdgpu_acpi_detect (void );#else static inline int amdgpu_acpi_init (struct amdgpu_device *adev) {return 0 ; }static inline void amdgpu_acpi_fini (struct amdgpu_device *adev) { } +static inline bool amdgpu_acpi_should_gpu_reset (struct amdgpu_device *adev) {return false; }static inline void amdgpu_acpi_detect (void ) { }static inline bool amdgpu_acpi_is_power_shift_control_supported (void ) {return false; } static inline int amdgpu_acpi_power_shift_control(struct amdgpu_device *adev,
@@ -1397,11 +1399,9 @@ static inline int amdgpu_acpi_smart_shif#if defined(CONFIG_ACPI ) && defined(CONFIG_SUSPEND )bool amdgpu_acpi_is_s3_active (struct amdgpu_device *adev); -bool amdgpu_acpi_should_gpu_reset (struct amdgpu_device *adev);bool amdgpu_acpi_is_s0ix_active (struct amdgpu_device *adev);#else static inline bool amdgpu_acpi_is_s0ix_active (struct amdgpu_device *adev) {return false; } -static inline bool amdgpu_acpi_should_gpu_reset (struct amdgpu_device *adev) {return false; }static inline bool amdgpu_acpi_is_s3_active (struct amdgpu_device *adev) {return false; }#endif
drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c +23 -18
53 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 206/224 riscv: mm: Fix incorrect ASID argument when flushing TLB
In reply to Greg Kroah-HartmanFrom: Dylan Jhong <[email protected]>
commit 9a801afd3eb95e1a89aba17321062df06fb49d98 upstream.
Currently, we pass the CONTEXTID instead of the ASID to the TLB flush function. We should only take the ASID field to prevent from touching the reserved bit field.
--- arch/riscv/include/asm/tlbflush.h | 2 ++ arch/riscv/mm/context.c | 2 +- arch/riscv/mm/tlbflush.c | 2 +- 3 files changed, 4 insertions(+), 2 deletions(-)
arch/riscv/include/asm/tlbflush.h +2 -0
@@ -12,6 +12,8 @@#include <asm/errata_list.h> #ifdef CONFIG_MMU +extern unsigned long asid_mask; +static inline void local_flush_tlb_all (void ) { __asm__ __volatile__ ("sfence.vma" : : :"memory" );
arch/riscv/mm/context.c +1 -1
@@ -22,7 +22,7 @@ DEFINE_STATIC_KEY_FALSE(use_asid_allocatstatic unsigned long asid_bits;static unsigned long num_asids; -static unsigned long asid_mask; +unsigned long asid_mask;static atomic_long_t current_version;
arch/riscv/mm/tlbflush.c +1 -1
@@ -42,7 +42,7 @@ static void __sbi_tlb_flush_range(struct/* check if the tlbflush needs to be sent to other CPUs */ broadcast =cpumask_any_but (cmask, cpuid) < nr_cpu_ids;if (static_branch_unlikely (&use_asid_allocator)) { -unsigned long asid =atomic_long_read (&mm->context.id); +unsigned long asid =atomic_long_read (&mm->context.id) & asid_mask;if (broadcast) {sbi_remote_sfence_vma_asid (cmask, start, size, asid);
Greg Kroah-Hartman
maintainerPATCH 207/224 riscv: Handle zicsr/zifencei issues between clang and binutils
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
commit e89c2e815e76471cb507bd95728bf26da7976430 upstream.
There are two related issues that appear in certain combinations with clang and GNU binutils.
The first occurs when a version of clang that supports zicsr or zifencei via '-march=' [1] (i.e, >= 17.x) is used in combination with a version of GNU binutils that do not recognize zicsr and zifencei in the '-march=' value (i.e., < 2.36):
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o
The second occurs when a version of clang that does not support zicsr or zifencei via '-march=' (i.e., <= 16.x) is used in combination with a version of GNU as that defaults to a newer ISA base spec, which requires specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >= 2.38):
../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode fence.i', extension zifencei' required
clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix build with binutils 2.38") (see [2] for additional information) but older versions of clang miss out on it because the cc-option check fails:
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
To resolve the first issue, only attempt to add zicsr and zifencei to the march string when using the GNU assembler 2.38 or newer, which is when the default ISA spec was updated, requiring these extensions to be specified explicitly. LLVM implements an older version of the base specification for all currently released versions, so these instructions are available as part of the 'i' extension. If LLVM's implementation is updated in the future, a CONFIG_AS_IS_LLVM condition can be added to CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.
To resolve the second issue, use version 2.2 of the base ISA spec when using an older version of clang that does not support zicsr or zifencei via '-march=', as that is the spec version most compatible with the one clang/LLVM implements and avoids the need to specify zicsr and zifencei explicitly due to still being a part of 'i'.
[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/[email protected]/
--- arch/riscv/Kconfig | 22 ++++++++++++++++++++++ arch/riscv/Makefile | 10 ++++++---- 2 files changed, 28 insertions(+), 4 deletions(-)
arch/riscv/Kconfig +22 -0
@@ -442,6 +442,28 @@ config TOOLCHAIN_HAS_ZIHINTPAUSE depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zihintpause) depends on LLD_VERSION >= 150000 || LD_VERSION >= 23600 +config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI + def_bool y + # https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc + depends on AS_IS_GNU && AS_VERSION >= 23800 + help + Newer binutils versions default to ISA spec version 20191213 which + moves some instructions from the I extension to the Zicsr and Zifencei + extensions. + +config TOOLCHAIN_NEEDS_OLD_ISA_SPEC + def_bool y + depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI + # https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16 + depends on CC_IS_CLANG && CLANG_VERSION < 170000 + help + Certain versions of clang do not support zicsr and zifencei via -march + but newer versions of binutils require it for the reasons noted in the + help text of CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. This + option causes an older ISA spec compatible with these older versions + of clang to be passed to GAS, which has the same result as passing zicsr + and zifencei to -march. + config FPU bool "FPU support" default y
arch/riscv/Makefile +6 -4
@@ -57,10 +57,12 @@ riscv-march-$(CONFIG_ARCH_RV64I) := rv64 riscv-march-$(CONFIG_FPU) := $(riscv-march-y)fd riscv-march-$(CONFIG_RISCV_ISA_C) := $(riscv-march-y)c -# Newer binutils versions default to ISA spec version 20191213 which moves some -# instructions from the I extension to the Zicsr and Zifencei extensions. -toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(riscv-march-y)_zicsr_zifencei) -riscv-march-$(toolchain-need-zicsr-zifencei) := $(riscv-march-y)_zicsr_zifencei +ifdef CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC +KBUILD_CFLAGS += -Wa,-misa-spec=2.2 +KBUILD_AFLAGS += -Wa,-misa-spec=2.2 +else +riscv-march-$(CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI) := $(riscv-march-y)_zicsr_zifencei +endif # Check if the toolchain supports Zicbom extension riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZICBOM) := $(riscv-march-y)_zicbom
Greg Kroah-Hartman
maintainerPATCH 208/224 tee: amdtee: fix race condition in amdtee_open_session
In reply to Greg Kroah-HartmanFrom: Rijo Thomas <[email protected]>
commit f8502fba45bd30e1a6a354d9d898bc99d1a11e6d upstream.
There is a potential race condition in amdtee_open_session that may lead to use-after-free. For instance, in amdtee_open_session() after sess->sess_mask is set, and before setting:
sess->session_info[i] = session_info;
if amdtee_close_session() closes this same session, then 'sess' data structure will be released, causing kernel panic when 'sess' is accessed within amdtee_open_session().
The solution is to set the bit sess->sess_mask as the last step in amdtee_open_session().
--- drivers/tee/amdtee/core.c | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-)
drivers/tee/amdtee/core.c +14 -15
@@ -267,35 +267,34 @@ int amdtee_open_session(struct tee_conte goto out; } +/* Open session with loaded TA */ +handle_open_session (arg, &session_info, param); +if (arg->ret !=TEEC_SUCCESS ) { +pr_err ("open_session failed %d\n" , arg->ret); +handle_unload_ta (ta_handle); +kref_put (&sess->refcount, destroy_session); + goto out; + } +/* Find an empty session index for the given TA */ spin_lock (&sess->lock); i =find_first_zero_bit (sess->sess_mask,TEE_NUM_SESSIONS ); -if (i <TEE_NUM_SESSIONS ) +if (i <TEE_NUM_SESSIONS ) { + sess->session_info[i] = session_info; +set_session_id (ta_handle, i, &arg->session);set_bit (i, sess->sess_mask); + }spin_unlock (&sess->lock);if (i >=TEE_NUM_SESSIONS ) {pr_err ("reached maximum session count %d\n" ,TEE_NUM_SESSIONS ); +handle_close_session (ta_handle, session_info);handle_unload_ta (ta_handle);kref_put (&sess->refcount, destroy_session); rc = -ENOMEM ; goto out; } -/* Open session with loaded TA */ -handle_open_session (arg, &session_info, param); -if (arg->ret !=TEEC_SUCCESS ) { -pr_err ("open_session failed %d\n" , arg->ret); -spin_lock (&sess->lock); -clear_bit (i, sess->sess_mask); -spin_unlock (&sess->lock); -handle_unload_ta (ta_handle); -kref_put (&sess->refcount, destroy_session); - goto out; - } - - sess->session_info[i] = session_info; -set_session_id (ta_handle, i, &arg->session); out:free_pages ((u64 )ta,get_order (ta_size));return rc;
Greg Kroah-Hartman
maintainerPATCH 209/224 firmware: arm_scmi: Fix device node validation for mailbox transport
In reply to Greg Kroah-HartmanFrom: Cristian Marussi <[email protected]>
commit 2ab4f4018cb6b8010ca5002c3bdc37783b5d28c2 upstream.
When mailboxes are used as a transport it is possible to setup the SCMI transport layer, depending on the underlying channels configuration, to use one or two mailboxes, associated, respectively, to one or two, distinct, shared memory areas: any other combination should be treated as invalid.
Add more strict checking of SCMI mailbox transport device node descriptors.
--- drivers/firmware/arm_scmi/mailbox.c | 37 ++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+)
drivers/firmware/arm_scmi/mailbox.c +37 -0
@@ -52,6 +52,39 @@ static bool mailbox_chan_available(struc "#mbox-cells", idx, NULL); } +static int mailbox_chan_validate (struct device *cdev) +{ +int num_mb, num_sh, ret =0 ; +struct device_node *np = cdev->of_node; + + num_mb =of_count_phandle_with_args (np,"mboxes" ,"#mbox-cells" ); + num_sh =of_count_phandle_with_args (np,"shmem" ,NULL ); +/* Bail out if mboxes and shmem descriptors are inconsistent */ +if (num_mb <=0 || num_sh >2 || num_mb != num_sh) { +dev_warn (cdev,"Invalid channel descriptor for '%s'\n" , +of_node_full_name (np)); +return -EINVAL ; + } + +if (num_sh >1 ) { +struct device_node *np_tx, *np_rx; + + np_tx =of_parse_phandle (np,"shmem" ,0 ); + np_rx =of_parse_phandle (np,"shmem" ,1 ); +/* SCMI Tx and Rx shared mem areas have to be distinct */ +if (!np_tx || !np_rx || np_tx == np_rx) { +dev_warn (cdev,"Invalid shmem descriptor for '%s'\n" , +of_node_full_name (np)); + ret = -EINVAL ; + } + +of_node_put (np_tx); +of_node_put (np_rx); + } + +return ret; +} +static int mailbox_chan_setup (struct scmi_chan_info *cinfo,struct device *dev,bool tx) {
@@ -64,6 +97,10 @@ static int mailbox_chan_setup(struct scmresource_size_t size;struct resource res; + ret =mailbox_chan_validate (cdev); +if (ret) +return ret; + smbox =devm_kzalloc (dev,sizeof (*smbox),GFP_KERNEL );if (!smbox)return -ENOMEM ;
Greg Kroah-Hartman
maintainerPATCH 210/224 arm64: dts: qcom: sc7280: Mark PCIe controller as cache coherent
In reply to Greg Kroah-HartmanFrom: Krishna chaitanya chundru <[email protected]>
commit 8a63441e83724fee1ef3fd37b237d40d90780766 upstream.
If the controller is not marked as cache coherent, then kernel will try to ensure coherency during dma-ops and that may cause data corruption. So, mark the PCIe node as dma-coherent as the devices on PCIe bus are cache coherent.
--- arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/boot/dts/qcom/sc7280.dtsi +2 -0
@@ -2077,6 +2077,8 @@ pinctrl-names = "default"; pinctrl-0 = <&pcie1_clkreq_n>; + dma-coherent; + iommus = <&apps_smmu 0x1c80 0x1>; iommu-map = <0x0 &apps_smmu 0x1c80 0x1>,
Greg Kroah-Hartman
maintainerPATCH 211/224 arm64: dts: qcom: sm8150: Fix the iommu mask used for PCIe controllers
In reply to Greg Kroah-HartmanFrom: Manivannan Sadhasivam <[email protected]>
commit 672a58fc7c477e59981653a11241566870fff852 upstream.
The iommu mask should be 0x3f as per Qualcomm internal documentation. Without the correct mask, the PCIe transactions from the endpoint will result in SMMU faults. Hence, fix it!
--- arch/arm64/boot/dts/qcom/sm8150.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm64/boot/dts/qcom/sm8150.dtsi +2 -2
@@ -1810,7 +1810,7 @@ "slave_q2a", "tbu"; - iommus = <&apps_smmu 0x1d80 0x7f>; + iommus = <&apps_smmu 0x1d80 0x3f>; iommu-map = <0x0 &apps_smmu 0x1d80 0x1>, <0x100 &apps_smmu 0x1d81 0x1>;
@@ -1909,7 +1909,7 @@ assigned-clocks = <&gcc GCC_PCIE_1_AUX_CLK>; assigned-clock-rates = <19200000>; - iommus = <&apps_smmu 0x1e00 0x7f>; + iommus = <&apps_smmu 0x1e00 0x3f>; iommu-map = <0x0 &apps_smmu 0x1e00 0x1>, <0x100 &apps_smmu 0x1e01 0x1>;
Greg Kroah-Hartman
maintainerPATCH 212/224 soc: qcom: llcc: Fix slice configuration values for SC8280XP
In reply to Greg Kroah-HartmanFrom: Abel Vesa <[email protected]>
commit 77bf4b3ed42e31d29b255fcd6530fb7a1e217e89 upstream.
The slice IDs for CVPFW, CPUSS1 and CPUWHT currently overflow the 32bit LLCC config registers, which means it is writing beyond the upper limit of the ATTR0_CFGn and ATTR1_CFGn range of registers. But the most obvious impact is the fact that the mentioned slices do not get configured at all, which will result in reduced performance. Fix that by using the slice ID values taken from the latest LLCC SC table.
--- drivers/soc/qcom/llcc-qcom.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/soc/qcom/llcc-qcom.c +3 -3
@@ -170,9 +170,9 @@ static const struct llcc_slice_config sc { LLCC_CVP, 28, 512, 3, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 }, { LLCC_APTCM, 30, 1024, 3, 1, 0x0, 0x1, 1, 0, 0, 1, 0, 0 }, { LLCC_WRCACHE, 31, 1024, 1, 1, 0xfff, 0x0, 0, 0, 0, 0, 1, 0 }, - { LLCC_CVPFW, 32, 512, 1, 0, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 }, - { LLCC_CPUSS1, 33, 2048, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 }, - { LLCC_CPUHWT, 36, 512, 1, 1, 0xfff, 0x0, 0, 0, 0, 0, 1, 0 }, + { LLCC_CVPFW, 17, 512, 1, 0, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 }, + { LLCC_CPUSS1, 3, 2048, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 }, + { LLCC_CPUHWT, 5, 512, 1, 1, 0xfff, 0x0, 0, 0, 0, 0, 1, 0 }, }; static const struct llcc_slice_config sdm845_data[] = {
Greg Kroah-Hartman
maintainerPATCH 213/224 mm/ksm: fix race with VMA iteration and mm_struct teardown
In reply to Greg Kroah-HartmanFrom: Liam R. Howlett <[email protected]>
commit 6db504ce55bdbc575723938fc480713c9183f6a2 upstream.
exit_mmap() will tear down the VMAs and maple tree with the mmap_lock held in write mode. Ensure that the maple tree is still valid by checking ksm_test_exit() after taking the mmap_lock in read mode, but before the for_each_vma() iterator dereferences a destroyed maple tree.
Since the maple tree is destroyed, the flags telling lockdep to check an external lock has been cleared. Skip the for_each_vma() iterator to avoid dereferencing a maple tree without the external lock flag, which would create a lockdep warning.
--- mm/ksm.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
mm/ksm.c +9 -2
@@ -960,9 +960,15 @@ static int unmerge_and_remove_all_rmap_i mm = mm_slot->slot.mm;mmap_read_lock (mm); + +/* +* Exit right away if mm is exiting to avoid lockdep issue in +* the maple tree +*/ +if (ksm_test_exit (mm)) + goto mm_exiting; +for_each_vma (vmi, vma) { -if (ksm_test_exit (mm)) -break ;if (!(vma->vm_flags &VM_MERGEABLE ) || !vma->anon_vma)continue ; err = unmerge_ksm_pages(vma,
@@ -971,6 +977,7 @@ static int unmerge_and_remove_all_rmap_i goto error; } +mm_exiting:remove_trailing_rmap_items (&mm_slot->rmap_list);mmap_read_unlock (mm);
Greg Kroah-Hartman
maintainerPATCH 214/224 bus: imx-weim: fix branch condition evaluates to a garbage value
In reply to Greg Kroah-HartmanFrom: Ivan Bornyakov <[email protected]>
commit 1adab2922c58e7ff4fa9f0b43695079402cce876 upstream.
If bus type is other than imx50_weim_devtype and have no child devices, variable 'ret' in function weim_parse_dt() will not be initialized, but will be used as branch condition and return value. Fix this by initializing 'ret' with 0.
This was discovered with help of clang-analyzer, but the situation is quite possible in real life.
--- drivers/bus/imx-weim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/bus/imx-weim.c +1 -1
@@ -204,8 +204,8 @@ static int weim_parse_dt(struct platformconst struct of_device_id *of_id =of_match_device (weim_id_table, &pdev->dev);const struct imx_weim_devtype *devtype = of_id->data; +int ret =0 , have_child =0 ;struct device_node *child; -int ret, have_child =0 ;struct weim_priv *priv;void __iomem *base;u32 reg;
Greg Kroah-Hartman
maintainerPATCH 215/224 i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer()
In reply to Greg Kroah-HartmanFrom: Wei Chen <[email protected]>
commit 92fbb6d1296f81f41f65effd7f5f8c0f74943d15 upstream.
The data->block[0] variable comes from user and is a number between 0-255. Without proper check, the variable may be very large to cause an out-of-bounds when performing memcpy in slimpro_i2c_blkwr.
Fix this bug by checking the value of writelen.
--- drivers/i2c/busses/i2c-xgene-slimpro.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/i2c/busses/i2c-xgene-slimpro.c +3 -0
@@ -308,6 +308,9 @@ static int slimpro_i2c_blkwr(struct slimu32 msg[3 ];int rc; +if (writelen >I2C_SMBUS_BLOCK_MAX ) +return -EINVAL ; +memcpy (ctx->dma_buffer, data, writelen); paddr =dma_map_single (ctx->dev, ctx->dma_buffer, writelen,DMA_TO_DEVICE );
Greg Kroah-Hartman
maintainerPATCH 216/224 dm stats: check for and propagate alloc_percpu failure
In reply to Greg Kroah-HartmanFrom: Jiasheng Jiang <[email protected]>
commit d3aa3e060c4a80827eb801fc448debc9daa7c46b upstream.
Check alloc_precpu()'s return value and return an error from dm_stats_init() if it fails. Update alloc_dev() to fail if dm_stats_init() does.
Otherwise, a NULL pointer dereference will occur in dm_stats_cleanup() even if dm-stats isn't being actively used.
--- drivers/md/dm-stats.c | 7 ++++++- drivers/md/dm-stats.h | 2 +- drivers/md/dm.c | 4 +++- 3 files changed, 10 insertions(+), 3 deletions(-)
drivers/md/dm-stats.c +6 -1
@@ -188,7 +188,7 @@ static int dm_stat_in_flight(struct dm_satomic_read (&shared->in_flight[WRITE ]); } -void dm_stats_init (struct dm_stats *stats) +int dm_stats_init (struct dm_stats *stats) {int cpu;struct dm_stats_last_position *last;
@@ -197,11 +197,16 @@ void dm_stats_init(struct dm_stats *statINIT_LIST_HEAD (&stats->list); stats->precise_timestamps = false; stats->last = alloc_percpu(struct dm_stats_last_position); +if (!stats->last) +return -ENOMEM ; +for_each_possible_cpu (cpu) { last =per_cpu_ptr (stats->last, cpu); last->last_sector = (sector_t )ULLONG_MAX ; last->last_rw =UINT_MAX ; } + +return 0 ; }void dm_stats_cleanup (struct dm_stats *stats)
drivers/md/dm-stats.h +1 -1
@@ -21,7 +21,7 @@ struct dm_stats_aux {unsigned long long duration_ns; }; -void dm_stats_init (struct dm_stats *st); +int dm_stats_init (struct dm_stats *st);void dm_stats_cleanup (struct dm_stats *st);struct mapped_device ;
drivers/md/dm.c +3 -1
@@ -2105,7 +2105,9 @@ static struct mapped_device *alloc_dev(iif (!md->pending_io) goto bad; -dm_stats_init (&md->stats); + r =dm_stats_init (&md->stats); +if (r <0 ) + goto bad;/* Populate the mapping, nobody knows we exist yet */ spin_lock (&_minor_lock);
Greg Kroah-Hartman
maintainerPATCH 217/224 dm crypt: add cond_resched() to dmcrypt_write()
In reply to Greg Kroah-HartmanFrom: Mikulas Patocka <[email protected]>
commit fb294b1c0ba982144ca467a75e7d01ff26304e2b upstream.
The loop in dmcrypt_write may be running for unbounded amount of time, thus we need cond_resched() in it.
This commit fixes the following warning:
[ 3391.153255][ C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897] ... [ 3391.387210][ C12] Call trace: [ 3391.390338][ C12] blk_attempt_bio_merge.part.6+0x38/0x158 [ 3391.395970][ C12] blk_attempt_plug_merge+0xc0/0x1b0 [ 3391.401085][ C12] blk_mq_submit_bio+0x398/0x550 [ 3391.405856][ C12] submit_bio_noacct+0x308/0x380 [ 3391.410630][ C12] dmcrypt_write+0x1e4/0x208 [dm_crypt] [ 3391.416005][ C12] kthread+0x130/0x138 [ 3391.419911][ C12] ret_from_fork+0x10/0x18
--- drivers/md/dm-crypt.c | 1 + 1 file changed, 1 insertion(+)
drivers/md/dm-crypt.c +1 -0
@@ -1933,6 +1933,7 @@ pop_from_list: io =crypt_io_from_node (rb_first (&write_tree));rb_erase (&io->rb_node, &write_tree);kcryptd_io_write (io); +cond_resched (); }while (!RB_EMPTY_ROOT (&write_tree));blk_finish_plug (&plug); }
Greg Kroah-Hartman
maintainerPATCH 218/224 dm crypt: avoid accessing uninitialized tasklet
In reply to Greg Kroah-HartmanFrom: Mike Snitzer <[email protected]>
commit d9a02e016aaf5a57fb44e9a5e6da8ccd3b9e2e70 upstream.
When neither "no_read_workqueue" nor "no_write_workqueue" are enabled, tasklet_trylock() in crypt_dec_pending() may still return false due to an uninitialized state, and dm-crypt will unnecessarily do io completion in io_queue workqueue instead of current context.
Fix this by adding an 'in_tasklet' flag to dm_crypt_io struct and initialize it to false in crypt_io_init(). Set this flag to true in kcryptd_queue_crypt() before calling tasklet_schedule(). If set crypt_dec_pending() will punt io completion to a workqueue.
This also nicely avoids the tasklet_trylock/unlock hack when tasklets aren't in use.
--- drivers/md/dm-crypt.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-)
drivers/md/dm-crypt.c +9 -6
@@ -71,7 +71,9 @@ struct dm_crypt_io {struct crypt_config *cc;struct bio *base_bio;u8 *integrity_metadata; -bool integrity_metadata_from_pool; + bool integrity_metadata_from_pool:1; + bool in_tasklet:1; +struct work_struct work;struct tasklet_struct tasklet;
@@ -1728,6 +1730,7 @@ static void crypt_io_init(struct dm_cryp io->ctx.r.req =NULL ; io->integrity_metadata =NULL ; io->integrity_metadata_from_pool = false; + io->in_tasklet = false;atomic_set (&io->io_pending,0 ); }
@@ -1773,14 +1776,13 @@ static void crypt_dec_pending(struct dm_* our tasklet. In this case we need to delay bio_endio() * execution to after the tasklet is done and dequeued. */ -if (tasklet_trylock (&io->tasklet)) { -tasklet_unlock (&io->tasklet); -bio_endio (base_bio); +if (io->in_tasklet) { +INIT_WORK (&io->work, kcryptd_io_bio_endio); +queue_work (cc->io_queue, &io->work);return ; } -INIT_WORK (&io->work, kcryptd_io_bio_endio); -queue_work (cc->io_queue, &io->work); +bio_endio (base_bio); }/*
@@ -2229,6 +2231,7 @@ static void kcryptd_queue_crypt(struct d* it is being executed with irqs disabled. */ if (in_hardirq () ||irqs_disabled ()) { + io->in_tasklet = true;tasklet_init (&io->tasklet, kcryptd_crypt_tasklet, (unsigned long )&io->work);tasklet_schedule (&io->tasklet);return ;
Greg Kroah-Hartman
maintainerPATCH 219/224 sched/fair: sanitize vruntime of entity being placed
In reply to Greg Kroah-HartmanFrom: Zhang Qiao <[email protected]>
commit 829c1651e9c4a6f78398d3e67651cef9bb6b42cc upstream.
When a scheduling entity is placed onto cfs_rq, its vruntime is pulled to the base level (around cfs_rq->min_vruntime), so that the entity doesn't gain extra boost when placed backwards.
However, if the entity being placed wasn't executed for a long time, its vruntime may get too far behind (e.g. while cfs_rq was executing a low-weight hog), which can inverse the vruntime comparison due to s64 overflow. This results in the entity being placed with its original vruntime way forwards, so that it will effectively never get to the cpu.
To prevent that, ignore the vruntime of the entity being placed if it didn't execute for much longer than the characteristic sheduler time scale.
--- kernel/sched/fair.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
kernel/sched/fair.c +13 -2
@@ -4640,6 +4640,7 @@ static void place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int initial) { u64 vruntime = cfs_rq->min_vruntime; +u64 sleep_time;/* * The 'current' period is already promised to the current tasks,
@@ -4669,8 +4670,18 @@ place_entity(struct cfs_rq *cfs_rq, stru vruntime -= thresh; } -/* ensure we never gain time by being placed backwards. */ - se->vruntime =max_vruntime (se->vruntime, vruntime); +/* +* Pull vruntime of the entity being placed to the base level of +* cfs_rq, to prevent boosting it if placed backwards. If the entity +* slept for a long time, don't even try to compare its vruntime with +* the base as it may be too far off and the comparison may get +* inversed due to s64 overflow. +*/ + sleep_time =rq_clock_task (rq_of (cfs_rq)) - se->exec_start; +if ((s64 )sleep_time >60LL *NSEC_PER_SEC ) + se->vruntime = vruntime; +else + se->vruntime =max_vruntime (se->vruntime, vruntime); }static void check_enqueue_throttle (struct cfs_rq *cfs_rq);
Greg Kroah-Hartman
maintainerPATCH 220/224 sched/fair: Sanitize vruntime of entity being migrated
In reply to Greg Kroah-HartmanFrom: Vincent Guittot <[email protected]>
commit a53ce18cacb477dd0513c607f187d16f0fa96f71 upstream.
Commit 829c1651e9c4 ("sched/fair: sanitize vruntime of entity being placed") fixes an overflowing bug, but ignore a case that se->exec_start is reset after a migration.
For fixing this case, we delay the reset of se->exec_start after placing the entity which se->exec_start to detect long sleeping task.
In order to take into account a possible divergence between the clock_task of 2 rqs, we increase the threshold to around 104 days.
--- kernel/sched/core.c | 3 ++ kernel/sched/fair.c | 53 ++++++++++++++++++++++++++++++++++++++++++---------- 2 files changed, 46 insertions(+), 10 deletions(-)
kernel/sched/core.c +3 -0
@@ -2082,6 +2082,9 @@ static inline void dequeue_task(struct rvoid activate_task (struct rq *rq,struct task_struct *p,int flags) { +if (task_on_rq_migrating (p)) + flags |=ENQUEUE_MIGRATED ; +enqueue_task (rq, p, flags); p->on_rq =TASK_ON_RQ_QUEUED ;
kernel/sched/fair.c +43 -10
82 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 221/224 drm/amdkfd: introduce dummy cache info for property asic
In reply to Greg Kroah-HartmanFrom: Prike Liang <[email protected]>
commit fd72e2cb2f9dd2734e8013b3e185a21f0d605d3e upstream.
This dummy cache info will enable kfd base function support.
--- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 53 +++++++++++++++++++++++++++++++++- 1 file changed, 52 insertions(+), 1 deletion(-)
drivers/gpu/drm/amd/amdkfd/kfd_crat.c +52 -1
@@ -891,6 +891,54 @@ static struct kfd_gpu_cache_info gc_10_3 }, }; +static struct kfd_gpu_cache_info dummy_cache_info[] = { + { +/* TCP L1 Cache per CU */ + .cache_size =16 , + .cache_level =1 , + .flags = (CRAT_CACHE_FLAGS_ENABLED | +CRAT_CACHE_FLAGS_DATA_CACHE | +CRAT_CACHE_FLAGS_SIMD_CACHE ), + .num_cu_shared =1 , + }, + { +/* Scalar L1 Instruction Cache per SQC */ + .cache_size =32 , + .cache_level =1 , + .flags = (CRAT_CACHE_FLAGS_ENABLED | +CRAT_CACHE_FLAGS_INST_CACHE | +CRAT_CACHE_FLAGS_SIMD_CACHE ), + .num_cu_shared =2 , + }, + { +/* Scalar L1 Data Cache per SQC */ + .cache_size =16 , + .cache_level =1 , + .flags = (CRAT_CACHE_FLAGS_ENABLED | +CRAT_CACHE_FLAGS_DATA_CACHE | +CRAT_CACHE_FLAGS_SIMD_CACHE ), + .num_cu_shared =2 , + }, + { +/* GL1 Data Cache per SA */ + .cache_size =128 , + .cache_level =1 , + .flags = (CRAT_CACHE_FLAGS_ENABLED | +CRAT_CACHE_FLAGS_DATA_CACHE | +CRAT_CACHE_FLAGS_SIMD_CACHE ), + .num_cu_shared =6 , + }, + { +/* L2 Data Cache per GPU (Total Tex Cache) */ + .cache_size =2048 , + .cache_level =2 , + .flags = (CRAT_CACHE_FLAGS_ENABLED | +CRAT_CACHE_FLAGS_DATA_CACHE | +CRAT_CACHE_FLAGS_SIMD_CACHE ), + .num_cu_shared =6 , + }, +}; +static void kfd_populated_cu_info_cpu (struct kfd_topology_device *dev,struct crat_subtype_computeunit *cu) {
@@ -1630,7 +1678,10 @@ static int kfd_fill_gpu_cache_info(struckfd_fill_gpu_cache_info_from_gfx_config (kdev, pcache_info);break ;default : -return -EINVAL ; + pcache_info = dummy_cache_info; + num_of_cache_types =ARRAY_SIZE (dummy_cache_info); +pr_warn ("dummy cache info is used temporarily and real cache info need update later.\n" ); +break ; } }
Greg Kroah-Hartman
maintainerPATCH 222/224 drm/amdkfd: Fix the warning of array-index-out-of-bounds
In reply to Greg Kroah-HartmanFrom: Ma Jun <[email protected]>
commit c0cc999f3c32e65a7c88fb323893ddf897b24488 upstream.
For some GPUs with more CUs, the original sibling_map[32] in struct crat_subtype_cache is not enough
to save the cache information when create the VCRAT table, so skip filling the struct crat_subtype_cache info instead fill struct kfd_cache_properties directly to fix this problem.
--- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 312 +++--------------------------- drivers/gpu/drm/amd/amdkfd/kfd_crat.h | 12 + drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 245 ++++++++++++++++++++++- drivers/gpu/drm/amd/amdkfd/kfd_topology.h | 5 4 files changed, 282 insertions(+), 292 deletions(-)
drivers/gpu/drm/amd/amdkfd/kfd_crat.c +34 -278
@@ -50,16 +50,6 @@ static inline unsigned int get_and_inc_greturn current_id; } -/* Static table to describe GPU Cache information */ -struct kfd_gpu_cache_info { -uint32_t cache_size; -uint32_t cache_level; -uint32_t flags; -/* Indicates how many Compute Units share this cache -* within a SA. Value = 1 indicates the cache is not shared -*/ -uint32_t num_cu_shared; -};static struct kfd_gpu_cache_info kaveri_cache_info[] = { {
@@ -1119,9 +1109,13 @@ static int kfd_parse_subtype_cache(struc props->cachelines_per_tag = cache->lines_per_tag; props->cache_assoc = cache->associativity; props->cache_latency = cache->cache_latency; +memcpy (props->sibling_map, cache->sibling_map,sizeof (props->sibling_map)); +/* set the sibling_map_size as 32 for CRAT from ACPI */ + props->sibling_map_size =CRAT_SIBLINGMAP_SIZE ; +if (cache->flags &CRAT_CACHE_FLAGS_DATA_CACHE ) props->cache_type |=HSA_CACHE_TYPE_DATA ;if (cache->flags &CRAT_CACHE_FLAGS_INST_CACHE )
@@ -1339,125 +1333,6 @@ err:return ret; } -/* Helper function. See kfd_fill_gpu_cache_info for parameter description */ -static int fill_in_l1_pcache (struct crat_subtype_cache *pcache, -struct kfd_gpu_cache_info *pcache_info, -struct kfd_cu_info *cu_info, -int mem_available, -int cu_bitmask, -int cache_type,unsigned int cu_processor_id, -int cu_block) -{ -unsigned int cu_sibling_map_mask; -int first_active_cu; - -/* First check if enough memory is available */ -if (sizeof (struct crat_subtype_cache ) > mem_available) -return -ENOMEM ; - - cu_sibling_map_mask = cu_bitmask; - cu_sibling_map_mask >>= cu_block; - cu_sibling_map_mask &= - ((1 << pcache_info[cache_type].num_cu_shared) -1 ); - first_active_cu =ffs (cu_sibling_map_mask); - -/* CU could be inactive. In case of shared cache find the first active -* CU. and incase of non-shared cache check if the CU is inactive. If -* inactive active skip it -*/ -if (first_active_cu) { -memset (pcache,0 ,sizeof (struct crat_subtype_cache )); - pcache->type =CRAT_SUBTYPE_CACHE_AFFINITY ; - pcache->length =sizeof (struct crat_subtype_cache ); - pcache->flags = pcache_info[cache_type].flags; - pcache->processor_id_low = cu_processor_id - + (first_active_cu -1 ); - pcache->cache_level = pcache_info[cache_type].cache_level; - pcache->cache_size = pcache_info[cache_type].cache_size; - -/* Sibling map is w.r.t processor_id_low, so shift out -* inactive CU -*/ - cu_sibling_map_mask = - cu_sibling_map_mask >> (first_active_cu -1 ); - - pcache->sibling_map[0 ] = (uint8_t )(cu_sibling_map_mask &0xFF ); - pcache->sibling_map[1 ] = - (uint8_t )((cu_sibling_map_mask >>8 ) &0xFF ); - pcache->sibling_map[2 ] = - (uint8_t )((cu_sibling_map_mask >>16 ) &0xFF ); - pcache->sibling_map[3 ] = - (uint8_t )((cu_sibling_map_mask >>24 ) &0xFF ); -return 0 ; - } -return 1 ; -} - -/* Helper function. See kfd_fill_gpu_cache_info for parameter description */ -static int fill_in_l2_l3_pcache (struct crat_subtype_cache *pcache, -struct kfd_gpu_cache_info *pcache_info, -struct kfd_cu_info *cu_info, -int mem_available, -int cache_type,unsigned int cu_processor_id) -{ -unsigned int cu_sibling_map_mask; -int first_active_cu; -int i, j, k; - -/* First check if enough memory is available */ -if (sizeof (struct crat_subtype_cache ) > mem_available) -return -ENOMEM ; - - cu_sibling_map_mask = cu_info->cu_bitmap[0 ][0 ]; - cu_sibling_map_mask &= - ((1 << pcache_info[cache_type].num_cu_shared) -1 ); - first_active_cu =ffs (cu_sibling_map_mask); - -/* CU could be inactive. In case of shared cache find the first active -* CU. and incase of non-shared cache check if the CU is inactive. If -* inactive active skip it -*/ -if (first_active_cu) { -memset (pcache,0 ,sizeof (struct crat_subtype_cache )); - pcache->type =CRAT_SUBTYPE_CACHE_AFFINITY ; - pcache->length =sizeof (struct crat_subtype_cache ); - pcache->flags = pcache_info[cache_type].flags; - pcache->processor_id_low = cu_processor_id - + (first_active_cu -1 ); - pcache->cache_level = pcache_info[cache_type].cache_level; - pcache->cache_size = pcache_info[cache_type].cache_size; - -/* Sibling map is w.r.t processor_id_low, so shift out -* inactive CU -*/ - cu_sibling_map_mask = - cu_sibling_map_mask >> (first_active_cu -1 ); - k =0 ; -for (i =0 ; i < cu_info->num_shader_engines; i++) { -for (j =0 ; j < cu_info->num_shader_arrays_per_engine; - j++) { - pcache->sibling_map[k] = - (uint8_t )(cu_sibling_map_mask &0xFF ); - pcache->sibling_map[k+1 ] = - (uint8_t )((cu_sibling_map_mask >>8 ) &0xFF ); - pcache->sibling_map[k+2 ] = - (uint8_t )((cu_sibling_map_mask >>16 ) &0xFF ); - pcache->sibling_map[k+3 ] = - (uint8_t )((cu_sibling_map_mask >>24 ) &0xFF ); - k +=4 ; - cu_sibling_map_mask = - cu_info->cu_bitmap[i %4 ][j + i /4 ]; - cu_sibling_map_mask &= ( - (1 << pcache_info[cache_type].num_cu_shared) - -1 ); - } - } -return 0 ; - } -return 1 ; -} - -#define KFD_MAX_CACHE_TYPES 6static int kfd_fill_gpu_cache_info_from_gfx_config (struct kfd_dev *kdev,struct kfd_gpu_cache_info *pcache_info)
@@ -1531,231 +1406,133 @@ static int kfd_fill_gpu_cache_info_from_return i; } -/* kfd_fill_gpu_cache_info - Fill GPU cache info using kfd_gpu_cache_info -* tables -* -* @kdev - [IN] GPU device -* @gpu_processor_id - [IN] GPU processor ID to which these caches -* associate -* @available_size - [IN] Amount of memory available in pcache -* @cu_info - [IN] Compute Unit info obtained from KGD -* @pcache - [OUT] memory into which cache data is to be filled in. -* @size_filled - [OUT] amount of data used up in pcache. -* @num_of_entries - [OUT] number of caches added -*/ -static int kfd_fill_gpu_cache_info (struct kfd_dev *kdev, -int gpu_processor_id, -int available_size, -struct kfd_cu_info *cu_info, -struct crat_subtype_cache *pcache, -int *size_filled, -int *num_of_entries) +int kfd_get_gpu_cache_info (struct kfd_dev *kdev,struct kfd_gpu_cache_info **pcache_info) { -struct kfd_gpu_cache_info *pcache_info; -struct kfd_gpu_cache_info cache_info[KFD_MAX_CACHE_TYPES ];int num_of_cache_types =0 ; -int i, j, k; -int ct =0 ; -int mem_available = available_size; -unsigned int cu_processor_id; -int ret; -unsigned int num_cu_shared;switch (kdev->adev->asic_type) {case CHIP_KAVERI : - pcache_info = kaveri_cache_info; + *pcache_info = kaveri_cache_info; num_of_cache_types =ARRAY_SIZE (kaveri_cache_info);break ;case CHIP_HAWAII : - pcache_info = hawaii_cache_info; + *pcache_info = hawaii_cache_info; num_of_cache_types =ARRAY_SIZE (hawaii_cache_info);break ;case CHIP_CARRIZO : - pcache_info = carrizo_cache_info; + *pcache_info = carrizo_cache_info; num_of_cache_types =ARRAY_SIZE (carrizo_cache_info);break ;case CHIP_TONGA : - pcache_info = tonga_cache_info; + *pcache_info = tonga_cache_info; num_of_cache_types =ARRAY_SIZE (tonga_cache_info);break ;case CHIP_FIJI : - pcache_info = fiji_cache_info; + *pcache_info = fiji_cache_info; num_of_cache_types =ARRAY_SIZE (fiji_cache_info);break ;case CHIP_POLARIS10 : - pcache_info = polaris10_cache_info; + *pcache_info = polaris10_cache_info; num_of_cache_types =ARRAY_SIZE (polaris10_cache_info);break ;case CHIP_POLARIS11 : - pcache_info = polaris11_cache_info; + *pcache_info = polaris11_cache_info; num_of_cache_types =ARRAY_SIZE (polaris11_cache_info);break ;case CHIP_POLARIS12 : - pcache_info = polaris12_cache_info; + *pcache_info = polaris12_cache_info; num_of_cache_types =ARRAY_SIZE (polaris12_cache_info);break ;case CHIP_VEGAM : - pcache_info = vegam_cache_info; + *pcache_info = vegam_cache_info; num_of_cache_types =ARRAY_SIZE (vegam_cache_info);break ;default :switch (KFD_GC_VERSION (kdev)) {case IP_VERSION (9 ,0 ,1 ): - pcache_info = vega10_cache_info; + *pcache_info = vega10_cache_info; num_of_cache_types =ARRAY_SIZE (vega10_cache_info);break ;case IP_VERSION (9 ,2 ,1 ): - pcache_info = vega12_cache_info; + *pcache_info = vega12_cache_info; num_of_cache_types =ARRAY_SIZE (vega12_cache_info);break ;case IP_VERSION (9 ,4 ,0 ):case IP_VERSION (9 ,4 ,1 ): - pcache_info = vega20_cache_info; + *pcache_info = vega20_cache_info; num_of_cache_types =ARRAY_SIZE (vega20_cache_info);break ;case IP_VERSION (9 ,4 ,2 ): - pcache_info = aldebaran_cache_info; + *pcache_info = aldebaran_cache_info; num_of_cache_types =ARRAY_SIZE (aldebaran_cache_info);break ;case IP_VERSION (9 ,1 ,0 ):case IP_VERSION (9 ,2 ,2 ): - pcache_info = raven_cache_info; + *pcache_info = raven_cache_info; num_of_cache_types =ARRAY_SIZE (raven_cache_info);break ;case IP_VERSION (9 ,3 ,0 ): - pcache_info = renoir_cache_info; + *pcache_info = renoir_cache_info; num_of_cache_types =ARRAY_SIZE (renoir_cache_info);break ;case IP_VERSION (10 ,1 ,10 ):case IP_VERSION (10 ,1 ,2 ):case IP_VERSION (10 ,1 ,3 ):case IP_VERSION (10 ,1 ,4 ): - pcache_info = navi10_cache_info; + *pcache_info = navi10_cache_info; num_of_cache_types =ARRAY_SIZE (navi10_cache_info);break ;case IP_VERSION (10 ,1 ,1 ): - pcache_info = navi14_cache_info; + *pcache_info = navi14_cache_info; num_of_cache_types =ARRAY_SIZE (navi14_cache_info);break ;case IP_VERSION (10 ,3 ,0 ): - pcache_info = sienna_cichlid_cache_info; + *pcache_info = sienna_cichlid_cache_info; num_of_cache_types =ARRAY_SIZE (sienna_cichlid_cache_info);break ;case IP_VERSION (10 ,3 ,2 ): - pcache_info = navy_flounder_cache_info; + *pcache_info = navy_flounder_cache_info; num_of_cache_types =ARRAY_SIZE (navy_flounder_cache_info);break ;case IP_VERSION (10 ,3 ,4 ): - pcache_info = dimgrey_cavefish_cache_info; + *pcache_info = dimgrey_cavefish_cache_info; num_of_cache_types =ARRAY_SIZE (dimgrey_cavefish_cache_info);break ;case IP_VERSION (10 ,3 ,1 ): - pcache_info = vangogh_cache_info; + *pcache_info = vangogh_cache_info; num_of_cache_types =ARRAY_SIZE (vangogh_cache_info);break ;case IP_VERSION (10 ,3 ,5 ): - pcache_info = beige_goby_cache_info; + *pcache_info = beige_goby_cache_info; num_of_cache_types =ARRAY_SIZE (beige_goby_cache_info);break ;case IP_VERSION (10 ,3 ,3 ): - pcache_info = yellow_carp_cache_info; + *pcache_info = yellow_carp_cache_info; num_of_cache_types =ARRAY_SIZE (yellow_carp_cache_info);break ;case IP_VERSION (10 ,3 ,6 ): - pcache_info = gc_10_3_6_cache_info; + *pcache_info = gc_10_3_6_cache_info; num_of_cache_types =ARRAY_SIZE (gc_10_3_6_cache_info);break ;case IP_VERSION (10 ,3 ,7 ): - pcache_info = gfx1037_cache_info; + *pcache_info = gfx1037_cache_info; num_of_cache_types =ARRAY_SIZE (gfx1037_cache_info);break ;case IP_VERSION (11 ,0 ,0 ):case IP_VERSION (11 ,0 ,1 ):case IP_VERSION (11 ,0 ,2 ):case IP_VERSION (11 ,0 ,3 ): - pcache_info = cache_info; num_of_cache_types = -kfd_fill_gpu_cache_info_from_gfx_config (kdev, pcache_info); +kfd_fill_gpu_cache_info_from_gfx_config (kdev, *pcache_info);break ;default : - pcache_info = dummy_cache_info; + *pcache_info = dummy_cache_info; num_of_cache_types =ARRAY_SIZE (dummy_cache_info);pr_warn ("dummy cache info is used temporarily and real cache info need update later.\n" );break ; } } - - *size_filled =0 ; - *num_of_entries =0 ; - -/* For each type of cache listed in the kfd_gpu_cache_info table, -* go through all available Compute Units. -* The [i,j,k] loop will -* if kfd_gpu_cache_info.num_cu_shared = 1 -* will parse through all available CU -* If (kfd_gpu_cache_info.num_cu_shared != 1) -* then it will consider only one CU from -* the shared unit -*/ - -for (ct =0 ; ct < num_of_cache_types; ct++) { - cu_processor_id = gpu_processor_id; -if (pcache_info[ct].cache_level ==1 ) { -for (i =0 ; i < cu_info->num_shader_engines; i++) { -for (j =0 ; j < cu_info->num_shader_arrays_per_engine; j++) { -for (k =0 ; k < cu_info->num_cu_per_sh; - k += pcache_info[ct].num_cu_shared) { - ret =fill_in_l1_pcache (pcache, - pcache_info, - cu_info, - mem_available, - cu_info->cu_bitmap[i %4 ][j + i /4 ], - ct, - cu_processor_id, - k); - -if (ret <0 ) -break ; - -if (!ret) { - pcache++; - (*num_of_entries)++; - mem_available -=sizeof (*pcache); - (*size_filled) +=sizeof (*pcache); - } - -/* Move to next CU block */ - num_cu_shared = ((k + pcache_info[ct].num_cu_shared) <= - cu_info->num_cu_per_sh) ? - pcache_info[ct].num_cu_shared : - (cu_info->num_cu_per_sh - k); - cu_processor_id += num_cu_shared; - } - } - } - }else { - ret =fill_in_l2_l3_pcache (pcache, - pcache_info, - cu_info, - mem_available, - ct, - cu_processor_id); - -if (ret <0 ) -break ; - -if (!ret) { - pcache++; - (*num_of_entries)++; - mem_available -=sizeof (*pcache); - (*size_filled) +=sizeof (*pcache); - } - } - } - -pr_debug ("Added [%d] GPU cache entries\n" , *num_of_entries); - -return 0 ; +return num_of_cache_types; }static bool kfd_ignore_crat (void )
@@ -2314,8 +2091,6 @@ static int kfd_create_vcrat_image_gpu(vostruct kfd_cu_info cu_info;int avail_size = *size;uint32_t total_num_of_cu; -int num_of_cache_entries =0 ; -int cache_mem_filled =0 ;uint32_t nid =0 ;int ret =0 ;
@@ -2416,31 +2191,12 @@ static int kfd_create_vcrat_image_gpu(vo crat_table->length +=sizeof (struct crat_subtype_memory ); crat_table->total_entries++; -/* TODO: Fill in cache information. This information is NOT readily -* available in KGD -*/ - sub_type_hdr = (typeof (sub_type_hdr))((char *)sub_type_hdr + - sub_type_hdr->length); - ret =kfd_fill_gpu_cache_info (kdev, cu->processor_id_low, - avail_size, - &cu_info, - (struct crat_subtype_cache *)sub_type_hdr, - &cache_mem_filled, - &num_of_cache_entries); - -if (ret <0 ) -return ret; - - crat_table->length += cache_mem_filled; - crat_table->total_entries += num_of_cache_entries; - avail_size -= cache_mem_filled; -/* Fill in Subtype: IO_LINKS * Only direct links are added here which is Link from GPU to * its NUMA node. Indirect links are added by userspace. */ sub_type_hdr = (typeof (sub_type_hdr))((char *)sub_type_hdr + - cache_mem_filled); + sub_type_hdr->length); ret =kfd_fill_gpu_direct_io_link_to_cpu (&avail_size, kdev, (struct crat_subtype_iolink *)sub_type_hdr, proximity_domain);
drivers/gpu/drm/amd/amdkfd/kfd_crat.h +12 -0
@@ -317,6 +317,18 @@ struct cdit_header {struct kfd_dev ; +/* Static table to describe GPU Cache information */ +struct kfd_gpu_cache_info { +uint32_t cache_size; +uint32_t cache_level; +uint32_t flags; +/* Indicates how many Compute Units share this cache +* within a SA. Value = 1 indicates the cache is not shared +*/ +uint32_t num_cu_shared; +}; +int kfd_get_gpu_cache_info (struct kfd_dev *kdev,struct kfd_gpu_cache_info **pcache_info); +int kfd_create_crat_image_acpi (void **crat_image,size_t *size);void kfd_destroy_crat_image (void *crat_image); int kfd_parse_crat_table(void *crat_image, struct list_head *device_list,
drivers/gpu/drm/amd/amdkfd/kfd_topology.c +232 -13
309 lines not on this page · raw message
drivers/gpu/drm/amd/amdkfd/kfd_topology.h +4 -1
@@ -80,6 +80,8 @@ struct kfd_mem_properties {struct attribute attr; }; +#define CACHE_SIBLINGMAP_SIZE 64 +struct kfd_cache_properties {struct list_head list;uint32_t processor_id_low;
@@ -90,10 +92,11 @@ struct kfd_cache_properties {uint32_t cache_assoc;uint32_t cache_latency;uint32_t cache_type; -uint8_t sibling_map[CRAT_SIBLINGMAP_SIZE ]; +uint8_t sibling_map[CACHE_SIBLINGMAP_SIZE ];struct kfd_dev *gpu;struct kobject *kobj;struct attribute attr; +uint32_t sibling_map_size; };struct kfd_iolink_properties {
Greg Kroah-Hartman
maintainerPATCH 223/224 drm/amdkfd: add GC 11.0.4 KFD support
In reply to Greg Kroah-HartmanFrom: Yifan Zhang <[email protected]>
commit 88c21c2b56aa21dd34290d43ada74033dc3bfe35 upstream.
Add initial support for GC 11.0.4 in KFD compute driver.
--- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 1 + drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 ++ 2 files changed, 3 insertions(+)
drivers/gpu/drm/amd/amdkfd/kfd_crat.c +1 -0
@@ -1522,6 +1522,7 @@ int kfd_get_gpu_cache_info(struct kfd_decase IP_VERSION (11 ,0 ,1 ):case IP_VERSION (11 ,0 ,2 ):case IP_VERSION (11 ,0 ,3 ): +case IP_VERSION (11 ,0 ,4 ): num_of_cache_types =kfd_fill_gpu_cache_info_from_gfx_config (kdev, *pcache_info);break ;
drivers/gpu/drm/amd/amdkfd/kfd_device.c +2 -0
@@ -154,6 +154,7 @@ static void kfd_device_info_set_event_incase IP_VERSION (11 ,0 ,1 ):case IP_VERSION (11 ,0 ,2 ):case IP_VERSION (11 ,0 ,3 ): +case IP_VERSION (11 ,0 ,4 ): kfd->device_info.event_interrupt_class = &event_interrupt_class_v11;break ;default :
@@ -396,6 +397,7 @@ struct kfd_dev *kgd2kfd_probe(struct amd f2g = &gfx_v11_kfd2kgd;break ;case IP_VERSION (11 ,0 ,1 ): +case IP_VERSION (11 ,0 ,4 ): gfx_target_version =110003 ; f2g = &gfx_v11_kfd2kgd;break ;
Greg Kroah-Hartman
maintainerPATCH 224/224 drm/amdkfd: Fix the memory overrun
In reply to Greg Kroah-HartmanFrom: Ma Jun <[email protected]>
commit 4cc16d64b6cdb179a26fb389cae9dce788e88f5d upstream.
Fix the memory overrun issue caused by wrong array size.
Addresses-Coverity-ID: 1527133 ("Memory - corruptions")
--- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/amdkfd/kfd_crat.c +1 -1
@@ -1111,7 +1111,7 @@ static int kfd_parse_subtype_cache(struc props->cache_latency = cache->cache_latency;memcpy (props->sibling_map, cache->sibling_map, -sizeof (props->sibling_map)); +CRAT_SIBLINGMAP_SIZE );/* set the sibling_map_size as 32 for CRAT from ACPI */ props->sibling_map_size =CRAT_SIBLINGMAP_SIZE ;
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.22 release. There are 224 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 Thu, 30 Mar 2023 14:25:33 +0000. Anything received after that time might be too late.
Hi Greg
6.1.22-rc1
compiles, boots and runs here on x86_64
(AMD Ryzen 5 PRO 4650G, Slackware64-15.0)
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.22 release. There are 224 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 Thu, 30 Mar 2023 14:25:33 +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.1.22-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Hi Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.22 release. There are 224 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 Thu, 30 Mar 2023 14:25:33 +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.1.22-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
6.1.22-rc1 tested.
x86_64
Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.
Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P, arch linux)
Thanks
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.22 release. There are 224 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.2.0).
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Hello Greg,
Quoted 10 lines
From: Greg Kroah-Hartman <[email protected]>
Sent: 28 March 2023 15:40This is the start of the stable review cycle for the 6.1.22 release. There are 224 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 Thu, 30 Mar 2023 14:25:33 +0000. Anything received after that time might be too late.
CIP configurations built and booted with Linux 6.1.22-rc1 (e6bbee2ba76f):
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/pipelines/820595007
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/commits/linux-6.1.y
Kind regards, Chris
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.22 release. There are 224 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 Thu, 30 Mar 2023 14:25:33 +0000. Anything received after that time might be too late.
Hi Greg,
6.1.22-rc1 tested.
Run tested on:
- Allwinner H6 (Tanix TX6)
- Intel Alder Lake x86_64 (nuc12 i7-1260P)
In addition - build tested for:
- Allwinner A64
- Allwinner H3
- Allwinner H5
- NXP iMX6
- NXP iMX8
- Qualcomm Dragonboard
- Rockchip RK3288
- Rockchip RK3328
- Rockchip RK3399pro
- Samsung Exynos
--
Rudi
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.22 release. There are 224 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.
Looks grand on our RISC-V stuff, thanks.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.22 release. There are 224 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 Thu, 30 Mar 2023 14:25:33 +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.1.22-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.1:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
130 tests: 130 pass, 0 failLinux version: 6.1.22-rc1-ge6bbee2ba76f
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-a04Jon
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.22 release. There are 224 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 Thu, 30 Mar 2023 14:25:33 +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.1.22-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.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.1.22-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-6.1.y
* git commit: e6bbee2ba76fd6c97025903e3b04b1461f02e8af
* git describe: v6.1.21-225-ge6bbee2ba76f
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.21-225-ge6bbee2ba76f
## Test Regressions (compared to v6.1.21)
## Metric Regressions (compared to v6.1.21)
## Test Fixes (compared to v6.1.21)
## Metric Fixes (compared to v6.1.21)
## Test result summary
total: 164164, pass: 145146, fail: 4467, skip: 14236, xfail: 315
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 149 total, 148 passed, 1 failed
* arm64: 51 total, 50 passed, 1 failed
* i386: 39 total, 36 passed, 3 failed
* mips: 30 total, 28 passed, 2 failed
* parisc: 8 total, 8 passed, 0 failed
* powerpc: 38 total, 36 passed, 2 failed
* riscv: 16 total, 15 passed, 1 failed
* s390: 16 total, 16 passed, 0 failed
* sh: 14 total, 12 passed, 2 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 44 total, 44 passed, 0 failed
## Test suites summary
* boot
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* 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-ftrace
* 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-net-mptcp
* 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-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
* perf
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.22 release. There are 224 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 Thu, 30 Mar 2023 14:25:33 +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.1.22-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.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.1.22 release. There are 224 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 Thu, 30 Mar 2023 14:25:33 +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.1.22-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.1.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.1.22 release. There are 224 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 Thu, 30 Mar 2023 14:25:33 +0000. Anything received after that time might be too late.
Build results:
total: 155 pass: 155 fail: 0 Qemu test results: total: 519 pass: 519 fail: 0
Guenter