--- /dev/null
+From 90d74fdbd8059bf041ac797092c9b1d461555280 Mon Sep 17 00:00:00 2001
+From: Christoffer Sandberg <cs@tuxedo.de>
+Date: Wed, 17 Aug 2022 15:51:44 +0200
+Subject: ALSA: hda/realtek: Add quirk for Clevo NS50PU, NS70PU
+
+From: Christoffer Sandberg <cs@tuxedo.de>
+
+commit 90d74fdbd8059bf041ac797092c9b1d461555280 upstream.
+
+Fixes headset microphone detection on Clevo NS50PU and NS70PU.
+
+Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
+Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220817135144.34103-1-wse@tuxedocomputers.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -9034,6 +9034,7 @@ static const struct snd_pci_quirk alc269
+ SND_PCI_QUIRK(0x1558, 0x70f4, "Clevo NH77EPY", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1558, 0x70f6, "Clevo NH77DPQ-Y", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1558, 0x7716, "Clevo NS50PU", ALC256_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
++ SND_PCI_QUIRK(0x1558, 0x7717, "Clevo NS70PU", ALC256_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1558, 0x7718, "Clevo L140PU", ALC256_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1558, 0x8228, "Clevo NR40BU", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1558, 0x8520, "Clevo NH50D[CD]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE),
--- /dev/null
+From 9be080edcca330be4af06b19916c35227891e8bc Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Amadeusz=20S=C5=82awi=C5=84ski?=
+ <amadeuszx.slawinski@linux.intel.com>
+Date: Wed, 17 Aug 2022 14:49:24 +0200
+Subject: ALSA: info: Fix llseek return value when using callback
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
+
+commit 9be080edcca330be4af06b19916c35227891e8bc upstream.
+
+When using callback there was a flow of
+
+ ret = -EINVAL
+ if (callback) {
+ offset = callback();
+ goto out;
+ }
+ ...
+ offset = some other value in case of no callback;
+ ret = offset;
+out:
+ return ret;
+
+which causes the snd_info_entry_llseek() to return -EINVAL when there is
+callback handler. Fix this by setting "ret" directly to callback return
+value before jumping to "out".
+
+Fixes: 73029e0ff18d ("ALSA: info - Implement common llseek for binary mode")
+Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20220817124924.3974577-1-amadeuszx.slawinski@linux.intel.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/core/info.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/sound/core/info.c
++++ b/sound/core/info.c
+@@ -111,9 +111,9 @@ static loff_t snd_info_entry_llseek(stru
+ entry = data->entry;
+ mutex_lock(&entry->access);
+ if (entry->c.ops->llseek) {
+- offset = entry->c.ops->llseek(entry,
+- data->file_private_data,
+- file, offset, orig);
++ ret = entry->c.ops->llseek(entry,
++ data->file_private_data,
++ file, offset, orig);
+ goto out;
+ }
+
--- /dev/null
+From d3122bf9aa4c974f5e2c0112f799757b3a2779da Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Date: Fri, 12 Aug 2022 02:29:53 +0900
+Subject: ata: libata-eh: Add missing command name
+
+From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+
+commit d3122bf9aa4c974f5e2c0112f799757b3a2779da upstream.
+
+Add the missing command name for ATA_CMD_NCQ_NON_DATA to
+ata_get_cmd_name().
+
+Fixes: 661ce1f0c4a6 ("libata/libsas: Define ATA_CMD_NCQ_NON_DATA")
+Cc: stable@vger.kernel.org
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Reviewed-by: Hannes Reinecke <hare@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/ata/libata-eh.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/ata/libata-eh.c
++++ b/drivers/ata/libata-eh.c
+@@ -2130,6 +2130,7 @@ const char *ata_get_cmd_descript(u8 comm
+ { ATA_CMD_WRITE_QUEUED_FUA_EXT, "WRITE DMA QUEUED FUA EXT" },
+ { ATA_CMD_FPDMA_READ, "READ FPDMA QUEUED" },
+ { ATA_CMD_FPDMA_WRITE, "WRITE FPDMA QUEUED" },
++ { ATA_CMD_NCQ_NON_DATA, "NCQ NON-DATA" },
+ { ATA_CMD_FPDMA_SEND, "SEND FPDMA QUEUED" },
+ { ATA_CMD_FPDMA_RECV, "RECEIVE FPDMA QUEUED" },
+ { ATA_CMD_PIO_READ, "READ SECTOR(S)" },
--- /dev/null
+From 89b008222c2bf21e50219725caed31590edfd9d1 Mon Sep 17 00:00:00 2001
+From: Aurabindo Pillai <aurabindo.pillai@amd.com>
+Date: Tue, 26 Jul 2022 13:13:27 -0400
+Subject: drm/amd/display: Check correct bounds for stream encoder instances for DCN303
+
+From: Aurabindo Pillai <aurabindo.pillai@amd.com>
+
+commit 89b008222c2bf21e50219725caed31590edfd9d1 upstream.
+
+[Why & How]
+eng_id for DCN303 cannot be more than 1, since we have only two
+instances of stream encoders.
+
+Check the correct boundary condition for engine ID for DCN303 prevent
+the potential out of bounds access.
+
+Fixes: cd6d421e3d1a ("drm/amd/display: Initial DC support for Beige Goby")
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Chris Park <Chris.Park@amd.com>
+Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
+Acked-by: Tom Chung <chiahsuan.chung@amd.com>
+Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c
++++ b/drivers/gpu/drm/amd/display/dc/dcn303/dcn303_resource.c
+@@ -500,7 +500,7 @@ static struct stream_encoder *dcn303_str
+ int afmt_inst;
+
+ /* Mapping of VPG, AFMT, DME register blocks to DIO block instance */
+- if (eng_id <= ENGINE_ID_DIGE) {
++ if (eng_id <= ENGINE_ID_DIGB) {
+ vpg_inst = eng_id;
+ afmt_inst = eng_id;
+ } else
--- /dev/null
+From c20ee5749a3f688d9bab83a3b09b75587153ff13 Mon Sep 17 00:00:00 2001
+From: Karol Herbst <kherbst@redhat.com>
+Date: Wed, 3 Aug 2022 16:27:45 +0200
+Subject: drm/nouveau: recognise GA103
+
+From: Karol Herbst <kherbst@redhat.com>
+
+commit c20ee5749a3f688d9bab83a3b09b75587153ff13 upstream.
+
+Appears to be ok with general GA10x code.
+
+Signed-off-by: Karol Herbst <kherbst@redhat.com>
+Cc: <stable@vger.kernel.org> # v5.15+
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220803142745.2679510-1-kherbst@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ .../gpu/drm/nouveau/nvkm/engine/device/base.c | 22 +++++++++++++++++++
+ 1 file changed, 22 insertions(+)
+
+diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+index 62efbd0f3846..b7246b146e51 100644
+--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
++++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+@@ -2605,6 +2605,27 @@ nv172_chipset = {
+ .fifo = { 0x00000001, ga102_fifo_new },
+ };
+
++static const struct nvkm_device_chip
++nv173_chipset = {
++ .name = "GA103",
++ .bar = { 0x00000001, tu102_bar_new },
++ .bios = { 0x00000001, nvkm_bios_new },
++ .devinit = { 0x00000001, ga100_devinit_new },
++ .fb = { 0x00000001, ga102_fb_new },
++ .gpio = { 0x00000001, ga102_gpio_new },
++ .i2c = { 0x00000001, gm200_i2c_new },
++ .imem = { 0x00000001, nv50_instmem_new },
++ .mc = { 0x00000001, ga100_mc_new },
++ .mmu = { 0x00000001, tu102_mmu_new },
++ .pci = { 0x00000001, gp100_pci_new },
++ .privring = { 0x00000001, gm200_privring_new },
++ .timer = { 0x00000001, gk20a_timer_new },
++ .top = { 0x00000001, ga100_top_new },
++ .disp = { 0x00000001, ga102_disp_new },
++ .dma = { 0x00000001, gv100_dma_new },
++ .fifo = { 0x00000001, ga102_fifo_new },
++};
++
+ static const struct nvkm_device_chip
+ nv174_chipset = {
+ .name = "GA104",
+@@ -3092,6 +3113,7 @@ nvkm_device_ctor(const struct nvkm_device_func *func,
+ case 0x167: device->chip = &nv167_chipset; break;
+ case 0x168: device->chip = &nv168_chipset; break;
+ case 0x172: device->chip = &nv172_chipset; break;
++ case 0x173: device->chip = &nv173_chipset; break;
+ case 0x174: device->chip = &nv174_chipset; break;
+ case 0x176: device->chip = &nv176_chipset; break;
+ case 0x177: device->chip = &nv177_chipset; break;
+--
+2.37.2
+
--- /dev/null
+From cf4b7387c0a842d64bdd7c353e6d3298174a7740 Mon Sep 17 00:00:00 2001
+From: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
+Date: Tue, 9 Aug 2022 02:56:23 -0700
+Subject: drm/ttm: Fix dummy res NULL ptr deref bug
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
+
+commit cf4b7387c0a842d64bdd7c353e6d3298174a7740 upstream.
+
+Check the bo->resource value before accessing the resource
+mem_type.
+
+v2: Fix commit description unwrapped warning
+
+<log snip>
+[ 40.191227][ T184] general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] SMP KASAN PTI
+[ 40.192995][ T184] KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
+[ 40.194411][ T184] CPU: 1 PID: 184 Comm: systemd-udevd Not tainted 5.19.0-rc4-00721-gb297c22b7070 #1
+[ 40.196063][ T184] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-4 04/01/2014
+[ 40.199605][ T184] RIP: 0010:ttm_bo_validate+0x1b3/0x240 [ttm]
+[ 40.200754][ T184] Code: e8 72 c5 ff ff 83 f8 b8 74 d4 85 c0 75 54 49 8b 9e 58 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 10 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 04 3c 03 7e 44 8b 53 10 31 c0 85 d2 0f 85 58
+[ 40.203685][ T184] RSP: 0018:ffffc900006df0c8 EFLAGS: 00010202
+[ 40.204630][ T184] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 1ffff1102f4bb71b
+[ 40.205864][ T184] RDX: 0000000000000002 RSI: ffffc900006df208 RDI: 0000000000000010
+[ 40.207102][ T184] RBP: 1ffff920000dbe1a R08: ffffc900006df208 R09: 0000000000000000
+[ 40.208394][ T184] R10: ffff88817a5f0000 R11: 0000000000000001 R12: ffffc900006df110
+[ 40.209692][ T184] R13: ffffc900006df0f0 R14: ffff88817a5db800 R15: ffffc900006df208
+[ 40.210862][ T184] FS: 00007f6b1d16e8c0(0000) GS:ffff88839d700000(0000) knlGS:0000000000000000
+[ 40.212250][ T184] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 40.213275][ T184] CR2: 000055a1001d4ff0 CR3: 00000001700f4000 CR4: 00000000000006e0
+[ 40.214469][ T184] Call Trace:
+[ 40.214974][ T184] <TASK>
+[ 40.215438][ T184] ? ttm_bo_bounce_temp_buffer+0x140/0x140 [ttm]
+[ 40.216572][ T184] ? mutex_spin_on_owner+0x240/0x240
+[ 40.217456][ T184] ? drm_vma_offset_add+0xaa/0x100 [drm]
+[ 40.218457][ T184] ttm_bo_init_reserved+0x3d6/0x540 [ttm]
+[ 40.219410][ T184] ? shmem_get_inode+0x744/0x980
+[ 40.220231][ T184] ttm_bo_init_validate+0xb1/0x200 [ttm]
+[ 40.221172][ T184] ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper]
+[ 40.222530][ T184] ? ttm_bo_init_reserved+0x540/0x540 [ttm]
+[ 40.223643][ T184] ? __do_sys_finit_module+0x11a/0x1c0
+[ 40.224654][ T184] ? __shmem_file_setup+0x102/0x280
+[ 40.234764][ T184] drm_gem_vram_create+0x305/0x480 [drm_vram_helper]
+[ 40.235766][ T184] ? bo_driver_evict_flags+0x340/0x340 [drm_vram_helper]
+[ 40.236846][ T184] ? __kasan_slab_free+0x108/0x180
+[ 40.237650][ T184] drm_gem_vram_fill_create_dumb+0x134/0x340 [drm_vram_helper]
+[ 40.238864][ T184] ? local_pci_probe+0xdf/0x180
+[ 40.239674][ T184] ? drmm_vram_helper_init+0x400/0x400 [drm_vram_helper]
+[ 40.240826][ T184] drm_client_framebuffer_create+0x19c/0x400 [drm]
+[ 40.241955][ T184] ? drm_client_buffer_delete+0x200/0x200 [drm]
+[ 40.243001][ T184] ? drm_client_pick_crtcs+0x554/0xb80 [drm]
+[ 40.244030][ T184] drm_fb_helper_generic_probe+0x23f/0x940 [drm_kms_helper]
+[ 40.245226][ T184] ? __cond_resched+0x1c/0xc0
+[ 40.245987][ T184] ? drm_fb_helper_memory_range_to_clip+0x180/0x180 [drm_kms_helper]
+[ 40.247316][ T184] ? mutex_unlock+0x80/0x100
+[ 40.248005][ T184] ? __mutex_unlock_slowpath+0x2c0/0x2c0
+[ 40.249083][ T184] drm_fb_helper_single_fb_probe+0x907/0xf00 [drm_kms_helper]
+[ 40.250314][ T184] ? drm_fb_helper_check_var+0x1180/0x1180 [drm_kms_helper]
+[ 40.251540][ T184] ? __cond_resched+0x1c/0xc0
+[ 40.252321][ T184] ? mutex_lock+0x9f/0x100
+[ 40.253062][ T184] __drm_fb_helper_initial_config_and_unlock+0xb9/0x2c0 [drm_kms_helper]
+[ 40.254394][ T184] drm_fbdev_client_hotplug+0x56f/0x840 [drm_kms_helper]
+[ 40.255477][ T184] drm_fbdev_generic_setup+0x165/0x3c0 [drm_kms_helper]
+[ 40.256607][ T184] bochs_pci_probe+0x6b7/0x900 [bochs]
+[ 40.257515][ T184] ? _raw_spin_lock_irqsave+0x87/0x100
+[ 40.258312][ T184] ? bochs_hw_init+0x480/0x480 [bochs]
+[ 40.259244][ T184] ? bochs_hw_init+0x480/0x480 [bochs]
+[ 40.260186][ T184] local_pci_probe+0xdf/0x180
+[ 40.260928][ T184] pci_call_probe+0x15f/0x500
+[ 40.265798][ T184] ? _raw_spin_lock+0x81/0x100
+[ 40.266508][ T184] ? pci_pm_suspend_noirq+0x980/0x980
+[ 40.267322][ T184] ? pci_assign_irq+0x81/0x280
+[ 40.268096][ T184] ? pci_match_device+0x351/0x6c0
+[ 40.268883][ T184] ? kernfs_put+0x18/0x40
+[ 40.269611][ T184] pci_device_probe+0xee/0x240
+[ 40.270352][ T184] really_probe+0x435/0xa80
+[ 40.271021][ T184] __driver_probe_device+0x2ab/0x480
+[ 40.271828][ T184] driver_probe_device+0x49/0x140
+[ 40.272627][ T184] __driver_attach+0x1bd/0x4c0
+[ 40.273372][ T184] ? __device_attach_driver+0x240/0x240
+[ 40.274273][ T184] bus_for_each_dev+0x11e/0x1c0
+[ 40.275080][ T184] ? subsys_dev_iter_exit+0x40/0x40
+[ 40.275951][ T184] ? klist_add_tail+0x132/0x280
+[ 40.276767][ T184] bus_add_driver+0x39b/0x580
+[ 40.277574][ T184] driver_register+0x20f/0x3c0
+[ 40.278281][ T184] ? 0xffffffffc04a2000
+[ 40.278894][ T184] do_one_initcall+0x8a/0x300
+[ 40.279642][ T184] ? trace_event_raw_event_initcall_level+0x1c0/0x1c0
+[ 40.280707][ T184] ? kasan_unpoison+0x23/0x80
+[ 40.281479][ T184] ? kasan_unpoison+0x23/0x80
+[ 40.282197][ T184] do_init_module+0x190/0x640
+[ 40.282926][ T184] load_module+0x221b/0x2780
+[ 40.283611][ T184] ? layout_and_allocate+0x5c0/0x5c0
+[ 40.284401][ T184] ? kernel_read_file+0x286/0x6c0
+[ 40.285216][ T184] ? __x64_sys_fspick+0x2c0/0x2c0
+[ 40.286043][ T184] ? mmap_region+0x4e7/0x1300
+[ 40.286832][ T184] ? __do_sys_finit_module+0x11a/0x1c0
+[ 40.287743][ T184] __do_sys_finit_module+0x11a/0x1c0
+[ 40.288636][ T184] ? __ia32_sys_init_module+0xc0/0xc0
+[ 40.289557][ T184] ? __seccomp_filter+0x15e/0xc80
+[ 40.290341][ T184] ? vm_mmap_pgoff+0x185/0x240
+[ 40.291060][ T184] do_syscall_64+0x3b/0xc0
+[ 40.291763][ T184] entry_SYSCALL_64_after_hwframe+0x46/0xb0
+[ 40.292678][ T184] RIP: 0033:0x7f6b1d6279b9
+[ 40.293438][ T184] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a7 54 0c 00 f7 d8 64 89 01 48
+[ 40.296302][ T184] RSP: 002b:00007ffe7f51b798 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
+[ 40.297633][ T184] RAX: ffffffffffffffda RBX: 00005642dcca2880 RCX: 00007f6b1d6279b9
+[ 40.298890][ T184] RDX: 0000000000000000 RSI: 00007f6b1d7b2e2d RDI: 0000000000000016
+[ 40.300199][ T184] RBP: 0000000000020000 R08: 0000000000000000 R09: 00005642dccd5530
+[ 40.301547][ T184] R10: 0000000000000016 R11: 0000000000000246 R12: 00007f6b1d7b2e2d
+[ 40.302698][ T184] R13: 0000000000000000 R14: 00005642dcca4230 R15: 00005642dcca2880
+
+Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com>
+Reported-by: kernel test robot <oliver.sang@intel.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20220726162205.2778-1-Arunpravin.PaneerSelvam@amd.com
+Link: https://patchwork.freedesktop.org/patch/msgid/20220809095623.3569-1-Arunpravin.PaneerSelvam@amd.com
+Signed-off-by: Christian König <christian.koenig@amd.com>
+CC: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/ttm/ttm_bo.c
++++ b/drivers/gpu/drm/ttm/ttm_bo.c
+@@ -987,7 +987,7 @@ int ttm_bo_validate(struct ttm_buffer_ob
+ /*
+ * We might need to add a TTM.
+ */
+- if (bo->resource->mem_type == TTM_PL_SYSTEM) {
++ if (!bo->resource || bo->resource->mem_type == TTM_PL_SYSTEM) {
+ ret = ttm_tt_create(bo, true);
+ if (ret)
+ return ret;
--- /dev/null
+From 405294f29faee5de8c10cb9d4a90e229c2835279 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Tue, 16 Aug 2022 05:39:36 +0000
+Subject: KVM: Unconditionally get a ref to /dev/kvm module when creating a VM
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 405294f29faee5de8c10cb9d4a90e229c2835279 upstream.
+
+Unconditionally get a reference to the /dev/kvm module when creating a VM
+instead of using try_get_module(), which will fail if the module is in
+the process of being forcefully unloaded. The error handling when
+try_get_module() fails doesn't properly unwind all that has been done,
+e.g. doesn't call kvm_arch_pre_destroy_vm() and doesn't remove the VM
+from the global list. Not removing VMs from the global list tends to be
+fatal, e.g. leads to use-after-free explosions.
+
+The obvious alternative would be to add proper unwinding, but the
+justification for using try_get_module(), "rmmod --wait", is completely
+bogus as support for "rmmod --wait", i.e. delete_module() without
+O_NONBLOCK, was removed by commit 3f2b9c9cdf38 ("module: remove rmmod
+--wait option.") nearly a decade ago.
+
+It's still possible for try_get_module() to fail due to the module dying
+(more like being killed), as the module will be tagged MODULE_STATE_GOING
+by "rmmod --force", i.e. delete_module(..., O_TRUNC), but playing nice
+with forced unloading is an exercise in futility and gives a falsea sense
+of security. Using try_get_module() only prevents acquiring _new_
+references, it doesn't magically put the references held by other VMs,
+and forced unloading doesn't wait, i.e. "rmmod --force" on KVM is all but
+guaranteed to cause spectacular fireworks; the window where KVM will fail
+try_get_module() is tiny compared to the window where KVM is building and
+running the VM with an elevated module refcount.
+
+Addressing KVM's inability to play nice with "rmmod --force" is firmly
+out-of-scope. Forcefully unloading any module taints kernel (for obvious
+reasons) _and_ requires the kernel to be built with
+CONFIG_MODULE_FORCE_UNLOAD=y, which is off by default and comes with the
+amusing disclaimer that it's "mainly for kernel developers and desperate
+users". In other words, KVM is free to scoff at bug reports due to using
+"rmmod --force" while VMs may be running.
+
+Fixes: 5f6de5cbebee ("KVM: Prevent module exit until all VMs are freed")
+Cc: stable@vger.kernel.org
+Cc: David Matlack <dmatlack@google.com>
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20220816053937.2477106-3-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ virt/kvm/kvm_main.c | 14 ++++----------
+ 1 file changed, 4 insertions(+), 10 deletions(-)
+
+--- a/virt/kvm/kvm_main.c
++++ b/virt/kvm/kvm_main.c
+@@ -1034,6 +1034,9 @@ static struct kvm *kvm_create_vm(unsigne
+ if (!kvm)
+ return ERR_PTR(-ENOMEM);
+
++ /* KVM is pinned via open("/dev/kvm"), the fd passed to this ioctl(). */
++ __module_get(kvm_chardev_ops.owner);
++
+ KVM_MMU_LOCK_INIT(kvm);
+ mmgrab(current->mm);
+ kvm->mm = current->mm;
+@@ -1107,16 +1110,6 @@ static struct kvm *kvm_create_vm(unsigne
+ preempt_notifier_inc();
+ kvm_init_pm_notifier(kvm);
+
+- /*
+- * When the fd passed to this ioctl() is opened it pins the module,
+- * but try_module_get() also prevents getting a reference if the module
+- * is in MODULE_STATE_GOING (e.g. if someone ran "rmmod --wait").
+- */
+- if (!try_module_get(kvm_chardev_ops.owner)) {
+- r = -ENODEV;
+- goto out_err;
+- }
+-
+ return kvm;
+
+ out_err:
+@@ -1140,6 +1133,7 @@ out_err_no_irq_srcu:
+ out_err_no_srcu:
+ kvm_arch_free_vm(kvm);
+ mmdrop(current->mm);
++ module_put(kvm_chardev_ops.owner);
+ return ERR_PTR(r);
+ }
+
--- /dev/null
+From 415d832497098030241605c52ea83d4e2cfa7879 Mon Sep 17 00:00:00 2001
+From: Hector Martin <marcan@marcan.st>
+Date: Tue, 16 Aug 2022 16:03:11 +0900
+Subject: locking/atomic: Make test_and_*_bit() ordered on failure
+
+From: Hector Martin <marcan@marcan.st>
+
+commit 415d832497098030241605c52ea83d4e2cfa7879 upstream.
+
+These operations are documented as always ordered in
+include/asm-generic/bitops/instrumented-atomic.h, and producer-consumer
+type use cases where one side needs to ensure a flag is left pending
+after some shared data was updated rely on this ordering, even in the
+failure case.
+
+This is the case with the workqueue code, which currently suffers from a
+reproducible ordering violation on Apple M1 platforms (which are
+notoriously out-of-order) that ends up causing the TTY layer to fail to
+deliver data to userspace properly under the right conditions. This
+change fixes that bug.
+
+Change the documentation to restrict the "no order on failure" story to
+the _lock() variant (for which it makes sense), and remove the
+early-exit from the generic implementation, which is what causes the
+missing barrier semantics in that case. Without this, the remaining
+atomic op is fully ordered (including on ARM64 LSE, as of recent
+versions of the architecture spec).
+
+Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: stable@vger.kernel.org
+Fixes: e986a0d6cb36 ("locking/atomics, asm-generic/bitops/atomic.h: Rewrite using atomic_*() APIs")
+Fixes: 61e02392d3c7 ("locking/atomic/bitops: Document and clarify ordering semantics for failed test_and_{}_bit()")
+Signed-off-by: Hector Martin <marcan@marcan.st>
+Acked-by: Will Deacon <will@kernel.org>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/atomic_bitops.txt | 2 +-
+ include/asm-generic/bitops/atomic.h | 6 ------
+ 2 files changed, 1 insertion(+), 7 deletions(-)
+
+--- a/Documentation/atomic_bitops.txt
++++ b/Documentation/atomic_bitops.txt
+@@ -59,7 +59,7 @@ Like with atomic_t, the rule of thumb is
+ - RMW operations that have a return value are fully ordered.
+
+ - RMW operations that are conditional are unordered on FAILURE,
+- otherwise the above rules apply. In the case of test_and_{}_bit() operations,
++ otherwise the above rules apply. In the case of test_and_set_bit_lock(),
+ if the bit in memory is unchanged by the operation then it is deemed to have
+ failed.
+
+--- a/include/asm-generic/bitops/atomic.h
++++ b/include/asm-generic/bitops/atomic.h
+@@ -39,9 +39,6 @@ arch_test_and_set_bit(unsigned int nr, v
+ unsigned long mask = BIT_MASK(nr);
+
+ p += BIT_WORD(nr);
+- if (READ_ONCE(*p) & mask)
+- return 1;
+-
+ old = arch_atomic_long_fetch_or(mask, (atomic_long_t *)p);
+ return !!(old & mask);
+ }
+@@ -53,9 +50,6 @@ arch_test_and_clear_bit(unsigned int nr,
+ unsigned long mask = BIT_MASK(nr);
+
+ p += BIT_WORD(nr);
+- if (!(READ_ONCE(*p) & mask))
+- return 0;
+-
+ old = arch_atomic_long_fetch_andnot(mask, (atomic_long_t *)p);
+ return !!(old & mask);
+ }
--- /dev/null
+From 9f414eb409daf4f778f011cf8266d36896bb930b Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Wed, 10 Aug 2022 09:00:42 -0400
+Subject: rds: add missing barrier to release_refill
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 9f414eb409daf4f778f011cf8266d36896bb930b upstream.
+
+The functions clear_bit and set_bit do not imply a memory barrier, thus it
+may be possible that the waitqueue_active function (which does not take
+any locks) is moved before clear_bit and it could miss a wakeup event.
+
+Fix this bug by adding a memory barrier after clear_bit.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/rds/ib_recv.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/rds/ib_recv.c
++++ b/net/rds/ib_recv.c
+@@ -363,6 +363,7 @@ static int acquire_refill(struct rds_con
+ static void release_refill(struct rds_connection *conn)
+ {
+ clear_bit(RDS_RECV_REFILL, &conn->c_flags);
++ smp_mb__after_atomic();
+
+ /* We don't use wait_on_bit()/wake_up_bit() because our waking is in a
+ * hot path and finding waiters is very rare. We don't want to walk
--- /dev/null
+alsa-info-fix-llseek-return-value-when-using-callback.patch
+alsa-hda-realtek-add-quirk-for-clevo-ns50pu-ns70pu.patch
+kvm-unconditionally-get-a-ref-to-dev-kvm-module-when-creating-a-vm.patch
+x86-mm-use-proper-mask-when-setting-pud-mapping.patch
+rds-add-missing-barrier-to-release_refill.patch
+locking-atomic-make-test_and_-_bit-ordered-on-failure.patch
+drm-nouveau-recognise-ga103.patch
+drm-ttm-fix-dummy-res-null-ptr-deref-bug.patch
+drm-amd-display-check-correct-bounds-for-stream-encoder-instances-for-dcn303.patch
+ata-libata-eh-add-missing-command-name.patch
--- /dev/null
+From 88e0a74902f894fbbc55ad3ad2cb23b4bfba555c Mon Sep 17 00:00:00 2001
+From: Aaron Lu <aaron.lu@intel.com>
+Date: Fri, 19 Aug 2022 10:30:01 +0800
+Subject: x86/mm: Use proper mask when setting PUD mapping
+
+From: Aaron Lu <aaron.lu@intel.com>
+
+commit 88e0a74902f894fbbc55ad3ad2cb23b4bfba555c upstream.
+
+Commit c164fbb40c43f("x86/mm: thread pgprot_t through
+init_memory_mapping()") mistakenly used __pgprot() which doesn't respect
+__default_kernel_pte_mask when setting PUD mapping.
+
+Fix it by only setting the one bit we actually need (PSE) and leaving
+the other bits (that have been properly masked) alone.
+
+Fixes: c164fbb40c43 ("x86/mm: thread pgprot_t through init_memory_mapping()")
+Signed-off-by: Aaron Lu <aaron.lu@intel.com>
+Cc: stable@kernel.org
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/mm/init_64.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/mm/init_64.c
++++ b/arch/x86/mm/init_64.c
+@@ -646,7 +646,7 @@ phys_pud_init(pud_t *pud_page, unsigned
+ pages++;
+ spin_lock(&init_mm.page_table_lock);
+
+- prot = __pgprot(pgprot_val(prot) | __PAGE_KERNEL_LARGE);
++ prot = __pgprot(pgprot_val(prot) | _PAGE_PSE);
+
+ set_pte_init((pte_t *)pud,
+ pfn_pte((paddr & PUD_MASK) >> PAGE_SHIFT,
projects / thirdparty / kernel / stable-queue.git / commitdiff
