commit a2547651bc896f95a3680a6a0a27401e7c7a1080 Author: Greg Kroah-Hartman Date: Wed Dec 1 09:04:57 2021 +0100 Linux 5.15.6 Link: https://lore.kernel.org/r/20211129181718.913038547@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Fox Chen Tested-by: Ronald Warsow Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman commit 4268e8325d63c63c424640e58da0ce6bad6344e0 Author: Alex Deucher Date: Thu Nov 18 14:50:37 2021 -0500 drm/amdgpu/gfx9: switch to golden tsc registers for renoir+ commit 53af98c091bc42fd9ec64cfabc40da4e5f3aae93 upstream. Renoir and newer gfx9 APUs have new TSC register that is not part of the gfxoff tile, so it can be read without needing to disable gfx off. Acked-by: Luben Tuikov Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 8c501d9cf1229fe9676da75f3c1f77c61ccffe22 Author: Alex Deucher Date: Thu Nov 18 14:33:23 2021 -0500 drm/amdgpu/gfx10: add wraparound gpu counter check for APUs as well commit 244ee398855df2adc7d3ac5702b58424a5f684cc upstream. Apply the same check we do for dGPUs for APUs as well. Acked-by: Luben Tuikov Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit db8ed1e61b4922b841b47c989a0000e06acac0fe Author: Ming Lei Date: Wed Nov 17 19:55:02 2021 +0800 block: avoid to quiesce queue in elevator_init_mq commit 245a489e81e13dd55ae46d27becf6d5901eb7828 upstream. elevator_init_mq() is only called before adding disk, when there isn't any FS I/O, only passthrough requests can be queued, so freezing queue plus canceling dispatch work is enough to drain any dispatch activities, then we can avoid synchronize_srcu() in blk_mq_quiesce_queue(). Long boot latency issue can be fixed in case of lots of disks added during booting. Fixes: 737eb78e82d5 ("block: Delay default elevator initialization") Reported-by: yangerkun Cc: Damien Le Moal Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20211117115502.1600950-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e03513f58919d9e2bc6df765ca2c9da863d03d90 Author: Ming Lei Date: Tue Nov 16 09:43:43 2021 +0800 blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release() commit 2a19b28f7929866e1cec92a3619f4de9f2d20005 upstream. For avoiding to slow down queue destroy, we don't call blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to cancel dispatch work in blk_release_queue(). However, this way has caused kernel oops[1], reported by Changhui. The log shows that scsi_device can be freed before running blk_release_queue(), which is expected too since scsi_device is released after the scsi disk is closed and the scsi_device is removed. Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue() and disk_release(): 1) when disk_release() is run, the disk has been closed, and any sync dispatch activities have been done, so canceling dispatch work is enough to quiesce filesystem I/O dispatch activity. 2) in blk_cleanup_queue(), we only focus on passthrough request, and passthrough request is always explicitly allocated & freed by its caller, so once queue is frozen, all sync dispatch activity for passthrough request has been done, then it is enough to just cancel dispatch work for avoiding any dispatch activity. [1] kernel panic log [12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300 [12622.777186] #PF: supervisor read access in kernel mode [12622.782918] #PF: error_code(0x0000) - not-present page [12622.788649] PGD 0 P4D 0 [12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI [12622.796138] CPU: 10 PID: 744 Comm: kworker/10:1H Kdump: loaded Not tainted 5.15.0+ #1 [12622.804877] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015 [12622.813321] Workqueue: kblockd blk_mq_run_work_fn [12622.818572] RIP: 0010:sbitmap_get+0x75/0x190 [12622.823336] Code: 85 80 00 00 00 41 8b 57 08 85 d2 0f 84 b1 00 00 00 45 31 e4 48 63 cd 48 8d 1c 49 48 c1 e3 06 49 03 5f 10 4c 8d 6b 40 83 f0 01 <48> 8b 33 44 89 f2 4c 89 ef 0f b6 c8 e8 fa f3 ff ff 83 f8 ff 75 58 [12622.844290] RSP: 0018:ffffb00a446dbd40 EFLAGS: 00010202 [12622.850120] RAX: 0000000000000001 RBX: 0000000000000300 RCX: 0000000000000004 [12622.858082] RDX: 0000000000000006 RSI: 0000000000000082 RDI: ffffa0b7a2dfe030 [12622.866042] RBP: 0000000000000004 R08: 0000000000000001 R09: ffffa0b742721334 [12622.874003] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000000 [12622.881964] R13: 0000000000000340 R14: 0000000000000000 R15: ffffa0b7a2dfe030 [12622.889926] FS: 0000000000000000(0000) GS:ffffa0baafb40000(0000) knlGS:0000000000000000 [12622.898956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [12622.905367] CR2: 0000000000000300 CR3: 0000000641210001 CR4: 00000000001706e0 [12622.913328] Call Trace: [12622.916055] [12622.918394] scsi_mq_get_budget+0x1a/0x110 [12622.922969] __blk_mq_do_dispatch_sched+0x1d4/0x320 [12622.928404] ? pick_next_task_fair+0x39/0x390 [12622.933268] __blk_mq_sched_dispatch_requests+0xf4/0x140 [12622.939194] blk_mq_sched_dispatch_requests+0x30/0x60 [12622.944829] __blk_mq_run_hw_queue+0x30/0xa0 [12622.949593] process_one_work+0x1e8/0x3c0 [12622.954059] worker_thread+0x50/0x3b0 [12622.958144] ? rescuer_thread+0x370/0x370 [12622.962616] kthread+0x158/0x180 [12622.966218] ? set_kthread_struct+0x40/0x40 [12622.970884] ret_from_fork+0x22/0x30 [12622.974875] [12622.977309] Modules linked in: scsi_debug rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs sunrpc dm_multipath intel_rapl_msr intel_rapl_common dell_wmi_descriptor sb_edac rfkill video x86_pkg_temp_thermal intel_powerclamp dcdbas coretemp kvm_intel kvm mgag200 irqbypass i2c_algo_bit rapl drm_kms_helper ipmi_ssif intel_cstate intel_uncore syscopyarea sysfillrect sysimgblt fb_sys_fops pcspkr cec mei_me lpc_ich mei ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter drm fuse xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg ixgbe ahci libahci crct10dif_pclmul crc32_pclmul crc32c_intel libata megaraid_sas ghash_clmulni_intel tg3 wdat_wdt mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_debug] Reported-by: ChanghuiZhong Cc: Christoph Hellwig Cc: "Martin K. Petersen" Cc: Bart Van Assche Cc: linux-scsi@vger.kernel.org Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20211116014343.610501-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d9262cc886e2e144840226a31e40a36f25c6579f Author: Mauro Carvalho Chehab Date: Tue Nov 16 12:11:21 2021 +0000 docs: accounting: update delay-accounting.rst reference commit 0f60a29c52b515532e6b11dc6b3c9e5b5f7ff2b4 upstream. The file name: accounting/delay-accounting.rst should be, instead: Documentation/accounting/delay-accounting.rst. Also, there's no need to use doc:`foo`, as automarkup.py will automatically handle plain text mentions to Documentation/ files. So, update its cross-reference accordingly. Fixes: fcb501704554 ("delayacct: Document task_delayacct sysctl") Fixes: c3123552aad3 ("docs: accounting: convert to ReST") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman commit ec8848ab5ebc706a24be85f9c9e92f846d6266cd Author: Cristian Marussi Date: Mon Nov 15 15:40:43 2021 +0000 firmware: arm_scmi: Fix type error in sensor protocol commit bd074e5039ee16d71833a67337e2f6bf5d106b3a upstream. Fix incorrect type error reported by sparse as: drivers/firmware/arm_scmi/sensors.c:640:28: warning: incorrect type in argument 1 (different base types) drivers/firmware/arm_scmi/sensors.c:640:28: expected unsigned int [usertype] val drivers/firmware/arm_scmi/sensors.c:640:28: got restricted __le32 [usertype] Link: https://lore.kernel.org/r/20211115154043.49284-2-cristian.marussi@arm.com Fixes: 7b83c5f410889 ("firmware: arm_scmi: Add SCMI v3.0 sensor configuration support") Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman commit 4cbe2531efebcd2ae5f98ed2d8d8cdacc5423d7f Author: Cristian Marussi Date: Mon Nov 15 15:40:42 2021 +0000 firmware: arm_scmi: Fix type error assignment in voltage protocol commit 026d9835b62bba34b7e657a0bfb76717822f9319 upstream. Fix incorrect type assignment error reported by sparse as: drivers/firmware/arm_scmi/voltage.c:159:42: warning: incorrect type in assignment (different base types) drivers/firmware/arm_scmi/voltage.c:159:42: expected restricted __le32 [usertype] level_index drivers/firmware/arm_scmi/voltage.c:159:42: got unsigned int [usertype] desc_index Link: https://lore.kernel.org/r/20211115154043.49284-1-cristian.marussi@arm.com Fixes: 2add5cacff353 ("firmware: arm_scmi: Add voltage domain management protocol support") Reported-by: kernel test robot Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla Signed-off-by: Greg Kroah-Hartman commit 2d447d318b76252154f5eec34646f767de2bf500 Author: Ye Bin Date: Mon Nov 22 10:47:37 2021 +0800 io_uring: fix soft lockup when call __io_remove_buffers commit 1d0254e6b47e73222fd3d6ae95cccbaafe5b3ecf upstream. I got issue as follows: [ 567.094140] __io_remove_buffers: [1]start ctx=0xffff8881067bf000 bgid=65533 buf=0xffff8881fefe1680 [ 594.360799] watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u32:5:108] [ 594.364987] Modules linked in: [ 594.365405] irq event stamp: 604180238 [ 594.365906] hardirqs last enabled at (604180237): [] _raw_spin_unlock_irqrestore+0x2d/0x50 [ 594.367181] hardirqs last disabled at (604180238): [] sysvec_apic_timer_interrupt+0xb/0xc0 [ 594.368420] softirqs last enabled at (569080666): [] __do_softirq+0x654/0xa9e [ 594.369551] softirqs last disabled at (569080575): [] irq_exit_rcu+0x1ca/0x250 [ 594.370692] CPU: 2 PID: 108 Comm: kworker/u32:5 Tainted: G L 5.15.0-next-20211112+ #88 [ 594.371891] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 594.373604] Workqueue: events_unbound io_ring_exit_work [ 594.374303] RIP: 0010:_raw_spin_unlock_irqrestore+0x33/0x50 [ 594.375037] Code: 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 55 f5 55 fd 48 89 ef e8 ed a7 56 fd 80 e7 02 74 06 e8 43 13 7b fd fb bf 01 00 00 00 f8 78 474 [ 594.377433] RSP: 0018:ffff888101587a70 EFLAGS: 00000202 [ 594.378120] RAX: 0000000024030f0d RBX: 0000000000000246 RCX: 1ffffffff2f09106 [ 594.379053] RDX: 0000000000000000 RSI: ffffffff9449f0e0 RDI: 0000000000000001 [ 594.379991] RBP: ffffffff9586cdc0 R08: 0000000000000001 R09: fffffbfff2effcab [ 594.380923] R10: ffffffff977fe557 R11: fffffbfff2effcaa R12: ffff8881b8f3def0 [ 594.381858] R13: 0000000000000246 R14: ffff888153a8b070 R15: 0000000000000000 [ 594.382787] FS: 0000000000000000(0000) GS:ffff888399c00000(0000) knlGS:0000000000000000 [ 594.383851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 594.384602] CR2: 00007fcbe71d2000 CR3: 00000000b4216000 CR4: 00000000000006e0 [ 594.385540] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 594.386474] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 594.387403] Call Trace: [ 594.387738] [ 594.388042] find_and_remove_object+0x118/0x160 [ 594.389321] delete_object_full+0xc/0x20 [ 594.389852] kfree+0x193/0x470 [ 594.390275] __io_remove_buffers.part.0+0xed/0x147 [ 594.390931] io_ring_ctx_free+0x342/0x6a2 [ 594.392159] io_ring_exit_work+0x41e/0x486 [ 594.396419] process_one_work+0x906/0x15a0 [ 594.399185] worker_thread+0x8b/0xd80 [ 594.400259] kthread+0x3bf/0x4a0 [ 594.401847] ret_from_fork+0x22/0x30 [ 594.402343] Message from syslogd@localhost at Nov 13 09:09:54 ... kernel:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u32:5:108] [ 596.793660] __io_remove_buffers: [2099199]start ctx=0xffff8881067bf000 bgid=65533 buf=0xffff8881fefe1680 We can reproduce this issue by follow syzkaller log: r0 = syz_io_uring_setup(0x401, &(0x7f0000000300), &(0x7f0000003000/0x2000)=nil, &(0x7f0000ff8000/0x4000)=nil, &(0x7f0000000280)=0x0, &(0x7f0000000380)=0x0) sendmsg$ETHTOOL_MSG_FEATURES_SET(0xffffffffffffffff, &(0x7f0000003080)={0x0, 0x0, &(0x7f0000003040)={&(0x7f0000000040)=ANY=[], 0x18}}, 0x0) syz_io_uring_submit(r1, r2, &(0x7f0000000240)=@IORING_OP_PROVIDE_BUFFERS={0x1f, 0x5, 0x0, 0x401, 0x1, 0x0, 0x100, 0x0, 0x1, {0xfffd}}, 0x0) io_uring_enter(r0, 0x3a2d, 0x0, 0x0, 0x0, 0x0) The reason above issue is 'buf->list' has 2,100,000 nodes, occupied cpu lead to soft lockup. To solve this issue, we need add schedule point when do while loop in '__io_remove_buffers'. After add schedule point we do regression, get follow data. [ 240.141864] __io_remove_buffers: [1]start ctx=0xffff888170603000 bgid=65533 buf=0xffff8881116fcb00 [ 268.408260] __io_remove_buffers: [1]start ctx=0xffff8881b92d2000 bgid=65533 buf=0xffff888130c83180 [ 275.899234] __io_remove_buffers: [2099199]start ctx=0xffff888170603000 bgid=65533 buf=0xffff8881116fcb00 [ 296.741404] __io_remove_buffers: [1]start ctx=0xffff8881b659c000 bgid=65533 buf=0xffff8881010fe380 [ 305.090059] __io_remove_buffers: [2099199]start ctx=0xffff8881b92d2000 bgid=65533 buf=0xffff888130c83180 [ 325.415746] __io_remove_buffers: [1]start ctx=0xffff8881b92d1000 bgid=65533 buf=0xffff8881a17d8f00 [ 333.160318] __io_remove_buffers: [2099199]start ctx=0xffff8881b659c000 bgid=65533 buf=0xffff8881010fe380 ... Fixes:8bab4c09f24e("io_uring: allow conditional reschedule for intensive iterators") Signed-off-by: Ye Bin Link: https://lore.kernel.org/r/20211122024737.2198530-1-yebin10@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit d841c6720fb24dda402d3fcc08eda6ad4efa457c Author: Shyam Prasad N Date: Sun Nov 21 16:45:44 2021 +0000 cifs: nosharesock should be set on new server commit b9ad6b5b687e798746024e5fc4574d8fa8bdfade upstream. Recent fix to maintain a nosharesock state on the server struct caused a regression. It updated this field in the old tcp session, and not the new one. This caused the multichannel scenario to misbehave. Fixes: c9f1c19cf7c5 (cifs: nosharesock should not share socket with future sessions) Signed-off-by: Shyam Prasad N Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit c9c8c054a01ca6259cd380641cd21bfce791d124 Author: Steven Rostedt (VMware) Date: Fri Nov 26 13:35:26 2021 -0500 tracing: Check pid filtering when creating events commit 6cb206508b621a9a0a2c35b60540e399225c8243 upstream. When pid filtering is activated in an instance, all of the events trace files for that instance has the PID_FILTER flag set. This determines whether or not pid filtering needs to be done on the event, otherwise the event is executed as normal. If pid filtering is enabled when an event is created (via a dynamic event or modules), its flag is not updated to reflect the current state, and the events are not filtered properly. Cc: stable@vger.kernel.org Fixes: 3fdaf80f4a836 ("tracing: Implement event pid filtering") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 6e56e87f43e26047f936152c0e3fb0f9f7bc4327 Author: Christophe JAILLET Date: Sun Nov 7 16:22:57 2021 +0100 ksmbd: Fix an error handling path in 'smb2_sess_setup()' commit f8fbfd85f5c95fff477a7c19f576725945891d0c upstream. All the error handling paths of 'smb2_sess_setup()' end to 'out_err'. All but the new error handling path added by the commit given in the Fixes tag below. Fix this error handling path and branch to 'out_err' as well. Fixes: 0d994cd482ee ("ksmbd: add buffer validation in session setup") Cc: stable@vger.kernel.org # v5.15 Acked-by: Namjae Jeon Signed-off-by: Christophe JAILLET Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 278f72e8eb572a5f392cb291566b9d4c9ea68dc8 Author: Stefano Garzarella Date: Mon Nov 22 17:35:24 2021 +0100 vhost/vsock: fix incorrect used length reported to the guest commit 49d8c5ffad07ca014cfae72a1b9b8c52b6ad9cb8 upstream. The "used length" reported by calling vhost_add_used() must be the number of bytes written by the device (using "in" buffers). In vhost_vsock_handle_tx_kick() the device only reads the guest buffers (they are all "out" buffers), without writing anything, so we must pass 0 as "used length" to comply virtio spec. Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko") Cc: stable@vger.kernel.org Reported-by: Halil Pasic Suggested-by: Jason Wang Signed-off-by: Stefano Garzarella Link: https://lore.kernel.org/r/20211122163525.294024-2-sgarzare@redhat.com Signed-off-by: Michael S. Tsirkin Reviewed-by: Stefan Hajnoczi Reviewed-by: Halil Pasic Signed-off-by: Greg Kroah-Hartman commit e4d58ac67e63727aa45a4a26185876f598e8b3dd Author: Longpeng Date: Wed Nov 24 09:52:15 2021 +0800 vdpa_sim: avoid putting an uninitialized iova_domain commit bb93ce4b150dde79f58e34103cbd1fe829796649 upstream. The system will crash if we put an uninitialized iova_domain, this could happen when an error occurs before initializing the iova_domain in vdpasim_create(). BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:__cpuhp_state_remove_instance+0x96/0x1c0 ... Call Trace: put_iova_domain+0x29/0x220 vdpasim_free+0xd1/0x120 [vdpa_sim] vdpa_release_dev+0x21/0x40 [vdpa] device_release+0x33/0x90 kobject_release+0x63/0x160 vdpasim_create+0x127/0x2a0 [vdpa_sim] vdpasim_net_dev_add+0x7d/0xfe [vdpa_sim_net] vdpa_nl_cmd_dev_add_set_doit+0xe1/0x1a0 [vdpa] genl_family_rcv_msg_doit+0x112/0x140 genl_rcv_msg+0xdf/0x1d0 ... So we must make sure the iova_domain is already initialized before put it. In addition, we may get the following warning in this case: WARNING: ... drivers/iommu/iova.c:344 iova_cache_put+0x58/0x70 So we must make sure the iova_cache_put() is invoked only if the iova_cache_get() is already invoked. Let's fix it together. Cc: stable@vger.kernel.org Fixes: 4080fc106750 ("vdpa_sim: use iova module to allocate IOVA addresses") Signed-off-by: Longpeng Acked-by: Jason Wang Reviewed-by: Stefano Garzarella Link: https://lore.kernel.org/r/20211124015215.119-1-longpeng2@huawei.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman commit e2c8ed0de4ab215cdb21e7952062db3ee2a8291a Author: Joerg Roedel Date: Tue Nov 23 11:55:07 2021 +0100 iommu/amd: Clarify AMD IOMMUv2 initialization messages commit 717e88aad37befedfd531378b632e794e24e9afb upstream. The messages printed on the initialization of the AMD IOMMUv2 driver have caused some confusion in the past. Clarify the messages to lower the confusion in the future. Cc: stable@vger.kernel.org Signed-off-by: Joerg Roedel Link: https://lore.kernel.org/r/20211123105507.7654-3-joro@8bytes.org Signed-off-by: Greg Kroah-Hartman commit 68883f17798c12123da870eb1e418aeb3c6da3b3 Author: Jeff Layton Date: Tue Oct 5 11:12:58 2021 -0400 ceph: properly handle statfs on multifs setups [ Upstream commit 8cfc0c7ed34f7929ce7e5d7c6eecf4d01ba89a84 ] ceph_statfs currently stuffs the cluster fsid into the f_fsid field. This was fine when we only had a single filesystem per cluster, but now that we have multiples we need to use something that will vary between them. Change ceph_statfs to xor each 32-bit chunk of the fsid (aka cluster id) into the lower bits of the statfs->f_fsid. Change the lower bits to hold the fscid (filesystem ID within the cluster). That should give us a value that is guaranteed to be unique between filesystems within a cluster, and should minimize the chance of collisions between mounts of different clusters. URL: https://tracker.ceph.com/issues/52812 Reported-by: Sachin Prabhu Signed-off-by: Jeff Layton Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit a96c6f0bbba6272f0e85e8748c0ee4522d026f3b Author: Shyam Prasad N Date: Sat Nov 6 11:31:53 2021 +0000 cifs: nosharesock should not share socket with future sessions [ Upstream commit c9f1c19cf7c50949885fa5afdb2cb242d61a7fac ] Today, when a new mount is done with nosharesock, we ensure that we don't select an existing matching session. However, we don't mark the connection as nosharesock, which means that those could be shared with future sessions. Fixed it with this commit. Also printing this info in DebugData. Signed-off-by: Shyam Prasad N Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 98805da98d93e6cf4e96d2f2aa5eaecc730722b9 Author: Krzysztof Kozlowski Date: Mon Sep 27 14:50:42 2021 +0200 riscv: dts: microchip: drop duplicated MMC/SDHC node [ Upstream commit 42a57a47bb0c0f531321a7001972a3ca121409bd ] Devicetree source is a description of hardware and hardware has only one block @20008000 which can be configured either as eMMC or SDHC. Having two node for different modes is an obscure, unusual and confusing way to configure it. Instead the board file is supposed to customize the block to its needs, e.g. to SDHC mode. This fixes dtbs_check warning: arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dt.yaml: sdhc@20008000: $nodename:0: 'sdhc@20008000' does not match '^mmc(@.*)?$' Signed-off-by: Krzysztof Kozlowski Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit fda0d131c0a4e6e1c86da2369291430bd9dff9cf Author: Krzysztof Kozlowski Date: Mon Sep 27 14:50:41 2021 +0200 riscv: dts: microchip: fix board compatible [ Upstream commit fd86dd2a5dc5ff1044423c19fef3907862f591c4 ] According to bindings, the compatible must include microchip,mpfs. This fixes dtbs_check warning: arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dt.yaml: /: compatible: ['microchip,mpfs-icicle-kit'] is too short Signed-off-by: Krzysztof Kozlowski Reviewed-by: Conor Dooley Reviewed-by: Geert Uytterhoeven Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 8984bba3b4c0b36be6cbcd7ac4a8779a045bd670 Author: Weichao Guo Date: Sat Sep 18 20:46:36 2021 +0800 f2fs: set SBI_NEED_FSCK flag when inconsistent node block found [ Upstream commit 6663b138ded1a59e630c9e605e42aa7fde490cdc ] Inconsistent node block will cause a file fail to open or read, which could make the user process crashes or stucks. Let's mark SBI_NEED_FSCK flag to trigger a fix at next fsck time. After unlinking the corrupted file, the user process could regenerate a new one and work correctly. Signed-off-by: Weichao Guo Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit fb89bcbfbf373524afa2dd54e339dc45404c0176 Author: Chao Yu Date: Fri Sep 3 10:38:11 2021 +0800 f2fs: quota: fix potential deadlock [ Upstream commit a5c0042200b28fff3bde6fa128ddeaef97990f8d ] As Yi Zhuang reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=214299 There is potential deadlock during quota data flush as below: Thread A: Thread B: f2fs_dquot_acquire down_read(&sbi->quota_sem) f2fs_write_checkpoint block_operations f2fs_look_all down_write(&sbi->cp_rwsem) f2fs_quota_write f2fs_write_begin __do_map_lock f2fs_lock_op down_read(&sbi->cp_rwsem) __need_flush_qutoa down_write(&sbi->quota_sem) This patch changes block_operations() to use trylock, if it fails, it means there is potential quota data updater, in this condition, let's flush quota data first and then trylock again to check dirty status of quota data. The side effect is: in heavy race condition (e.g. multi quota data upaters vs quota data flusher), it may decrease the probability of synchronizing quota data successfully in checkpoint() due to limited retry time of quota flush. Reported-by: Yi Zhuang Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 724ee060d0aba28f072fc7357a20366b0a519593 Author: Alex Williamson Date: Fri Nov 26 21:55:56 2021 +0800 iommu/vt-d: Fix unmap_pages support [ Upstream commit 86dc40c7ea9c22f64571e0e45f695de73a0e2644 ] When supporting only the .map and .unmap callbacks of iommu_ops, the IOMMU driver can make assumptions about the size and alignment used for mappings based on the driver provided pgsize_bitmap. VT-d previously used essentially PAGE_MASK for this bitmap as any power of two mapping was acceptably filled by native page sizes. However, with the .map_pages and .unmap_pages interface we're now getting page-size and count arguments. If we simply combine these as (page-size * count) and make use of the previous map/unmap functions internally, any size and alignment assumptions are very different. As an example, a given vfio device assignment VM will often create a 4MB mapping at IOVA pfn [0x3fe00 - 0x401ff]. On a system that does not support IOMMU super pages, the unmap_pages interface will ask to unmap 1024 4KB pages at the base IOVA. dma_pte_clear_level() will recurse down to level 2 of the page table where the first half of the pfn range exactly matches the entire pte level. We clear the pte, increment the pfn by the level size, but (oops) the next pte is on a new page, so we exit the loop an pop back up a level. When we then update the pfn based on that higher level, we seem to assume that the previous pfn value was at the start of the level. In this case the level size is 256K pfns, which we add to the base pfn and get a results of 0x7fe00, which is clearly greater than 0x401ff, so we're done. Meanwhile we never cleared the ptes for the remainder of the range. When the VM remaps this range, we're overwriting valid ptes and the VT-d driver complains loudly, as reported by the user report linked below. The fix for this seems relatively simple, if each iteration of the loop in dma_pte_clear_level() is assumed to clear to the end of the level pte page, then our next pfn should be calculated from level_pfn rather than our working pfn. Fixes: 3f34f1259776 ("iommu/vt-d: Implement map/unmap_pages() iommu_ops callback") Reported-by: Ajay Garg Signed-off-by: Alex Williamson Tested-by: Giovanni Cabiddu Link: https://lore.kernel.org/all/20211002124012.18186-1-ajaygargnsit@gmail.com/ Link: https://lore.kernel.org/r/163659074748.1617923.12716161410774184024.stgit@omen Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20211126135556.397932-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 88fc40a33ff3d5ef6a3ec5a8489036867644e256 Author: Alex Bee Date: Wed Nov 24 03:13:25 2021 +0100 iommu/rockchip: Fix PAGE_DESC_HI_MASKs for RK3568 [ Upstream commit f7ff3cff3527ff1e70cad8d2fe7c0c7b6f83120a ] With the submission of iommu driver for RK3568 a subtle bug was introduced: PAGE_DESC_HI_MASK1 and PAGE_DESC_HI_MASK2 have to be the other way arround - that leads to random errors, especially when addresses beyond 32 bit are used. Fix it. Fixes: c55356c534aa ("iommu: rockchip: Add support for iommu v2") Signed-off-by: Alex Bee Tested-by: Peter Geis Reviewed-by: Heiko Stuebner Tested-by: Dan Johansen Reviewed-by: Benjamin Gaignard Link: https://lore.kernel.org/r/20211124021325.858139-1-knaerzche@gmail.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 229c555260cb9c1ccdab861e16f0410f1718f302 Author: Mark Rutland Date: Tue Nov 23 11:40:47 2021 +0000 sched/scs: Reset task stack state in bringup_cpu() [ Upstream commit dce1ca0525bfdc8a69a9343bc714fbc19a2f04b3 ] To hot unplug a CPU, the idle task on that CPU calls a few layers of C code before finally leaving the kernel. When KASAN is in use, poisoned shadow is left around for each of the active stack frames, and when shadow call stacks are in use. When shadow call stacks (SCS) are in use the task's saved SCS SP is left pointing at an arbitrary point within the task's shadow call stack. When a CPU is offlined than onlined back into the kernel, this stale state can adversely affect execution. Stale KASAN shadow can alias new stackframes and result in bogus KASAN warnings. A stale SCS SP is effectively a memory leak, and prevents a portion of the shadow call stack being used. Across a number of hotplug cycles the idle task's entire shadow call stack can become unusable. We previously fixed the KASAN issue in commit: e1b77c92981a5222 ("sched/kasan: remove stale KASAN poison after hotplug") ... by removing any stale KASAN stack poison immediately prior to onlining a CPU. Subsequently in commit: f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled") ... the refactoring left the KASAN and SCS cleanup in one-time idle thread initialization code rather than something invoked prior to each CPU being onlined, breaking both as above. We fixed SCS (but not KASAN) in commit: 63acd42c0d4942f7 ("sched/scs: Reset the shadow stack when idle_task_exit") ... but as this runs in the context of the idle task being offlined it's potentially fragile. To fix these consistently and more robustly, reset the SCS SP and KASAN shadow of a CPU's idle task immediately before we online that CPU in bringup_cpu(). This ensures the idle task always has a consistent state when it is running, and removes the need to so so when exiting an idle task. Whenever any thread is created, dup_task_struct() will give the task a stack which is free of KASAN shadow, and initialize the task's SCS SP, so there's no need to specially initialize either for idle thread within init_idle(), as this was only necessary to handle hotplug cycles. I've tested this on arm64 with: * gcc 11.1.0, defconfig +KASAN_INLINE, KASAN_STACK * clang 12.0.0, defconfig +KASAN_INLINE, KASAN_STACK, SHADOW_CALL_STACK ... offlining and onlining CPUS with: | while true; do | for C in /sys/devices/system/cpu/cpu*/online; do | echo 0 > $C; | echo 1 > $C; | done | done Fixes: f1a0a376ca0c4ef1 ("sched/core: Initialize the idle task with preemption disabled") Reported-by: Qian Cai Signed-off-by: Mark Rutland Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Tested-by: Qian Cai Link: https://lore.kernel.org/lkml/20211115113310.35693-1-mark.rutland@arm.com/ Signed-off-by: Sasha Levin commit 5f8c2755f85014b5c43787b199c3aaca6f47fdcd Author: Marco Elver Date: Tue Nov 9 13:22:32 2021 +0100 perf: Ignore sigtrap for tracepoints destined for other tasks [ Upstream commit 73743c3b092277febbf69b250ce8ebbca0525aa2 ] syzbot reported that the warning in perf_sigtrap() fires, saying that the event's task does not match current: | WARNING: CPU: 0 PID: 9090 at kernel/events/core.c:6446 perf_pending_event+0x40d/0x4b0 kernel/events/core.c:6513 | Modules linked in: | CPU: 0 PID: 9090 Comm: syz-executor.1 Not tainted 5.15.0-syzkaller #0 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 | RIP: 0010:perf_sigtrap kernel/events/core.c:6446 [inline] | RIP: 0010:perf_pending_event_disable kernel/events/core.c:6470 [inline] | RIP: 0010:perf_pending_event+0x40d/0x4b0 kernel/events/core.c:6513 | ... | Call Trace: | | irq_work_single+0x106/0x220 kernel/irq_work.c:211 | irq_work_run_list+0x6a/0x90 kernel/irq_work.c:242 | irq_work_run+0x4f/0xd0 kernel/irq_work.c:251 | __sysvec_irq_work+0x95/0x3d0 arch/x86/kernel/irq_work.c:22 | sysvec_irq_work+0x8e/0xc0 arch/x86/kernel/irq_work.c:17 | | | asm_sysvec_irq_work+0x12/0x20 arch/x86/include/asm/idtentry.h:664 | RIP: 0010:__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:152 [inline] | RIP: 0010:_raw_spin_unlock_irqrestore+0x38/0x70 kernel/locking/spinlock.c:194 | ... | coredump_task_exit kernel/exit.c:371 [inline] | do_exit+0x1865/0x25c0 kernel/exit.c:771 | do_group_exit+0xe7/0x290 kernel/exit.c:929 | get_signal+0x3b0/0x1ce0 kernel/signal.c:2820 | arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868 | handle_signal_work kernel/entry/common.c:148 [inline] | exit_to_user_mode_loop kernel/entry/common.c:172 [inline] | exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207 | __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline] | syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300 | do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86 | entry_SYSCALL_64_after_hwframe+0x44/0xae On x86 this shouldn't happen, which has arch_irq_work_raise(). The test program sets up a perf event with sigtrap set to fire on the 'sched_wakeup' tracepoint, which fired in ttwu_do_wakeup(). This happened because the 'sched_wakeup' tracepoint also takes a task argument passed on to perf_tp_event(), which is used to deliver the event to that other task. Since we cannot deliver synchronous signals to other tasks, skip an event if perf_tp_event() is targeted at another task and perf_event_attr::sigtrap is set, which will avoid ever entering perf_sigtrap() for such events. Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events") Reported-by: syzbot+663359e32ce6f1a305ad@syzkaller.appspotmail.com Signed-off-by: Marco Elver Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/YYpoCOBmC/kJWfmI@elver.google.com Signed-off-by: Sasha Levin commit 76723ed1fb8922ee94089e7432b8a262e3a06ed7 Author: Waiman Long Date: Mon Nov 15 20:29:12 2021 -0500 locking/rwsem: Make handoff bit handling more consistent [ Upstream commit d257cc8cb8d5355ffc43a96bab94db7b5a324803 ] There are some inconsistency in the way that the handoff bit is being handled in readers and writers that lead to a race condition. Firstly, when a queue head writer set the handoff bit, it will clear it when the writer is being killed or interrupted on its way out without acquiring the lock. That is not the case for a queue head reader. The handoff bit will simply be inherited by the next waiter. Secondly, in the out_nolock path of rwsem_down_read_slowpath(), both the waiter and handoff bits are cleared if the wait queue becomes empty. For rwsem_down_write_slowpath(), however, the handoff bit is not checked and cleared if the wait queue is empty. This can potentially make the handoff bit set with empty wait queue. Worse, the situation in rwsem_down_write_slowpath() relies on wstate, a variable set outside of the critical section containing the ->count manipulation, this leads to race condition where RWSEM_FLAG_HANDOFF can be double subtracted, corrupting ->count. To make the handoff bit handling more consistent and robust, extract out handoff bit clearing code into the new rwsem_del_waiter() helper function. Also, completely eradicate wstate; always evaluate everything inside the same critical section. The common function will only use atomic_long_andnot() to clear bits when the wait queue is empty to avoid possible race condition. If the first waiter with handoff bit set is killed or interrupted to exit the slowpath without acquiring the lock, the next waiter will inherit the handoff bit. While at it, simplify the trylock for loop in rwsem_down_write_slowpath() to make it easier to read. Fixes: 4f23dbc1e657 ("locking/rwsem: Implement lock handoff to prevent lock starvation") Reported-by: Zhenhua Ma Suggested-by: Peter Zijlstra Signed-off-by: Waiman Long Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20211116012912.723980-1-longman@redhat.com Signed-off-by: Sasha Levin commit 7b9237a8ef194c5c20c3c4fba2486422ac96b1a8 Author: Vladimir Oltean Date: Fri Nov 26 19:28:45 2021 +0200 net: mscc: ocelot: correctly report the timestamping RX filters in ethtool [ Upstream commit c49a35eedfef08bffd46b53c25dbf9d6016a86ff ] The driver doesn't support RX timestamping for non-PTP packets, but it declares that it does. Restrict the reported RX filters to PTP v2 over L2 and over L4. Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support") Signed-off-by: Vladimir Oltean Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 93945f2c10bc9d69743f16ad8a71600310e09f37 Author: Vladimir Oltean Date: Fri Nov 26 19:28:41 2021 +0200 net: mscc: ocelot: don't downgrade timestamping RX filters in SIOCSHWTSTAMP [ Upstream commit 8a075464d1e9317ffae0973dfe538a7511291a06 ] The ocelot driver, when asked to timestamp all receiving packets, 1588 v1 or NTP, says "nah, here's 1588 v2 for you". According to this discussion: https://patchwork.kernel.org/project/netdevbpf/patch/20211104133204.19757-8-martin.kaistra@linutronix.de/#24577647 drivers that downgrade from a wider request to a narrower response (or even a response where the intersection with the request is empty) are buggy, and should return -ERANGE instead. This patch fixes that. Fixes: 4e3b0468e6d7 ("net: mscc: PTP Hardware Clock (PHC) support") Suggested-by: Richard Cochran Signed-off-by: Vladimir Oltean Acked-by: Richard Cochran Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d1e71d7d22820052ea7172bc7cc0603af6db8399 Author: Jie Wang Date: Fri Nov 26 20:03:18 2021 +0800 net: hns3: fix incorrect components info of ethtool --reset command [ Upstream commit 82229c4dbb8a2780f05fa1bab29c97ef7bcd21bb ] Currently, HNS3 driver doesn't clear the reset flags of components after successfully executing reset, it causes userspace info of "Components reset" and "Components not reset" is incorrect. So fix this problem by clear corresponding reset flag after reset process. Fixes: ddccc5e368a3 ("net: hns3: add support for triggering reset by ethtool") Signed-off-by: Jie Wang Signed-off-by: Guangbin Huang Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 41f967a247bf48cfc7284e2cb5bc260ee9fb47d5 Author: Guangbin Huang Date: Fri Nov 26 20:03:15 2021 +0800 net: hns3: fix VF RSS failed problem after PF enable multi-TCs [ Upstream commit 8d2ad993aa05c0768f00c886c9d369cd97a337ac ] When PF is set to multi-TCs and configured mapping relationship between priorities and TCs, the hardware will active these settings for this PF and its VFs. In this case when VF just uses one TC and its rx packets contain priority, and if the priority is not mapped to TC0, as other TCs of VF is not valid, hardware always put this kind of packets to the queue 0. It cause this kind of packets of VF can not be used RSS function. To fix this problem, set tc mode of all unused TCs of VF to the setting of TC0, then rx packet with priority which map to unused TC will be direct to TC0. Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: Guangbin Huang Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 724c50cac0d5063ab514fd7ea41e57ba4e093d10 Author: Tony Lu Date: Fri Nov 26 10:41:35 2021 +0800 net/smc: Don't call clcsock shutdown twice when smc shutdown [ Upstream commit bacb6c1e47691cda4a95056c21b5487fb7199fcc ] When applications call shutdown() with SHUT_RDWR in userspace, smc_close_active() calls kernel_sock_shutdown(), and it is called twice in smc_shutdown(). This fixes this by checking sk_state before do clcsock shutdown, and avoids missing the application's call of smc_shutdown(). Link: https://lore.kernel.org/linux-s390/1f67548e-cbf6-0dce-82b5-10288a4583bd@linux.ibm.com/ Fixes: 606a63c9783a ("net/smc: Ensure the active closing peer first closes clcsock") Signed-off-by: Tony Lu Reviewed-by: Wen Gu Acked-by: Karsten Graul Link: https://lore.kernel.org/r/20211126024134.45693-1-tonylu@linux.alibaba.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f7fc72a508cf115c273a7a29350069def1041890 Author: Ziyang Xuan Date: Fri Nov 26 09:59:42 2021 +0800 net: vlan: fix underflow for the real_dev refcnt [ Upstream commit 01d9cc2dea3fde3bad6d27f464eff463496e2b00 ] Inject error before dev_hold(real_dev) in register_vlan_dev(), and execute the following testcase: ip link add dev dummy1 type dummy ip link add name dummy1.100 link dummy1 type vlan id 100 ip link del dev dummy1 When the dummy netdevice is removed, we will get a WARNING as following: ======================================================================= refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 2 PID: 0 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0 and an endless loop of: ======================================================================= unregister_netdevice: waiting for dummy1 to become free. Usage count = -1073741824 That is because dev_put(real_dev) in vlan_dev_free() be called without dev_hold(real_dev) in register_vlan_dev(). It makes the refcnt of real_dev underflow. Move the dev_hold(real_dev) to vlan_dev_init() which is the call-back of ndo_init(). That makes dev_hold() and dev_put() for vlan's real_dev symmetrical. Fixes: 563bcbae3ba2 ("net: vlan: fix a UAF in vlan_dev_real_dev()") Reported-by: Petr Machata Suggested-by: Jakub Kicinski Signed-off-by: Ziyang Xuan Link: https://lore.kernel.org/r/20211126015942.2918542-1-william.xuanziyang@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit abfdd9e2f0f9699015d72317f74154d3e53664e6 Author: Julian Wiedmann Date: Fri Nov 26 18:55:43 2021 +0100 ethtool: ioctl: fix potential NULL deref in ethtool_set_coalesce() [ Upstream commit 0276af2176c78771da7f311621a25d7608045827 ] ethtool_set_coalesce() now uses both the .get_coalesce() and .set_coalesce() callbacks. But the check for their availability is buggy, so changing the coalesce settings on a device where the driver provides only _one_ of the callbacks results in a NULL pointer dereference instead of an -EOPNOTSUPP. Fix the condition so that the availability of both callbacks is ensured. This also matches the netlink code. Note that reproducing this requires some effort - it only affects the legacy ioctl path, and needs a specific combination of driver options: - have .get_coalesce() and .coalesce_supported but no .set_coalesce(), or - have .set_coalesce() but no .get_coalesce(). Here eg. ethtool doesn't cause the crash as it first attempts to call ethtool_get_coalesce() and bails out on error. Fixes: f3ccfda19319 ("ethtool: extend coalesce setting uAPI with CQE mode") Cc: Yufeng Mo Cc: Huazhong Tan Cc: Andrew Lunn Cc: Heiner Kallweit Signed-off-by: Julian Wiedmann Link: https://lore.kernel.org/r/20211126175543.28000-1-jwi@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e25bdbc7e951ae5728fee1f4c09485df113d013c Author: Davide Caratti Date: Wed Nov 24 17:14:40 2021 +0100 net/sched: sch_ets: don't peek at classes beyond 'nbands' [ Upstream commit de6d25924c2a8c2988c6a385990cafbe742061bf ] when the number of DRR classes decreases, the round-robin active list can contain elements that have already been freed in ets_qdisc_change(). As a consequence, it's possible to see a NULL dereference crash, caused by the attempt to call cl->qdisc->ops->peek(cl->qdisc) when cl->qdisc is NULL: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 910 Comm: mausezahn Not tainted 5.16.0-rc1+ #475 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 RIP: 0010:ets_qdisc_dequeue+0x129/0x2c0 [sch_ets] Code: c5 01 41 39 ad e4 02 00 00 0f 87 18 ff ff ff 49 8b 85 c0 02 00 00 49 39 c4 0f 84 ba 00 00 00 49 8b ad c0 02 00 00 48 8b 7d 10 <48> 8b 47 18 48 8b 40 38 0f ae e8 ff d0 48 89 c3 48 85 c0 0f 84 9d RSP: 0000:ffffbb36c0b5fdd8 EFLAGS: 00010287 RAX: ffff956678efed30 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: ffffffff9b938dc9 RDI: 0000000000000000 RBP: ffff956678efed30 R08: e2f3207fe360129c R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff956678efeac0 R13: ffff956678efe800 R14: ffff956611545000 R15: ffff95667ac8f100 FS: 00007f2aa9120740(0000) GS:ffff95667b800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000011070c000 CR4: 0000000000350ee0 Call Trace: qdisc_peek_dequeued+0x29/0x70 [sch_ets] tbf_dequeue+0x22/0x260 [sch_tbf] __qdisc_run+0x7f/0x630 net_tx_action+0x290/0x4c0 __do_softirq+0xee/0x4f8 irq_exit_rcu+0xf4/0x130 sysvec_apic_timer_interrupt+0x52/0xc0 asm_sysvec_apic_timer_interrupt+0x12/0x20 RIP: 0033:0x7f2aa7fc9ad4 Code: b9 ff ff 48 8b 54 24 18 48 83 c4 08 48 89 ee 48 89 df 5b 5d e9 ed fc ff ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa <53> 48 83 ec 10 48 8b 05 10 64 33 00 48 8b 00 48 85 c0 0f 85 84 00 RSP: 002b:00007ffe5d33fab8 EFLAGS: 00000202 RAX: 0000000000000002 RBX: 0000561f72c31460 RCX: 0000561f72c31720 RDX: 0000000000000002 RSI: 0000561f72c31722 RDI: 0000561f72c31720 RBP: 000000000000002a R08: 00007ffe5d33fa40 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 0000561f7187e380 R13: 0000000000000000 R14: 0000000000000000 R15: 0000561f72c31460 Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt intel_rapl_msr iTCO_vendor_support intel_rapl_common joydev virtio_balloon lpc_ich i2c_i801 i2c_smbus pcspkr ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel ahci libahci ghash_clmulni_intel serio_raw libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod CR2: 0000000000000018 Ensuring that 'alist' was never zeroed [1] was not sufficient, we need to remove from the active list those elements that are no more SP nor DRR. [1] https://lore.kernel.org/netdev/60d274838bf09777f0371253416e8af71360bc08.1633609148.git.dcaratti@redhat.com/ v3: fix race between ets_qdisc_change() and ets_qdisc_dequeue() delisting DRR classes beyond 'nbands' in ets_qdisc_change() with the qdisc lock acquired, thanks to Cong Wang. v2: when a NULL qdisc is found in the DRR active list, try to dequeue skb from the next list item. Reported-by: Hangbin Liu Fixes: dcc68b4d8084 ("net: sch_ets: Add a new Qdisc") Signed-off-by: Davide Caratti Link: https://lore.kernel.org/r/7a5c496eed2d62241620bdbb83eb03fb9d571c99.1637762721.git.dcaratti@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a92f0eebb8dc008b9e8c51c6f7b8c93b27a29a43 Author: Yannick Vignon Date: Wed Nov 24 16:47:31 2021 +0100 net: stmmac: Disable Tx queues when reconfiguring the interface [ Upstream commit b270bfe697367776eca2e6759a71d700fb8d82a2 ] The Tx queues were not disabled in situations where the driver needed to stop the interface to apply a new configuration. This could result in a kernel panic when doing any of the 3 following actions: * reconfiguring the number of queues (ethtool -L) * reconfiguring the size of the ring buffers (ethtool -G) * installing/removing an XDP program (ip l set dev ethX xdp) Prevent the panic by making sure netif_tx_disable is called when stopping an interface. Without this patch, the following kernel panic can be observed when doing any of the actions above: Unable to handle kernel paging request at virtual address ffff80001238d040 [....] Call trace: dwmac4_set_addr+0x8/0x10 dev_hard_start_xmit+0xe4/0x1ac sch_direct_xmit+0xe8/0x39c __dev_queue_xmit+0x3ec/0xaf0 dev_queue_xmit+0x14/0x20 [...] [ end trace 0000000000000002 ]--- Fixes: 5fabb01207a2d ("net: stmmac: Add initial XDP support") Fixes: aa042f60e4961 ("net: stmmac: Add support to Ethtool get/set ring parameters") Fixes: 0366f7e06a6be ("net: stmmac: add ethtool support for get/set channels") Signed-off-by: Yannick Vignon Link: https://lore.kernel.org/r/20211124154731.1676949-1-yannick.vignon@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b3c37092378befe90e4bb9d1a7fb308ccc5c6f90 Author: Jakub Kicinski Date: Wed Nov 24 15:25:56 2021 -0800 tls: fix replacing proto_ops [ Upstream commit f3911f73f51d1534f4db70b516cc1fcb6be05bae ] We replace proto_ops whenever TLS is configured for RX. But our replacement also overrides sendpage_locked, which will crash unless TX is also configured. Similarly we plug both of those in for TLS_HW (NIC crypto offload) even tho TLS_HW has a completely different implementation for TX. Last but not least we always plug in something based on inet_stream_ops even though a few of the callbacks differ for IPv6 (getname, release, bind). Use a callback building method similar to what we do for struct proto. Fixes: c46234ebb4d1 ("tls: RX path for ktls") Fixes: d4ffb02dee2f ("net/tls: enable sk_msg redirect to tls socket egress") Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6a012337bc701f347b7eac7e5e2584348debf83f Author: Jakub Kicinski Date: Wed Nov 24 15:25:54 2021 -0800 tls: splice_read: fix accessing pre-processed records [ Upstream commit e062fe99cccd9ff9f232e593d163ecabd244fae8 ] recvmsg() will put peek()ed and partially read records onto the rx_list. splice_read() needs to consult that list otherwise it may miss data. Align with recvmsg() and also put partially-read records onto rx_list. tls_sw_advance_skb() is pretty pointless now and will be removed in net-next. Fixes: 692d7b5d1f91 ("tls: Fix recvmsg() to be able to peek across multiple records") Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit befe4e2915943a086ec3c65dbfe536de674f21a4 Author: Jakub Kicinski Date: Wed Nov 24 15:25:52 2021 -0800 tls: splice_read: fix record type check [ Upstream commit 520493f66f6822551aef2879cd40207074fe6980 ] We don't support splicing control records. TLS 1.3 changes moved the record type check into the decrypt if(). The skb may already be decrypted and still be an alert. Note that decrypt_skb_update() is idempotent and updates ctx->decrypted so the if() is pointless. Reorder the check for decryption errors with the content type check while touching them. This part is not really a bug, because if decryption failed in TLS 1.3 content type will be DATA, and for TLS 1.2 it will be correct. Nevertheless its strange to touch output before checking if the function has failed. Fixes: fedf201e1296 ("net: tls: Refactor control message handling on recv") Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a6a75b537a4f612bf51ac40d86ce652d42fc2f4b Author: Huang Pei Date: Thu Nov 25 18:59:48 2021 +0800 MIPS: use 3-level pgtable for 64KB page size on MIPS_VA_BITS_48 [ Upstream commit 41ce097f714401e6ad8f3f5eb30d7f91b0b5e495 ] It hangup when booting Loongson 3A1000 with BOTH CONFIG_PAGE_SIZE_64KB and CONFIG_MIPS_VA_BITS_48, that it turn out to use 2-level pgtable instead of 3-level. 64KB page size with 2-level pgtable only cover 42 bits VA, use 3-level pgtable to cover all 48 bits VA(55 bits) Fixes: 1e321fa917fb ("MIPS64: Support of at least 48 bits of SEGBITS) Signed-off-by: Huang Pei Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit ea3c7588e16f62080d20fa067cfa9188d37dd329 Author: Huang Pei Date: Thu Nov 25 18:59:49 2021 +0800 MIPS: loongson64: fix FTLB configuration [ Upstream commit 7db5e9e9e5e6c10d7d26f8df7f8fd8841cb15ee7 ] It turns out that 'decode_configs' -> 'set_ftlb_enable' is called under c->cputype unset, which leaves FTLB disabled on BOTH 3A2000 and 3A3000 Fix it by calling "decode_configs" after c->cputype is initialized Fixes: da1bd29742b1 ("MIPS: Loongson64: Probe CPU features via CPUCFG") Signed-off-by: Huang Pei Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 1685d6669a847f5c9316dabb6bed1347d0b6bcfb Author: Jesse Brandeburg Date: Tue Nov 23 12:40:00 2021 -0800 igb: fix netpoll exit with traffic [ Upstream commit eaeace60778e524a2820d0c0ad60bf80289e292c ] Oleksandr brought a bug report where netpoll causes trace messages in the log on igb. Danielle brought this back up as still occurring, so we'll try again. [22038.710800] ------------[ cut here ]------------ [22038.710801] igb_poll+0x0/0x1440 [igb] exceeded budget in poll [22038.710802] WARNING: CPU: 12 PID: 40362 at net/core/netpoll.c:155 netpoll_poll_dev+0x18a/0x1a0 As Alex suggested, change the driver to return work_done at the exit of napi_poll, which should be safe to do in this driver because it is not polling multiple queues in this single napi context (multiple queues attached to one MSI-X vector). Several other drivers contain the same simple sequence, so I hope this will not create new problems. Fixes: 16eb8815c235 ("igb: Refactor clean_rx_irq to reduce overhead and improve performance") Reported-by: Oleksandr Natalenko Reported-by: Danielle Ratson Suggested-by: Alexander Duyck Signed-off-by: Jesse Brandeburg Tested-by: Oleksandr Natalenko Tested-by: Danielle Ratson Link: https://lore.kernel.org/r/20211123204000.1597971-1-jesse.brandeburg@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5585036815e54e380293b73050262cb62ec10d0c Author: Maurizio Lombardi Date: Mon Nov 22 11:08:27 2021 +0100 nvmet: use IOCB_NOWAIT only if the filesystem supports it [ Upstream commit c024b226a417c4eb9353ff500b1c823165d4d508 ] Submit I/O requests with the IOCB_NOWAIT flag set only if the underlying filesystem supports it. Fixes: 50a909db36f2 ("nvmet: use IOCB_NOWAIT for file-ns buffered I/O") Signed-off-by: Maurizio Lombardi Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a93af38c9f47df2109dfda94b8b66b49c14a94ef Author: Guo DaXing Date: Wed Nov 24 13:32:38 2021 +0100 net/smc: Fix loop in smc_listen [ Upstream commit 9ebb0c4b27a6158303b791b5b91e66d7665ee30e ] The kernel_listen function in smc_listen will fail when all the available ports are occupied. At this point smc->clcsock->sk->sk_data_ready has been changed to smc_clcsock_data_ready. When we call smc_listen again, now both smc->clcsock->sk->sk_data_ready and smc->clcsk_data_ready point to the smc_clcsock_data_ready function. The smc_clcsock_data_ready() function calls lsmc->clcsk_data_ready which now points to itself resulting in an infinite loop. This patch restores smc->clcsock->sk->sk_data_ready with the old value. Fixes: a60a2b1e0af1 ("net/smc: reduce active tcp_listen workers") Signed-off-by: Guo DaXing Acked-by: Tony Lu Signed-off-by: Karsten Graul Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit bb851d0fb02547d03cd40106b5f2391c4fed6ed1 Author: Karsten Graul Date: Wed Nov 24 13:32:37 2021 +0100 net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk() [ Upstream commit 587acad41f1bc48e16f42bb2aca63bf323380be8 ] Coverity reports a possible NULL dereferencing problem: in smc_vlan_by_tcpsk(): 6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times). 7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next. 1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &lower); CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS) 8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev. 1624 if (is_vlan_dev(ndev)) { Remove the manual implementation and use netdev_walk_all_lower_dev() to iterate over the lower devices. While on it remove an obsolete function parameter comment. Fixes: cb9d43f67754 ("net/smc: determine vlan_id of stacked net_device") Suggested-by: Julian Wiedmann Signed-off-by: Karsten Graul Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e85d50c4d85ef302ffb1a331b00648d52387fb23 Author: Russell King (Oracle) Date: Tue Nov 23 16:44:03 2021 +0100 net: phylink: Force retrigger in case of latched link-fail indicator [ Upstream commit dbae3388ea9ca33bd1d5eabc3b0ef17e69c74677 ] On mv88e6xxx 1G/2.5G PCS, the SerDes register 4.2001.2 has the following description: This register bit indicates when link was lost since the last read. For the current link status, read this register back-to-back. Thus to get current link state, we need to read the register twice. But doing that in the link change interrupt handler would lead to potentially ignoring link down events, which we really want to avoid. Thus this needs to be solved in phylink's resolve, by retriggering another resolve in the event when PCS reports link down and previous link was up, and by re-reading PCS state if the previous link was down. The wrong value is read when phylink requests change from sgmii to 2500base-x mode, and link won't come up. This fixes the bug. Fixes: 9525ae83959b ("phylink: add phylink infrastructure") Signed-off-by: Russell King (Oracle) Signed-off-by: Marek Behún Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d6525de28dfeefb30e8487f83d62b38ab840344a Author: Russell King (Oracle) Date: Tue Nov 23 16:44:02 2021 +0100 net: phylink: Force link down and retrigger resolve on interface change [ Upstream commit 80662f4fd4771bc9c7cc4abdfbe866ebd1179621 ] On PHY state change the phylink_resolve() function can read stale information from the MAC and report incorrect link speed and duplex to the kernel message log. Example with a Marvell 88X3310 PHY connected to a SerDes port on Marvell 88E6393X switch: - PHY driver triggers state change due to PHY interface mode being changed from 10gbase-r to 2500base-x due to copper change in speed from 10Gbps to 2.5Gbps, but the PHY itself either hasn't yet changed its interface to the host, or the interrupt about loss of SerDes link hadn't arrived yet (there can be a delay of several milliseconds for this), so we still think that the 10gbase-r mode is up - phylink_resolve() - phylink_mac_pcs_get_state() - this fills in speed=10g link=up - interface mode is updated to 2500base-x but speed is left at 10Gbps - phylink_major_config() - interface is changed to 2500base-x - phylink_link_up() - mv88e6xxx_mac_link_up() - .port_set_speed_duplex() - speed is set to 10Gbps - reports "Link is Up - 10Gbps/Full" to dmesg Afterwards when the interrupt finally arrives for mv88e6xxx, another resolve is forced in which we get the correct speed from phylink_mac_pcs_get_state(), but since the interface is not being changed anymore, we don't call phylink_major_config() but only phylink_mac_config(), which does not set speed/duplex anymore. To fix this, we need to force the link down and trigger another resolve on PHY interface change event. Fixes: 9525ae83959b ("phylink: add phylink infrastructure") Signed-off-by: Russell King (Oracle) Signed-off-by: Marek Behún Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit cc1645427a0f258467de1fa9ebfc293344c1a719 Author: Heiner Kallweit Date: Wed Nov 24 08:16:25 2021 +0100 lan743x: fix deadlock in lan743x_phy_link_status_change() [ Upstream commit ddb826c2c92d461f290a7bab89e7c28696191875 ] Usage of phy_ethtool_get_link_ksettings() in the link status change handler isn't needed, and in combination with the referenced change it results in a deadlock. Simply remove the call and replace it with direct access to phydev->speed. The duplex argument of lan743x_phy_update_flowcontrol() isn't used and can be removed. Fixes: c10a485c3de5 ("phy: phy_ethtool_ksettings_get: Lock the phy for consistency") Reported-by: Alessandro B Maurici Tested-by: Alessandro B Maurici Signed-off-by: Heiner Kallweit Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/40e27f76-0ba3-dcef-ee32-a78b9df38b0f@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8165a96f6b7122f25bf809aecf06f17b0ec37b58 Author: Eric Dumazet Date: Tue Nov 23 12:25:35 2021 -0800 tcp_cubic: fix spurious Hystart ACK train detections for not-cwnd-limited flows [ Upstream commit 4e1fddc98d2585ddd4792b5e44433dcee7ece001 ] While testing BIG TCP patch series, I was expecting that TCP_RR workloads with 80KB requests/answers would send one 80KB TSO packet, then being received as a single GRO packet. It turns out this was not happening, and the root cause was that cubic Hystart ACK train was triggering after a few (2 or 3) rounds of RPC. Hystart was wrongly setting CWND/SSTHRESH to 30, while my RPC needed a budget of ~20 segments. Ideally these TCP_RR flows should not exit slow start. Cubic Hystart should reset itself at each round, instead of assuming every TCP flow is a bulk one. Note that even after this patch, Hystart can still trigger, depending on scheduling artifacts, but at a higher CWND/SSTHRESH threshold, keeping optimal TSO packet sizes. Tested: ip link set dev eth0 gro_ipv6_max_size 131072 gso_ipv6_max_size 131072 nstat -n; netperf -H ... -t TCP_RR -l 5 -- -r 80000,80000 -K cubic; nstat|egrep "Ip6InReceives|Hystart|Ip6OutRequests" Before: 8605 Ip6InReceives 87541 0.0 Ip6OutRequests 129496 0.0 TcpExtTCPHystartTrainDetect 1 0.0 TcpExtTCPHystartTrainCwnd 30 0.0 After: 8760 Ip6InReceives 88514 0.0 Ip6OutRequests 87975 0.0 Fixes: ae27e98a5152 ("[TCP] CUBIC v2.3") Co-developed-by: Neal Cardwell Signed-off-by: Neal Cardwell Signed-off-by: Eric Dumazet Cc: Stephen Hemminger Cc: Yuchung Cheng Cc: Soheil Hassas Yeganeh Link: https://lore.kernel.org/r/20211123202535.1843771-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7b904ba3568dab19699948dc56728793d3e1814e Author: Nicholas Kazlauskas Date: Tue Nov 9 11:24:10 2021 -0500 drm/amd/display: Set plane update flags for all planes in reset [ Upstream commit 21431f70f6014f81b0d118ff4fcee12b00b9dd70 ] [Why] We're only setting the flags on stream[0]'s planes so this logic fails if we have more than one stream in the state. This can cause a page flip timeout with multiple displays in the configuration. [How] Index into the stream_status array using the stream index - it's a 1:1 mapping. Fixes: cdaae8371aa9 ("drm/amd/display: Handle GPU reset for DC block") Reviewed-by: Harry Wentland Acked-by: Qingqing Zhuo Signed-off-by: Nicholas Kazlauskas Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4da564004a73601e67ea609fed760f00d0682210 Author: Nicholas Kazlauskas Date: Mon Nov 8 16:49:48 2021 -0500 drm/amd/display: Fix DPIA outbox timeout after GPU reset [ Upstream commit 6eff272dbee7ad444c491c9a96d49e78e91e2161 ] [Why] The HW interrupt gets disabled after GPU reset so we don't receive notifications for HPD or AUX from DMUB - leading to timeout and black screen with (or without) DPIA links connected. [How] Re-enable the interrupt after GPU reset like we do for the other DC interrupts. Fixes: 81927e2808be ("drm/amd/display: Support for DMUB AUX") Reviewed-by: Jude Shih Acked-by: Qingqing Zhuo Signed-off-by: Nicholas Kazlauskas Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c83f27576c46bc8071141a67aa8adb471ec9bac5 Author: Thomas Zeitlhofer Date: Tue Nov 23 20:18:43 2021 +0100 PM: hibernate: use correct mode for swsusp_close() [ Upstream commit cefcf24b4d351daf70ecd945324e200d3736821e ] Commit 39fbef4b0f77 ("PM: hibernate: Get block device exclusively in swsusp_check()") changed the opening mode of the block device to (FMODE_READ | FMODE_EXCL). In the corresponding calls to swsusp_close(), the mode is still just FMODE_READ which triggers the warning in blkdev_flush_mapping() on resume from hibernate. So, use the mode (FMODE_READ | FMODE_EXCL) also when closing the device. Fixes: 39fbef4b0f77 ("PM: hibernate: Get block device exclusively in swsusp_check()") Signed-off-by: Thomas Zeitlhofer Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit fd49f1f5945a9eb59384b643282fae0da6fe0914 Author: Kumar Thangavel Date: Mon Nov 22 22:08:18 2021 +0530 net/ncsi : Add payload to be 32-bit aligned to fix dropped packets [ Upstream commit ac132852147ad303a938dda318970dd1bbdfda4e ] Update NC-SI command handler (both standard and OEM) to take into account of payload paddings in allocating skb (in case of payload size is not 32-bit aligned). The checksum field follows payload field, without taking payload padding into account can cause checksum being truncated, leading to dropped packets. Fixes: fb4ee67529ff ("net/ncsi: Add NCSI OEM command support") Signed-off-by: Kumar Thangavel Acked-by: Samuel Mendoza-Jonas Reviewed-by: Paul Menzel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ff1a30740f7aa78699cea964640df6ff4f034bb5 Author: Mark Rutland Date: Mon Nov 22 12:58:20 2021 +0000 arm64: uaccess: avoid blocking within critical sections [ Upstream commit 94902d849e85093aafcdbea2be8e2beff47233e6 ] As Vincent reports in: https://lore.kernel.org/r/20211118163417.21617-1-vincent.whitchurch@axis.com The put_user() in schedule_tail() can get stuck in a livelock, similar to a problem recently fixed on riscv in commit: 285a76bb2cf51b0c ("riscv: evaluate put_user() arg before enabling user access") In __raw_put_user() we have a critical section between uaccess_ttbr0_enable() and uaccess_ttbr0_disable() where we cannot safely call into the scheduler without having taken an exception, as schedule() and other scheduling functions will not save/restore the TTBR0 state. If either of the `x` or `ptr` arguments to __raw_put_user() contain a blocking call, we may call into the scheduler within the critical section. This can result in two problems: 1) The access within the critical section will occur without the required TTBR0 tables installed. This will fault, and where the required tables permit access, the access will be retried without the required tables, resulting in a livelock. 2) When TTBR0 SW PAN is in use, check_and_switch_context() does not modify TTBR0, leaving a stale value installed. The mappings of the blocked task will erroneously be accessible to regular accesses in the context of the new task. Additionally, if the tables are subsequently freed, local TLB maintenance required to reuse the ASID may be lost, potentially resulting in TLB corruption (e.g. in the presence of CnP). The same issue exists for __raw_get_user() in the critical section between uaccess_ttbr0_enable() and uaccess_ttbr0_disable(). A similar issue exists for __get_kernel_nofault() and __put_kernel_nofault() for the critical section between __uaccess_enable_tco_async() and __uaccess_disable_tco_async(), as the TCO state is not context-switched by direct calls into the scheduler. Here the TCO state may be lost from the context of the current task, resulting in unexpected asynchronous tag check faults. It may also be leaked to another task, suppressing expected tag check faults. To fix all of these cases, we must ensure that we do not directly call into the scheduler in their respective critical sections. This patch reworks __raw_put_user(), __raw_get_user(), __get_kernel_nofault(), and __put_kernel_nofault(), ensuring that parameters are evaluated outside of the critical sections. To make this requirement clear, comments are added describing the problem, and line spaces added to separate the critical sections from other portions of the macros. For __raw_get_user() and __raw_put_user() the `err` parameter is conditionally assigned to, and we must currently evaluate this in the critical section. This behaviour is relied upon by the signal code, which uses chains of put_user_error() and get_user_error(), checking the return value at the end. In all cases, the `err` parameter is a plain int rather than a more complex expression with a blocking call, so this is safe. In future we should try to clean up the `err` usage to remove the potential for this to be a problem. Aside from the changes to time of evaluation, there should be no functional change as a result of this patch. Reported-by: Vincent Whitchurch Link: https://lore.kernel.org/r/20211118163417.21617-1-vincent.whitchurch@axis.com Fixes: f253d827f33c ("arm64: uaccess: refactor __{get,put}_user") Signed-off-by: Mark Rutland Cc: Will Deacon Cc: Catalin Marinas Link: https://lore.kernel.org/r/20211122125820.55286-1-mark.rutland@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 85851d9ff790509a42aa12a770ead6e84e427eeb Author: Mohammed Gamal Date: Fri Nov 19 12:29:00 2021 +0100 drm/hyperv: Fix device removal on Gen1 VMs [ Upstream commit e048834c209a02e3776bcc47d43c6d863e3a67ca ] The Hyper-V DRM driver tries to free MMIO region on removing the device regardless of VM type, while Gen1 VMs don't use MMIO and hence causing the kernel to crash on a NULL pointer dereference. Fix this by making deallocating MMIO only on Gen2 machines and implement removal for Gen1 Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Signed-off-by: Mohammed Gamal Reviewed-by: Deepak Rawat Signed-off-by: Deepak Rawat Link: https://patchwork.freedesktop.org/patch/msgid/20211119112900.300537-1-mgamal@redhat.com Signed-off-by: Sasha Levin commit 63a68f37718294ab0c1d07699845b4c88f6d5f00 Author: Varun Prakash Date: Mon Nov 22 15:38:41 2021 +0530 nvmet-tcp: fix incomplete data digest send [ Upstream commit 102110efdff6beedece6ab9b51664c32ac01e2db ] Current nvmet_try_send_ddgst() code does not check whether all data digest bytes are transmitted, fix this by returning -EAGAIN if all data digest bytes are not transmitted. Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Signed-off-by: Varun Prakash Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit d10ecfd9518e35eb33ab42531cb4fb41809db8d9 Author: Adamos Ttofari Date: Fri Nov 12 09:16:57 2021 +0000 cpufreq: intel_pstate: Add Ice Lake server to out-of-band IDs [ Upstream commit cd23f02f166892603eb9f2d488152b975872b682 ] Commit fbdc21e9b038 ("cpufreq: intel_pstate: Add Icelake servers support in no-HWP mode") enabled the use of Intel P-State driver for Ice Lake servers. But it doesn't cover the case when OS can't control P-States. Therefore, for Ice Lake server, if MSR_MISC_PWR_MGMT bits 8 or 18 are enabled, then the Intel P-State driver should exit as OS can't control P-States. Fixes: fbdc21e9b038 ("cpufreq: intel_pstate: Add Icelake servers support in no-HWP mode") Signed-off-by: Adamos Ttofari Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 57e91396455e7c06012ecde014b4dca3d3393008 Author: Marek Behún Date: Mon Nov 22 21:08:34 2021 +0100 net: marvell: mvpp2: increase MTU limit when XDP enabled [ Upstream commit 7b1b62bc1e6a7b2fd5ee7a4296268eb291d23aeb ] Currently mvpp2_xdp_setup won't allow attaching XDP program if mtu > ETH_DATA_LEN (1500). The mvpp2_change_mtu on the other hand checks whether MVPP2_RX_PKT_SIZE(mtu) > MVPP2_BM_LONG_PKT_SIZE. These two checks are semantically different. Moreover this limit can be increased to MVPP2_MAX_RX_BUF_SIZE, since in mvpp2_rx we have xdp.data = data + MVPP2_MH_SIZE + MVPP2_SKB_HEADROOM; xdp.frame_sz = PAGE_SIZE; Change the checks to check whether mtu > MVPP2_MAX_RX_BUF_SIZE Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support") Signed-off-by: Marek Behún Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d815f7ca8bd7fb67a77916c922113fad9c3e82e4 Author: Alex Elder Date: Mon Nov 22 19:16:40 2021 -0600 net: ipa: kill ipa_cmd_pipeline_clear() [ Upstream commit e4e9bfb7c93d7e78aa4ad7e1c411a8df15386062 ] Calling ipa_cmd_pipeline_clear() after stopping the channel underlying the AP<-modem RX endpoint can lead to a deadlock. This occurs in the ->runtime_suspend device power operation for the IPA driver. While this callback is in progress, any other requests for power will block until the callback returns. Stopping the AP<-modem RX channel does not prevent the modem from sending another packet to this endpoint. If a packet arrives for an RX channel when the channel is stopped, an SUSPEND IPA interrupt condition will be pending. Handling an IPA interrupt requires power, so ipa_isr_thread() calls pm_runtime_get_sync() first thing. The problem occurs because a "pipeline clear" command will not complete while such a SUSPEND interrupt condition exists. So the SUSPEND IPA interrupt handler won't proceed until it gets power; that won't happen until the ->runtime_suspend callback (and its "pipeline clear" command) completes; and that can't happen while the SUSPEND interrupt condition exists. It turns out that in this case there is no need to use the "pipeline clear" command. There are scenarios in which clearing the pipeline is required while suspending, but those are not (yet) supported upstream. So a simple fix, avoiding the potential deadlock, is to stop calling ipa_cmd_pipeline_clear() in ipa_endpoint_suspend(). This removes the only user of ipa_cmd_pipeline_clear(), so get rid of that function. It can be restored again whenever it's needed. This is basically a manual revert along with an explanation for commit 6cb63ea6a39ea ("net: ipa: introduce ipa_cmd_tag_process()"). Fixes: 6cb63ea6a39ea ("net: ipa: introduce ipa_cmd_tag_process()") Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 740c461a7340130a8339ee0ebf398a423fb8101c Author: Alex Elder Date: Mon Nov 22 18:15:55 2021 -0600 net: ipa: separate disabling setup from modem stop [ Upstream commit 8afc7e471ad3c92a9c96adc62d1b67de77378bb6 ] The IPA setup_complete flag is set at the end of ipa_setup(), when the setup phase of initialization has completed successfully. This occurs as part of driver probe processing, or (if "modem-init" is specified in the DTS file) it is triggered by the "ipa-setup-ready" SMP2P interrupt generated by the modem. In the latter case, it's possible for driver shutdown (or remove) to begin while setup processing is underway, and this can't be allowed. The problem is that the setup_complete flag is not adequate to signal that setup is underway. If setup_complete is set, it will never be un-set, so that case is not a problem. But if setup_complete is false, there's a chance setup is underway. Because setup is triggered by an interrupt on a "modem-init" system, there is a simple way to ensure the value of setup_complete is safe to read. The threaded handler--if it is executing--will complete as part of a request to disable the "ipa-modem-ready" interrupt. This means that ipa_setup() (which is called from the handler) will run to completion if it was underway, or will never be called otherwise. The request to disable the "ipa-setup-ready" interrupt is currently made within ipa_modem_stop(). Instead, disable the interrupt outside that function in the two places it's called. In the case of ipa_remove(), this ensures the setup_complete flag is safe to read before we read it. Rename ipa_smp2p_disable() to be ipa_smp2p_irq_disable_setup(), to be more specific about its effect. Fixes: 530f9216a953 ("soc: qcom: ipa: AP/modem communications") Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f38aa5cfadf17fd7d67403d274faa00bb4a639ae Author: Alex Elder Date: Mon Nov 22 18:15:54 2021 -0600 net: ipa: directly disable ipa-setup-ready interrupt [ Upstream commit 33a153100bb3459479bd95d3259c2915b53fefa8 ] We currently maintain a "disabled" Boolean flag to determine whether the "ipa-setup-ready" SMP2P IRQ handler does anything. That flag must be accessed under protection of a mutex. Instead, disable the SMP2P interrupt when requested, which prevents the interrupt handler from ever being called. More importantly, it synchronizes a thread disabling the interrupt with the completion of the interrupt handler in case they run concurrently. Use the IPA setup_complete flag rather than the disabled flag in the handler to determine whether to ignore any interrupts arriving after the first. Rename the "disabled" flag to be "setup_disabled", to be specific about its purpose. Fixes: 530f9216a953 ("soc: qcom: ipa: AP/modem communications") Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit da4d70199e5d82da664a80077508d6c18f5e76df Author: Amit Cohen Date: Tue Nov 23 09:52:56 2021 +0200 mlxsw: spectrum: Protect driver from buggy firmware [ Upstream commit 63b08b1f6834bbb0b4f7783bf63b80c8c8e9a047 ] When processing port up/down events generated by the device's firmware, the driver protects itself from events reported for non-existent local ports, but not the CPU port (local port 0), which exists, but lacks a netdev. This can result in a NULL pointer dereference when calling netif_carrier_{on,off}(). Fix this by bailing early when processing an event reported for the CPU port. Problem was only observed when running on top of a buggy emulator. Fixes: 28b1987ef506 ("mlxsw: spectrum: Register CPU port with devlink") Signed-off-by: Amit Cohen Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 12dea26c05cd5b2dc70fa1ca8c4dc3c630879481 Author: Tony Lu Date: Tue Nov 23 16:25:18 2021 +0800 net/smc: Ensure the active closing peer first closes clcsock [ Upstream commit 606a63c9783a32a45bd2ef0eee393711d75b3284 ] The side that actively closed socket, it's clcsock doesn't enter TIME_WAIT state, but the passive side does it. It should show the same behavior as TCP sockets. Consider this, when client actively closes the socket, the clcsock in server enters TIME_WAIT state, which means the address is occupied and won't be reused before TIME_WAIT dismissing. If we restarted server, the service would be unavailable for a long time. To solve this issue, shutdown the clcsock in [A], perform the TCP active close progress first, before the passive closed side closing it. So that the actively closed side enters TIME_WAIT, not the passive one. Client | Server close() // client actively close | smc_release() | smc_close_active() // PEERCLOSEWAIT1 | smc_close_final() // abort or closed = 1| smc_cdc_get_slot_and_msg_send() | [A] | |smc_cdc_msg_recv_action() // ACTIVE | queue_work(smc_close_wq, &conn->close_work) | smc_close_passive_work() // PROCESSABORT or APPCLOSEWAIT1 | smc_close_passive_abort_received() // only in abort | |close() // server recv zero, close | smc_release() // PROCESSABORT or APPCLOSEWAIT1 | smc_close_active() | smc_close_abort() or smc_close_final() // CLOSED | smc_cdc_get_slot_and_msg_send() // abort or closed = 1 smc_cdc_msg_recv_action() | smc_clcsock_release() queue_work(smc_close_wq, &conn->close_work) | sock_release(tcp) // actively close clc, enter TIME_WAIT smc_close_passive_work() // PEERCLOSEWAIT1 | smc_conn_free() smc_close_passive_abort_received() // CLOSED| smc_conn_free() | smc_clcsock_release() | sock_release(tcp) // passive close clc | Link: https://www.spinics.net/lists/netdev/msg780407.html Fixes: b38d732477e4 ("smc: socket closing and linkgroup cleanup") Signed-off-by: Tony Lu Reviewed-by: Wen Gu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cc432b0727ce404cc13e8f6b5ce29f412c3f9f1f Author: Vincent Whitchurch Date: Thu Nov 11 17:04:11 2021 +0100 i2c: virtio: disable timeout handling [ Upstream commit 84e1d0bf1d7121759622dabf8fbef4c99ad597c5 ] If a timeout is hit, it can result is incorrect data on the I2C bus and/or memory corruptions in the guest since the device can still be operating on the buffers it was given while the guest has freed them. Here is, for example, the start of a slub_debug splat which was triggered on the next transfer after one transfer was forced to timeout by setting a breakpoint in the backend (rust-vmm/vhost-device): BUG kmalloc-1k (Not tainted): Poison overwritten First byte 0x1 instead of 0x6b Allocated in virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29 __kmalloc+0xc2/0x1c9 virtio_i2c_xfer+0x65/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 Freed in virtio_i2c_xfer+0x32e/0x35c age=244 cpu=0 pid=29 kfree+0x1bd/0x1cc virtio_i2c_xfer+0x32e/0x35c __i2c_transfer+0x429/0x57d i2c_transfer+0x115/0x134 i2cdev_ioctl_rdwr+0x16a/0x1de i2cdev_ioctl+0x247/0x2ed vfs_ioctl+0x21/0x30 sys_ioctl+0xb18/0xb41 There is no simple fix for this (the driver would have to always create bounce buffers and hold on to them until the device eventually returns the buffers), so just disable the timeout support for now. Fixes: 3cfc88380413d20f ("i2c: virtio: add a virtio i2c frontend driver") Acked-by: Jie Deng Signed-off-by: Vincent Whitchurch Acked-by: Michael S. Tsirkin Reviewed-by: Viresh Kumar Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 4339cd0825946b6695a7c403dd48df14e9f66512 Author: Huang Jianan Date: Thu Nov 18 21:58:44 2021 +0800 erofs: fix deadlock when shrink erofs slab [ Upstream commit 57bbeacdbee72a54eb97d56b876cf9c94059fc34 ] We observed the following deadlock in the stress test under low memory scenario: Thread A Thread B - erofs_shrink_scan - erofs_try_to_release_workgroup - erofs_workgroup_try_to_freeze -- A - z_erofs_do_read_page - z_erofs_collection_begin - z_erofs_register_collection - erofs_insert_workgroup - xa_lock(&sbi->managed_pslots) -- B - erofs_workgroup_get - erofs_wait_on_workgroup_freezed -- A - xa_erase - xa_lock(&sbi->managed_pslots) -- B To fix this, it needs to hold xa_lock before freezing the workgroup since xarray will be touched then. So let's hold the lock before accessing each workgroup, just like what we did with the radix tree before. [ Gao Xiang: Jianhua Hao also reports this issue at https://lore.kernel.org/r/b10b85df30694bac8aadfe43537c897a@xiaomi.com ] Link: https://lore.kernel.org/r/20211118135844.3559-1-huangjianan@oppo.com Fixes: 64094a04414f ("erofs: convert workstn to XArray") Reviewed-by: Chao Yu Reviewed-by: Gao Xiang Signed-off-by: Huang Jianan Reported-by: Jianhua Hao Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 8b3b9aaada48297d4a1b10b248cbace3c973601e Author: Shin'ichiro Kawasaki Date: Mon Nov 22 15:12:23 2021 +0900 scsi: scsi_debug: Zero clear zones at reset write pointer [ Upstream commit 2d62253eb1b60f4ce8b39125eee282739b519297 ] When a reset is requested the position of the write pointer is updated but the data in the corresponding zone is not cleared. Instead scsi_debug returns any data written before the write pointer was reset. This is an error and prevents using scsi_debug for stale page cache testing of the BLKRESETZONE ioctl. Zero written data in the zone when resetting the write pointer. Link: https://lore.kernel.org/r/20211122061223.298890-1-shinichiro.kawasaki@wdc.com Fixes: f0d1cf9378bd ("scsi: scsi_debug: Add ZBC zone commands") Reviewed-by: Damien Le Moal Acked-by: Douglas Gilbert Signed-off-by: Shin'ichiro Kawasaki Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a67c045b555887a4fc3ef8f03708c63c95ccbf1e Author: Mike Christie Date: Sat Nov 20 10:49:17 2021 -0600 scsi: core: sysfs: Fix setting device state to SDEV_RUNNING [ Upstream commit eb97545d6264b341b06ba7603f52ff6c0b2af6ea ] This fixes an issue added in commit 4edd8cd4e86d ("scsi: core: sysfs: Fix hang when device state is set via sysfs") where if userspace is requesting to set the device state to SDEV_RUNNING when the state is already SDEV_RUNNING, we return -EINVAL instead of count. The commmit above set ret to count for this case, when it should have set it to 0. Link: https://lore.kernel.org/r/20211120164917.4924-1-michael.christie@oracle.com Fixes: 4edd8cd4e86d ("scsi: core: sysfs: Fix hang when device state is set via sysfs") Reviewed-by: Lee Duncan Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1f10b09ccc832698ef4624a6ab9a213b6ccbda76 Author: Marta Plantykow Date: Tue Oct 26 18:47:19 2021 +0200 ice: avoid bpf_prog refcount underflow [ Upstream commit f65ee535df775a13a1046c0a0b2d72db342f8a5b ] Ice driver has the routines for managing XDP resources that are shared between ndo_bpf op and VSI rebuild flow. The latter takes place for example when user changes queue count on an interface via ethtool's set_channels(). There is an issue around the bpf_prog refcounting when VSI is being rebuilt - since ice_prepare_xdp_rings() is called with vsi->xdp_prog as an argument that is used later on by ice_vsi_assign_bpf_prog(), same bpf_prog pointers are swapped with each other. Then it is also interpreted as an 'old_prog' which in turn causes us to call bpf_prog_put on it that will decrement its refcount. Below splat can be interpreted in a way that due to zero refcount of a bpf_prog it is wiped out from the system while kernel still tries to refer to it: [ 481.069429] BUG: unable to handle page fault for address: ffffc9000640f038 [ 481.077390] #PF: supervisor read access in kernel mode [ 481.083335] #PF: error_code(0x0000) - not-present page [ 481.089276] PGD 100000067 P4D 100000067 PUD 1001cb067 PMD 106d2b067 PTE 0 [ 481.097141] Oops: 0000 [#1] PREEMPT SMP PTI [ 481.101980] CPU: 12 PID: 3339 Comm: sudo Tainted: G OE 5.15.0-rc5+ #1 [ 481.110840] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016 [ 481.122021] RIP: 0010:dev_xdp_prog_id+0x25/0x40 [ 481.127265] Code: 80 00 00 00 00 0f 1f 44 00 00 89 f6 48 c1 e6 04 48 01 fe 48 8b 86 98 08 00 00 48 85 c0 74 13 48 8b 50 18 31 c0 48 85 d2 74 07 <48> 8b 42 38 8b 40 20 c3 48 8b 96 90 08 00 00 eb e8 66 2e 0f 1f 84 [ 481.148991] RSP: 0018:ffffc90007b63868 EFLAGS: 00010286 [ 481.155034] RAX: 0000000000000000 RBX: ffff889080824000 RCX: 0000000000000000 [ 481.163278] RDX: ffffc9000640f000 RSI: ffff889080824010 RDI: ffff889080824000 [ 481.171527] RBP: ffff888107af7d00 R08: 0000000000000000 R09: ffff88810db5f6e0 [ 481.179776] R10: 0000000000000000 R11: ffff8890885b9988 R12: ffff88810db5f4bc [ 481.188026] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 481.196276] FS: 00007f5466d5bec0(0000) GS:ffff88903fb00000(0000) knlGS:0000000000000000 [ 481.205633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 481.212279] CR2: ffffc9000640f038 CR3: 000000014429c006 CR4: 00000000003706e0 [ 481.220530] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 481.228771] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 481.237029] Call Trace: [ 481.239856] rtnl_fill_ifinfo+0x768/0x12e0 [ 481.244602] rtnl_dump_ifinfo+0x525/0x650 [ 481.249246] ? __alloc_skb+0xa5/0x280 [ 481.253484] netlink_dump+0x168/0x3c0 [ 481.257725] netlink_recvmsg+0x21e/0x3e0 [ 481.262263] ____sys_recvmsg+0x87/0x170 [ 481.266707] ? __might_fault+0x20/0x30 [ 481.271046] ? _copy_from_user+0x66/0xa0 [ 481.275591] ? iovec_from_user+0xf6/0x1c0 [ 481.280226] ___sys_recvmsg+0x82/0x100 [ 481.284566] ? sock_sendmsg+0x5e/0x60 [ 481.288791] ? __sys_sendto+0xee/0x150 [ 481.293129] __sys_recvmsg+0x56/0xa0 [ 481.297267] do_syscall_64+0x3b/0xc0 [ 481.301395] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 481.307238] RIP: 0033:0x7f5466f39617 [ 481.311373] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bd 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2f 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 [ 481.342944] RSP: 002b:00007ffedc7f4308 EFLAGS: 00000246 ORIG_RAX: 000000000000002f [ 481.361783] RAX: ffffffffffffffda RBX: 00007ffedc7f5460 RCX: 00007f5466f39617 [ 481.380278] RDX: 0000000000000000 RSI: 00007ffedc7f5360 RDI: 0000000000000003 [ 481.398500] RBP: 00007ffedc7f53f0 R08: 0000000000000000 R09: 000055d556f04d50 [ 481.416463] R10: 0000000000000077 R11: 0000000000000246 R12: 00007ffedc7f5360 [ 481.434131] R13: 00007ffedc7f5350 R14: 00007ffedc7f5344 R15: 0000000000000e98 [ 481.451520] Modules linked in: ice(OE) af_packet binfmt_misc nls_iso8859_1 ipmi_ssif intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp mxm_wmi mei_me coretemp mei ipmi_si ipmi_msghandler wmi acpi_pad acpi_power_meter ip_tables x_tables autofs4 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel ahci crypto_simd cryptd libahci lpc_ich [last unloaded: ice] [ 481.528558] CR2: ffffc9000640f038 [ 481.542041] ---[ end trace d1f24c9ecf5b61c1 ]--- Fix this by only calling ice_vsi_assign_bpf_prog() inside ice_prepare_xdp_rings() when current vsi->xdp_prog pointer is NULL. This way set_channels() flow will not attempt to swap the vsi->xdp_prog pointers with itself. Also, sprinkle around some comments that provide a reasoning about correlation between driver and kernel in terms of bpf_prog refcount. Fixes: efc2214b6047 ("ice: Add support for XDP") Reviewed-by: Alexander Lobakin Signed-off-by: Marta Plantykow Co-developed-by: Maciej Fijalkowski Signed-off-by: Maciej Fijalkowski Tested-by: Kiran Bhandare Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 992ba40a67638dfe2772b84dfc8168dc328d5c4c Author: Maciej Fijalkowski Date: Tue Oct 26 18:47:18 2021 +0200 ice: fix vsi->txq_map sizing [ Upstream commit 792b2086584f25d84081a526beee80d103c2a913 ] The approach of having XDP queue per CPU regardless of user's setting exposed a hidden bug that could occur in case when Rx queue count differ from Tx queue count. Currently vsi->txq_map's size is equal to the doubled vsi->alloc_txq, which is not correct due to the fact that XDP rings were previously based on the Rx queue count. Below splat can be seen when ethtool -L is used and XDP rings are configured: [ 682.875339] BUG: kernel NULL pointer dereference, address: 000000000000000f [ 682.883403] #PF: supervisor read access in kernel mode [ 682.889345] #PF: error_code(0x0000) - not-present page [ 682.895289] PGD 0 P4D 0 [ 682.898218] Oops: 0000 [#1] PREEMPT SMP PTI [ 682.903055] CPU: 42 PID: 2878 Comm: ethtool Tainted: G OE 5.15.0-rc5+ #1 [ 682.912214] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016 [ 682.923380] RIP: 0010:devres_remove+0x44/0x130 [ 682.928527] Code: 49 89 f4 55 48 89 fd 4c 89 ff 53 48 83 ec 10 e8 92 b9 49 00 48 8b 9d a8 02 00 00 48 8d 8d a0 02 00 00 49 89 c2 48 39 cb 74 0f <4c> 3b 63 10 74 25 48 8b 5b 08 48 39 cb 75 f1 4c 89 ff 4c 89 d6 e8 [ 682.950237] RSP: 0018:ffffc90006a679f0 EFLAGS: 00010002 [ 682.956285] RAX: 0000000000000286 RBX: ffffffffffffffff RCX: ffff88908343a370 [ 682.964538] RDX: 0000000000000001 RSI: ffffffff81690d60 RDI: 0000000000000000 [ 682.972789] RBP: ffff88908343a0d0 R08: 0000000000000000 R09: 0000000000000000 [ 682.981040] R10: 0000000000000286 R11: 3fffffffffffffff R12: ffffffff81690d60 [ 682.989282] R13: ffffffff81690a00 R14: ffff8890819807a8 R15: ffff88908343a36c [ 682.997535] FS: 00007f08c7bfa740(0000) GS:ffff88a03fd00000(0000) knlGS:0000000000000000 [ 683.006910] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 683.013557] CR2: 000000000000000f CR3: 0000001080a66003 CR4: 00000000003706e0 [ 683.021819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 683.030075] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 683.038336] Call Trace: [ 683.041167] devm_kfree+0x33/0x50 [ 683.045004] ice_vsi_free_arrays+0x5e/0xc0 [ice] [ 683.050380] ice_vsi_rebuild+0x4c8/0x750 [ice] [ 683.055543] ice_vsi_recfg_qs+0x9a/0x110 [ice] [ 683.060697] ice_set_channels+0x14f/0x290 [ice] [ 683.065962] ethnl_set_channels+0x333/0x3f0 [ 683.070807] genl_family_rcv_msg_doit+0xea/0x150 [ 683.076152] genl_rcv_msg+0xde/0x1d0 [ 683.080289] ? channels_prepare_data+0x60/0x60 [ 683.085432] ? genl_get_cmd+0xd0/0xd0 [ 683.089667] netlink_rcv_skb+0x50/0xf0 [ 683.094006] genl_rcv+0x24/0x40 [ 683.097638] netlink_unicast+0x239/0x340 [ 683.102177] netlink_sendmsg+0x22e/0x470 [ 683.106717] sock_sendmsg+0x5e/0x60 [ 683.110756] __sys_sendto+0xee/0x150 [ 683.114894] ? handle_mm_fault+0xd0/0x2a0 [ 683.119535] ? do_user_addr_fault+0x1f3/0x690 [ 683.134173] __x64_sys_sendto+0x25/0x30 [ 683.148231] do_syscall_64+0x3b/0xc0 [ 683.161992] entry_SYSCALL_64_after_hwframe+0x44/0xae Fix this by taking into account the value that num_possible_cpus() yields in addition to vsi->alloc_txq instead of doubling the latter. Fixes: efc2214b6047 ("ice: Add support for XDP") Fixes: 22bf877e528f ("ice: introduce XDP_TX fallback path") Reviewed-by: Alexander Lobakin Signed-off-by: Maciej Fijalkowski Tested-by: Kiran Bhandare Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 6652101175c524f0dca7cb2ee63ae2df3a4c03dd Author: Nikolay Aleksandrov Date: Mon Nov 22 17:15:13 2021 +0200 net: nexthop: release IPv6 per-cpu dsts when replacing a nexthop group [ Upstream commit 1005f19b9357b81aa64e1decd08d6e332caaa284 ] When replacing a nexthop group, we must release the IPv6 per-cpu dsts of the removed nexthop entries after an RCU grace period because they contain references to the nexthop's net device and to the fib6 info. With specific series of events[1] we can reach net device refcount imbalance which is unrecoverable. IPv4 is not affected because dsts don't take a refcount on the route. [1] $ ip nexthop list id 200 via 2002:db8::2 dev bridge.10 scope link onlink id 201 via 2002:db8::3 dev bridge scope link onlink id 203 group 201/200 $ ip -6 route 2001:db8::10 nhid 203 metric 1024 pref medium nexthop via 2002:db8::3 dev bridge weight 1 onlink nexthop via 2002:db8::2 dev bridge.10 weight 1 onlink Create rt6_info through one of the multipath legs, e.g.: $ taskset -a -c 1 ./pkt_inj 24 bridge.10 2001:db8::10 (pkt_inj is just a custom packet generator, nothing special) Then remove that leg from the group by replace (let's assume it is id 200 in this case): $ ip nexthop replace id 203 group 201 Now remove the IPv6 route: $ ip -6 route del 2001:db8::10/128 The route won't be really deleted due to the stale rt6_info holding 1 refcnt in nexthop id 200. At this point we have the following reference count dependency: (deleted) IPv6 route holds 1 reference over nhid 203 nh 203 holds 1 ref over id 201 nh 200 holds 1 ref over the net device and the route due to the stale rt6_info Now to create circular dependency between nh 200 and the IPv6 route, and also to get a reference over nh 200, restore nhid 200 in the group: $ ip nexthop replace id 203 group 201/200 And now we have a permanent circular dependncy because nhid 203 holds a reference over nh 200 and 201, but the route holds a ref over nh 203 and is deleted. To trigger the bug just delete the group (nhid 203): $ ip nexthop del id 203 It won't really be deleted due to the IPv6 route dependency, and now we have 2 unlinked and deleted objects that reference each other: the group and the IPv6 route. Since the group drops the reference it holds over its entries at free time (i.e. its own refcount needs to drop to 0) that will never happen and we get a permanent ref on them, since one of the entries holds a reference over the IPv6 route it will also never be released. At this point the dependencies are: (deleted, only unlinked) IPv6 route holds reference over group nh 203 (deleted, only unlinked) group nh 203 holds reference over nh 201 and 200 nh 200 holds 1 ref over the net device and the route due to the stale rt6_info This is the last point where it can be fixed by running traffic through nh 200, and specifically through the same CPU so the rt6_info (dst) will get released due to the IPv6 genid, that in turn will free the IPv6 route, which in turn will free the ref count over the group nh 203. If nh 200 is deleted at this point, it will never be released due to the ref from the unlinked group 203, it will only be unlinked: $ ip nexthop del id 200 $ ip nexthop $ Now we can never release that stale rt6_info, we have IPv6 route with ref over group nh 203, group nh 203 with ref over nh 200 and 201, nh 200 with rt6_info (dst) with ref over the net device and the IPv6 route. All of these objects are only unlinked, and cannot be released, thus they can't release their ref counts. Message from syslogd@dev at Nov 19 14:04:10 ... kernel:[73501.828730] unregister_netdevice: waiting for bridge.10 to become free. Usage count = 3 Message from syslogd@dev at Nov 19 14:04:20 ... kernel:[73512.068811] unregister_netdevice: waiting for bridge.10 to become free. Usage count = 3 Fixes: 7bf4796dd099 ("nexthops: add support for replace") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e085ae661afe423068228374dadd01a2e2f33887 Author: Nikolay Aleksandrov Date: Mon Nov 22 17:15:12 2021 +0200 net: ipv6: add fib6_nh_release_dsts stub [ Upstream commit 8837cbbf854246f5f4d565f21e6baa945d37aded ] We need a way to release a fib6_nh's per-cpu dsts when replacing nexthops otherwise we can end up with stale per-cpu dsts which hold net device references, so add a new IPv6 stub called fib6_nh_release_dsts. It must be used after an RCU grace period, so no new dsts can be created through a group's nexthop entry. Similar to fib6_nh_release it shouldn't be used if fib6_nh_init has failed so it doesn't need a dummy stub when IPv6 is not enabled. Fixes: 7bf4796dd099 ("nexthops: add support for replace") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8d196fa5a901239693bfcc119791cb8c3e18fa98 Author: Holger Assmann Date: Sun Nov 21 19:57:04 2021 +0200 net: stmmac: retain PTP clock time during SIOCSHWTSTAMP ioctls [ Upstream commit a6da2bbb0005e6b4909472962c9d0af29e75dd06 ] Currently, when user space emits SIOCSHWTSTAMP ioctl calls such as enabling/disabling timestamping or changing filter settings, the driver reads the current CLOCK_REALTIME value and programming this into the NIC's hardware clock. This might be necessary during system initialization, but at runtime, when the PTP clock has already been synchronized to a grandmaster, a reset of the timestamp settings might result in a clock jump. Furthermore, if the clock is also controlled by phc2sys in automatic mode (where the UTC offset is queried from ptp4l), that UTC-to-TAI offset (currently 37 seconds in 2021) would be temporarily reset to 0, and it would take a long time for phc2sys to readjust so that CLOCK_REALTIME and the PHC are apart by 37 seconds again. To address the issue, we introduce a new function called stmmac_init_tstamp_counter(), which gets called during ndo_open(). It contains the code snippet moved from stmmac_hwtstamp_set() that manages the time synchronization. Besides, the sub second increment configuration is also moved here since the related values are hardware dependent and runtime invariant. Furthermore, the hardware clock must be kept running even when no time stamping mode is selected in order to retain the synchronized time base. That way, timestamping can be enabled again at any time only with the need to compensate the clock's natural drifting. As a side effect, this patch fixes the issue that ptp_clock_info::enable can be called before SIOCSHWTSTAMP and the driver (which looks at priv->systime_flags) was not prepared to handle that ordering. Fixes: 92ba6888510c ("stmmac: add the support for PTP hw clock driver") Reported-by: Michael Olbrich Signed-off-by: Ahmad Fatoum Signed-off-by: Holger Assmann Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f6cd576855671ff94f62c57f3d8ecf5fa09b1e30 Author: Diana Wang Date: Fri Nov 19 14:38:03 2021 +0100 nfp: checking parameter process for rx-usecs/tx-usecs is invalid [ Upstream commit 3bd6b2a838ba6a3b86d41b077f570b1b61174def ] Use nn->tlv_caps.me_freq_mhz instead of nn->me_freq_mhz to check whether rx-usecs/tx-usecs is valid. This is because nn->tlv_caps.me_freq_mhz represents the clock_freq (MHz) of the flow processing cores (FPC) on the NIC. While nn->me_freq_mhz is not be set. Fixes: ce991ab6662a ("nfp: read ME frequency from vNIC ctrl memory") Signed-off-by: Diana Wang Signed-off-by: Simon Horman Reviewed-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f1f243c06675914ed5f50fea813c9620dae68dd2 Author: Eric Dumazet Date: Thu Nov 18 17:37:58 2021 -0800 ipv6: fix typos in __ip6_finish_output() [ Upstream commit 19d36c5f294879949c9d6f57cb61d39cc4c48553 ] We deal with IPv6 packets, so we need to use IP6CB(skb)->flags and IP6SKB_REROUTED, instead of IPCB(skb)->flags and IPSKB_REROUTED Found by code inspection, please double check that fixing this bug does not surface other bugs. Fixes: 09ee9dba9611 ("ipv6: Reinject IPv6 packets if IPsec policy matches after SNAT") Signed-off-by: Eric Dumazet Cc: Tobias Brunner Cc: Steffen Klassert Cc: David Ahern Reviewed-by: David Ahern Tested-by: Tobias Brunner Acked-by: Tobias Brunner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 88f6b5f10fd199f3dc2c5362e6e8507fb24fce0e Author: Michael Kelley Date: Fri Nov 19 15:39:01 2021 -0800 firmware: smccc: Fix check for ARCH_SOC_ID not implemented [ Upstream commit e95d8eaee21cd0d117d34125d4cdc97489c1ab82 ] The ARCH_FEATURES function ID is a 32-bit SMC call, which returns a 32-bit result per the SMCCC spec. Current code is doing a 64-bit comparison against -1 (SMCCC_RET_NOT_SUPPORTED) to detect that the feature is unimplemented. That check doesn't work in a Hyper-V VM, where the upper 32-bits are zero as allowed by the spec. Cast the result as an 'int' so the comparison works. The change also makes the code consistent with other similar checks in this file. Fixes: 821b67fa4639 ("firmware: smccc: Add ARCH_SOC_ID support") Signed-off-by: Michael Kelley Reviewed-by: Sudeep Holla Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 80d709875d920f7ca959040457b7393df706fe44 Author: Vincent Whitchurch Date: Fri Nov 19 13:05:21 2021 +0100 af_unix: fix regression in read after shutdown [ Upstream commit f9390b249c90a15a4d9e69fbfb7a53c860b1fcaf ] On kernels before v5.15, calling read() on a unix socket after shutdown(SHUT_RD) or shutdown(SHUT_RDWR) would return the data previously written or EOF. But now, while read() after shutdown(SHUT_RD) still behaves the same way, read() after shutdown(SHUT_RDWR) always fails with -EINVAL. This behaviour change was apparently inadvertently introduced as part of a bug fix for a different regression caused by the commit adding sockmap support to af_unix, commit 94531cfcbe79c359 ("af_unix: Add unix_stream_proto for sockmap"). Those commits, for unclear reasons, started setting the socket state to TCP_CLOSE on shutdown(SHUT_RDWR), while this state change had previously only been done in unix_release_sock(). Restore the original behaviour. The sockmap tests in tests/selftests/bpf continue to pass after this patch. Fixes: d0c6416bd7091647f60 ("unix: Fix an issue in unix_shutdown causing the other end read/write failures") Link: https://lore.kernel.org/lkml/20211111140000.GA10779@axis.com/ Signed-off-by: Vincent Whitchurch Tested-by: Casey Schaufler Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 97e5d85030c5544e704d5367414b5aca846581e7 Author: Paolo Abeni Date: Fri Nov 19 15:27:55 2021 +0100 mptcp: use delegate action to schedule 3rd ack retrans [ Upstream commit bcd97734318d1d87bb237dbc0a60c81237b0ac50 ] Scheduling a delack in mptcp_established_options_mp() is not a good idea: such function is called by tcp_send_ack() and the pending delayed ack will be cleared shortly after by the tcp_event_ack_sent() call in __tcp_transmit_skb(). Instead use the mptcp delegated action infrastructure to schedule the delayed ack after the current bh processing completes. Additionally moves the schedule_3rdack_retransmission() helper into protocol.c to avoid making it visible in a different compilation unit. Fixes: ec3edaa7ca6ce02f ("mptcp: Add handling of outgoing MP_JOIN requests") Reviewed-by: Mat Martineau @linux.intel.com> Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 10ef3a1c9377e2d1e38697a954788402e06b8ef0 Author: Eric Dumazet Date: Fri Nov 19 15:27:54 2021 +0100 mptcp: fix delack timer [ Upstream commit ee50e67ba0e17b1a1a8d76691d02eadf9e0f392c ] To compute the rtx timeout schedule_3rdack_retransmission() does multiple things in the wrong way: srtt_us is measured in usec/8 and the timeout itself is an absolute value. Fixes: ec3edaa7ca6ce02f ("mptcp: Add handling of outgoing MP_JOIN requests") Acked-by: Paolo Abeni Reviewed-by: Mat Martineau @linux.intel.com> Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 26c3603a2a885cfd0b717788cd2342f085026bec Author: Pierre-Louis Bossart Date: Wed Oct 27 10:32:54 2021 +0800 ALSA: intel-dsp-config: add quirk for JSL devices based on ES8336 codec [ Upstream commit fa9730b4f28b7bd183d28a0bf636ab7108de35d7 ] These devices are based on an I2C/I2S device, we need to force the use of the SOF driver otherwise the legacy HDaudio driver will be loaded - only HDMI will be supported. We previously added support for other Intel platforms but missed JasperLake. BugLink: https://github.com/thesofproject/linux/issues/3210 Fixes: 9d36ceab9415 ('ALSA: intel-dsp-config: add quirk for APL/GLK/TGL devices based on ES8336 codec') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Kai Vehmanen Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20211027023254.24955-1-yung-chuan.liao@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c6db0b15ced03150640b375e5192a7c136542fcc Author: Juergen Gross Date: Fri Nov 19 16:39:13 2021 +0100 xen/pvh: add missing prototype to header [ Upstream commit 2a0991929aba0a3dd6fe51d1daba06a93a96a021 ] The prototype of mem_map_via_hcall() is missing in its header, so add it. Reported-by: kernel test robot Fixes: a43fb7da53007e67ad ("xen/pvh: Move Xen code for getting mem map via hcall out of common file") Signed-off-by: Juergen Gross Link: https://lore.kernel.org/r/20211119153913.21678-1-jgross@suse.com Reviewed-by: Boris Ostrovsky Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin commit 7c7cfc9da0267ffa397a3242fe0d00b5d5f01408 Author: Juergen Gross Date: Wed Oct 6 08:19:50 2021 +0200 x86/pvh: add prototype for xen_pvh_init() [ Upstream commit 767216796cb9ae7f1e3bdf43a7b13b2bf100c2d2 ] xen_pvh_init() is lacking a prototype in a header, add it. Reported-by: kernel test robot Signed-off-by: Juergen Gross Link: https://lore.kernel.org/r/20211006061950.9227-1-jgross@suse.com Reviewed-by: Boris Ostrovsky Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin commit 229e70bf02d54b6c7bab1f18244c16c41dfae093 Author: Brett Creeley Date: Fri Nov 5 09:20:25 2021 -0700 iavf: Fix VLAN feature flags after VFR [ Upstream commit 5951a2b9812d8227d33f20d1899fae60e4f72c04 ] When a VF goes through a reset, it's possible for the VF's feature set to change. For example it may lose the VIRTCHNL_VF_OFFLOAD_VLAN capability after VF reset. Unfortunately, the driver doesn't correctly deal with this situation and errors are seen from downing/upping the interface and/or moving the interface in/out of a network namespace. When setting the interface down/up we see the following errors after the VIRTCHNL_VF_OFFLOAD_VLAN capability was taken away from the VF: ice 0000:51:00.1: VF 1 failed opcode 12, retval: -64 iavf 0000:51:09.1: Failed to add VLAN filter, error IAVF_NOT_SUPPORTED ice 0000:51:00.1: VF 1 failed opcode 13, retval: -64 iavf 0000:51:09.1: Failed to delete VLAN filter, error IAVF_NOT_SUPPORTED These add/delete errors are happening because the VLAN filters are tracked internally to the driver and regardless of the VLAN_ALLOWED() setting the driver tries to delete/re-add them over virtchnl. Fix the delete failure by making sure to delete any VLAN filter tracking in the driver when a removal request is made, while preventing the virtchnl request. This makes it so the driver's VLAN list is up to date and the errors are Fix the add failure by making sure the check for VLAN_ALLOWED() during reset is done after the VF receives its capability list from the PF via VIRTCHNL_OP_GET_VF_RESOURCES. If VLAN functionality is not allowed, then prevent requesting re-adding the filters over virtchnl. When moving the interface into a network namespace we see the following errors after the VIRTCHNL_VF_OFFLOAD_VLAN capability was taken away from the VF: iavf 0000:51:09.1 enp81s0f1v1: NIC Link is Up Speed is 25 Gbps Full Duplex iavf 0000:51:09.1 temp_27: renamed from enp81s0f1v1 iavf 0000:51:09.1 mgmt: renamed from temp_27 iavf 0000:51:09.1 dev27: set_features() failed (-22); wanted 0x020190001fd54833, left 0x020190001fd54bb3 These errors are happening because we aren't correctly updating the netdev capabilities and dealing with ndo_fix_features() and ndo_set_features() correctly. Fix this by only reporting errors in the driver's ndo_set_features() callback when VIRTCHNL_VF_OFFLOAD_VLAN is not allowed and any attempt to enable the VLAN features is made. Also, make sure to disable VLAN insertion, filtering, and stripping since the VIRTCHNL_VF_OFFLOAD_VLAN flag applies to all of them and not just VLAN stripping. Also, after we process the capabilities in the VF reset path, make sure to call netdev_update_features() in case the capabilities have changed in order to update the netdev's feature set to match the VF's actual capabilities. Lastly, make sure to always report success on VLAN filter delete when VIRTCHNL_VF_OFFLOAD_VLAN is not supported. The changed flow in iavf_del_vlans() allows the stack to delete previosly existing VLAN filters even if VLAN filtering is not allowed. This makes it so the VLAN filter list is up to date. Fixes: 8774370d268f ("i40e/i40evf: support for VF VLAN tag stripping control") Signed-off-by: Brett Creeley Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 8d4b4e0f011479c17d588edbbba7b2a6de320ec6 Author: Jedrzej Jagielski Date: Wed Sep 15 09:01:00 2021 +0000 iavf: Fix refreshing iavf adapter stats on ethtool request [ Upstream commit 3b5bdd18eb76e7570d9bacbcab6828a9b26ae121 ] Currently iavf adapter statistics are refreshed only in a watchdog task, triggered approximately every two seconds, which causes some ethtool requests to return outdated values. Add explicit statistics refresh when requested by ethtool -S. Fixes: b476b0030e61 ("iavf: Move commands processing to the separate function") Signed-off-by: Jan Sokolowski Signed-off-by: Jedrzej Jagielski Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit e4031c048f4806bee6c869b89582709e62d7739a Author: Nitesh B Venkatesh Date: Fri Jun 4 09:53:31 2021 -0700 iavf: Prevent changing static ITR values if adaptive moderation is on [ Upstream commit e792779e6b639c182df91b46ac1e5803460b0b15 ] Resolve being able to change static values on VF when adaptive interrupt moderation is enabled. This problem is fixed by checking the interrupt settings is not a combination of change of static value while adaptive interrupt moderation is turned on. Without this fix, the user would be able to change static values on VF with adaptive moderation enabled. Fixes: 65e87c0398f5 ("i40evf: support queue-specific settings for interrupt moderation") Signed-off-by: Nitesh B Venkatesh Tested-by: George Kuruvinakunnel Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 25bbaa3ae179a3001228b8dcab88135ae97b7911 Author: Claudia Pellegrino Date: Sun Nov 14 03:53:27 2021 +0100 HID: magicmouse: prevent division by 0 on scroll [ Upstream commit a1091118e0d6d84c2fdb94e6c397ac790bfb9dd6 ] In hid_magicmouse, if the user has set scroll_speed to a value between 55 and 63 and scrolls seven times in quick succession, the step_hr variable in the magicmouse_emit_touch function becomes 0. That causes a division by zero further down in the function when it does `step_x_hr /= step_hr`. To reproduce, create `/etc/modprobe.d/hid_magicmouse.conf` with the following content: ``` options hid_magicmouse scroll_acceleration=1 scroll_speed=55 ``` Then reboot, connect a Magic Mouse and scroll seven times quickly. The system will freeze for a minute, and after that `dmesg` will confirm that a division by zero occurred. Enforce a minimum of 1 for the variable so the high resolution step count can never reach 0 even at maximum scroll acceleration. Fixes: d4b9f10a0eb6 ("HID: magicmouse: enable high-resolution scroll") Signed-off-by: Claudia Pellegrino Tested-by: José Expósito Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 6341c9ccb29ab7ae41657dc59ff6760fbf68e7db Author: Thomas Weißschuh Date: Thu Oct 28 22:55:42 2021 +0200 HID: input: set usage type to key on keycode remap [ Upstream commit 3e6a950d98366f5e716904e9a7e8ffc7ed638bd6 ] When a scancode is manually remapped that previously was not handled as key, then the old usage type was incorrectly reused. This caused issues on a "04b3:301b IBM Corp. SK-8815 Keyboard" which has marked some of its keys with an invalid HID usage. These invalid usage keys are being ignored since support for USB programmable buttons was added. The scancodes are however remapped explicitly by the systemd hwdb to the keycodes that are printed on the physical buttons. During this mapping step the existing usage is retrieved which will be found with a default type of 0 (EV_SYN) instead of EV_KEY. The events with the correct code but EV_SYN type are not forwarded to userspace. This also leads to a kernel oops when trying to print the report descriptor via debugfs. hid_resolv_event() tries to resolve a EV_SYN event with an EV_KEY code which leads to an out-of-bounds access in the EV_SYN names array. Fixes: bcfa8d1457 ("HID: input: Add support for Programmable Buttons") Fixes: f5854fad39 ("Input: hid-input - allow mapping unknown usages") Reported-by: Brent Roman Tested-by: Brent Roman Signed-off-by: Thomas Weißschuh Reviewed-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 740dd84229a5c2430720f57348594bfef91eb606 Author: Hans de Goede Date: Thu Oct 28 18:33:30 2021 +0200 HID: input: Fix parsing of HID_CP_CONSUMER_CONTROL fields [ Upstream commit 7fc48fd6b2c0acacd8130d83d2a037670d6192d2 ] Fix parsing of HID_CP_CONSUMER_CONTROL fields which are not in the HID_CP_PROGRAMMABLEBUTTONS collection. Fixes: bcfa8d14570d ("HID: input: Add support for Programmable Buttons") BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2018096 Cc: Thomas Weißschuh Suggested-by: Benjamin Tissoires Signed-off-by: Hans de Goede Reviewed-By: Thomas Weißschuh Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 03e5203d2161a00afe4d97d206d2293e40b2f253 Author: Volodymyr Mytnyk Date: Thu Nov 18 21:51:40 2021 +0200 net: marvell: prestera: fix double free issue on err path [ Upstream commit e8d032507cb7912baf1d3e0af54516f823befefd ] fix error path handling in prestera_bridge_port_join() that cases prestera driver to crash (see below). Trace: Internal error: Oops: 96000044 [#1] SMP Modules linked in: prestera_pci prestera uio_pdrv_genirq CPU: 1 PID: 881 Comm: ip Not tainted 5.15.0 #1 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : prestera_bridge_destroy+0x2c/0xb0 [prestera] lr : prestera_bridge_port_join+0x2cc/0x350 [prestera] sp : ffff800011a1b0f0 ... x2 : ffff000109ca6c80 x1 : dead000000000100 x0 : dead000000000122 Call trace: prestera_bridge_destroy+0x2c/0xb0 [prestera] prestera_bridge_port_join+0x2cc/0x350 [prestera] prestera_netdev_port_event.constprop.0+0x3c4/0x450 [prestera] prestera_netdev_event_handler+0xf4/0x110 [prestera] raw_notifier_call_chain+0x54/0x80 call_netdevice_notifiers_info+0x54/0xa0 __netdev_upper_dev_link+0x19c/0x380 Fixes: e1189d9a5fbe ("net: marvell: prestera: Add Switchdev driver implementation") Signed-off-by: Volodymyr Mytnyk Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8599e15e508e5740b67eda3f0430a1756adf295f Author: Volodymyr Mytnyk Date: Thu Nov 18 21:48:03 2021 +0200 net: marvell: prestera: fix brige port operation [ Upstream commit 253e9b4d11e577bb8cbc77ef68a9ff46438065ca ] Return NOTIFY_DONE (dont't care) for switchdev notifications that prestera driver don't know how to handle them. With introduction of SWITCHDEV_BRPORT_[UN]OFFLOADED switchdev events, the driver rejects adding swport to bridge operation which is handled by prestera_bridge_port_join() func. The root cause of this is that prestera driver returns error (EOPNOTSUPP) in prestera_switchdev_blk_event() handler for unknown swdev events. This causes switchdev_bridge_port_offload() to fail when adding port to bridge in prestera_bridge_port_join(). Fixes: 957e2235e526 ("net: make switchdev_bridge_port_{,unoffload} loosely coupled with the bridge") Signed-off-by: Volodymyr Mytnyk Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 94850e2dda990fc07dfac15a65c167ac620b734a Author: Joel Stanley Date: Wed Nov 17 09:01:45 2021 +0800 drm/aspeed: Fix vga_pw sysfs output [ Upstream commit b4a6aaeaf4aa79f23775f6688a7e8db3ee1c1303 ] Before the drm driver had support for this file there was a driver that exposed the contents of the vga password register to userspace. It would present the entire register instead of interpreting it. The drm implementation chose to mask of the lower bit, without explaining why. This breaks the existing userspace, which is looking for 0xa8 in the lower byte. Change our implementation to expose the entire register. Fixes: 696029eb36c0 ("drm/aspeed: Add sysfs for output settings") Reported-by: Oskar Senft Signed-off-by: Joel Stanley Reviewed-by: Jeremy Kerr Tested-by: Oskar Senft Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20211117010145.297253-1-joel@jms.id.au Signed-off-by: Sasha Levin commit 555721765bd6174a735f4539474fab3d68886373 Author: Dan Carpenter Date: Thu Nov 18 14:14:16 2021 +0300 drm/vc4: fix error code in vc4_create_object() [ Upstream commit 96c5f82ef0a145d3e56e5b26f2bf6dcd2ffeae1c ] The ->gem_create_object() functions are supposed to return NULL if there is an error. None of the callers expect error pointers so returing one will lead to an Oops. See drm_gem_vram_create(), for example. Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.") Signed-off-by: Dan Carpenter Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20211118111416.GC1147@kili Signed-off-by: Sasha Levin commit b28df766a3fc377187e97dc0166dd5bbbe29876c Author: Sreekanth Reddy Date: Wed Nov 17 18:02:15 2021 +0530 scsi: mpt3sas: Fix incorrect system timestamp [ Upstream commit 5ecae9f8c705fae85fe4d2ed9f1b9cddf91e88e9 ] For updating the IOC firmware's timestamp with system timestamp, the driver issues the Mpi26IoUnitControlRequest message. While framing the Mpi26IoUnitControlRequest, the driver should copy the lower 32 bits of the current timestamp into IOCParameterValue field and the higher 32 bits into Reserved7 field. Link: https://lore.kernel.org/r/20211117123215.25487-1-sreekanth.reddy@broadcom.com Fixes: f98790c00375 ("scsi: mpt3sas: Sync time periodically between driver and firmware") Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8f13c5eddf507e83a97080dd267e24a036c1906a Author: Sreekanth Reddy Date: Wed Nov 17 16:20:58 2021 +0530 scsi: mpt3sas: Fix system going into read-only mode [ Upstream commit 91202a01a2fb2b78da3d03811b6d3d973ae426aa ] While determining the SAS address of a drive, the driver checks whether the handle number is less than the HBA phy count or not. If the handle number is less than the HBA phy count then driver assumes that this handle belongs to HBA and hence it assigns the HBA SAS address. During IOC firmware downgrade operation, if the number of HBA phys is reduced and the OS drive's device handle drops below the phy count while determining the drive's SAS address, the driver ends up using the HBA's SAS address. This leads to a mismatch of drive's SAS address and hence the driver unregisters the OS drive and the system goes into read-only mode. Update the IOC's num_phys to the HBA phy count provided by actual loaded firmware. Link: https://lore.kernel.org/r/20211117105058.3505-1-sreekanth.reddy@broadcom.com Fixes: a5e99fda0172 ("scsi: mpt3sas: Update hba_port objects after host reset") Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8485649a7655e791a6e4e9f15b4d30fdae937184 Author: Sreekanth Reddy Date: Wed Nov 17 16:19:09 2021 +0530 scsi: mpt3sas: Fix kernel panic during drive powercycle test [ Upstream commit 0ee4ba13e09c9d9c1cb6abb59da8295d9952328b ] While looping over shost's sdev list it is possible that one of the drives is getting removed and its sas_target object is freed but its sdev object remains intact. Consequently, a kernel panic can occur while the driver is trying to access the sas_address field of sas_target object without also checking the sas_target object for NULL. Link: https://lore.kernel.org/r/20211117104909.2069-1-sreekanth.reddy@broadcom.com Fixes: f92363d12359 ("[SCSI] mpt3sas: add new driver supporting 12GB SAS") Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 032cf0ad6873a07309736806269b3bfd53040cae Author: Dan Carpenter Date: Tue Nov 9 14:52:19 2021 +0300 scsi: qla2xxx: edif: Fix off by one bug in qla_edif_app_getfcinfo() [ Upstream commit e11e285b9cd132db21568b5d29c291f590841944 ] The > comparison needs to be >= to prevent accessing one element beyond the end of the app_reply->ports[] array. Link: https://lore.kernel.org/r/20211109115219.GE16587@kili Fixes: 7878f22a2e03 ("scsi: qla2xxx: edif: Add getfcinfo and statistic bsgs") Reviewed-by: Ewan D. Milne Reviewed-by: Himanshu Madhani Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8f98d6449b098ac6a7e9626c625a6c5c3e13a790 Author: Dan Carpenter Date: Thu Nov 18 14:13:14 2021 +0300 drm/nouveau/acr: fix a couple NULL vs IS_ERR() checks [ Upstream commit b371fd131fcec59f6165c80778bdc2cd1abd616b ] The nvkm_acr_lsfw_add() function never returns NULL. It returns error pointers on error. Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure boot"") Signed-off-by: Dan Carpenter Reviewed-by: Ben Skeggs Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20211118111314.GB1147@kili Signed-off-by: Sasha Levin commit 20a09c8b25a21506cf8b60bdef78f31a6549ebfc Author: Takashi Iwai Date: Thu Nov 18 15:25:08 2021 +0100 ARM: socfpga: Fix crash with CONFIG_FORTIRY_SOURCE [ Upstream commit 187bea472600dcc8d2eb714335053264dd437172 ] When CONFIG_FORTIFY_SOURCE is set, memcpy() checks the potential buffer overflow and panics. The code in sofcpga bootstrapping contains the memcpy() calls are mistakenly translated as the shorter size, hence it triggers a panic as if it were overflowing. This patch changes the secondary_trampoline and *_end definitions to arrays for avoiding the false-positive crash above. Fixes: 9c4566a117a6 ("ARM: socfpga: Enable SMP for socfpga") Suggested-by: Kees Cook Buglink: https://bugzilla.suse.com/show_bug.cgi?id=1192473 Link: https://lore.kernel.org/r/20211117193244.31162-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Dinh Nguyen Signed-off-by: Sasha Levin commit c76a5e594920930fce5016578a34ddb15bdfefe4 Author: Trond Myklebust Date: Tue Nov 16 09:55:01 2021 -0500 NFSv42: Don't fail clone() unless the OP_CLONE operation failed [ Upstream commit d3c45824ad65aebf765fcf51366d317a29538820 ] The failure to retrieve post-op attributes has no bearing on whether or not the clone operation itself was successful. We must therefore ignore the return value of decode_getfattr() when looking at the success or failure of nfs4_xdr_dec_clone(). Fixes: 36022770de6c ("nfs42: add CLONE xdr functions") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 63073a015730061084fa1c414f47ed8f03f07237 Author: Olivier Moysan Date: Wed Nov 17 11:44:04 2021 +0100 ASoC: stm32: i2s: fix 32 bits channel length without mclk [ Upstream commit 424fe7edbed18d47f7b97f7e1322a6f8969b77ae ] Fix divider calculation in the case of 32 bits channel configuration, when no master clock is used. Fixes: e4e6ec7b127c ("ASoC: stm32: Add I2S driver") Signed-off-by: Olivier Moysan Link: https://lore.kernel.org/r/20211117104404.3832-1-olivier.moysan@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 008fb838e226ab9aa5f29227d57f092ceab06fb8 Author: Peng Fan Date: Tue Nov 16 14:42:27 2021 +0800 firmware: arm_scmi: pm: Propagate return value to caller [ Upstream commit 1446fc6c678e8d8b31606a4b877abe205f344b38 ] of_genpd_add_provider_onecell may return error, so let's propagate its return value to caller Link: https://lore.kernel.org/r/20211116064227.20571-1-peng.fan@oss.nxp.com Fixes: 898216c97ed2 ("firmware: arm_scmi: add device power domain support using genpd") Signed-off-by: Peng Fan Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 7382bcaf30cb274f49c220b88a5bc6814cc48229 Author: Vincent Guittot Date: Wed Nov 17 09:18:56 2021 +0100 firmware: arm_scmi: Fix base agent discover response [ Upstream commit d1cbd9e0f7e51ae8e3638a36ba884fdbb2fc967e ] According to scmi specification, the response of the discover agent request is made of: - int32 status - uint32 agent_id - uint8 name[16] but the current implementation doesn't take into account the agent_id field and only allocates a rx buffer of SCMI_MAX_STR_SIZE length Allocate the correct length for rx buffer and copy the name from the correct offset in the response. While no error were returned until v5.15, v5.16-rc1 fails with virtio_scmi transport channel: | arm-scmi firmware:scmi0: SCMI Notifications - Core Enabled. | arm-scmi firmware:scmi0: SCMI Protocol v2.0 'Linaro:PMWG' Firmware version 0x2090000 | scmi-virtio virtio0: tx:used len 28 is larger than in buflen 24 Link: https://lore.kernel.org/r/20211117081856.9932-1-vincent.guittot@linaro.org Fixes: b6f20ff8bd94 ("firmware: arm_scmi: add common infrastructure and support for base protocol") Tested-by: Cristian Marussi Reviewed-by: Cristian Marussi Signed-off-by: Vincent Guittot Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 6335d90df8afac55b60b90078063fd299916e692 Author: Alexander Aring Date: Thu Nov 11 22:09:16 2021 -0500 net: ieee802154: handle iftypes as u32 [ Upstream commit 451dc48c806a7ce9fbec5e7a24ccf4b2c936e834 ] This patch fixes an issue that an u32 netlink value is handled as a signed enum value which doesn't fit into the range of u32 netlink type. If it's handled as -1 value some BIT() evaluation ends in a shift-out-of-bounds issue. To solve the issue we set the to u32 max which is s32 "-1" value to keep backwards compatibility and let the followed enum values start counting at 0. This brings the compiler to never handle the enum as signed and a check if the value is above NL802154_IFTYPE_MAX should filter -1 out. Fixes: f3ea5e44231a ("ieee802154: add new interface command") Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20211112030916.685793-1-aahringo@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit 4739705254a7ca837ecc0ef1fe3dda7083fce579 Author: Srinivas Kandagatla Date: Tue Nov 16 11:46:23 2021 +0000 ASoC: codecs: lpass-rx-macro: fix HPHR setting CLSH mask [ Upstream commit cb04d8cd0bb0b82acc34cc73cb33ae77cbfb020d ] For some reason we ended up using snd_soc_component_write_field for HPHL and snd_soc_component_update_bits for HPHR, so fix this. Fixes: af3d54b99764 ("ASoC: codecs: lpass-rx-macro: add support for lpass rx macro") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20211116114623.11891-4-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b1b33a14298a8baa090389d66e6453ba19268092 Author: Srinivas Kandagatla Date: Tue Nov 16 11:46:22 2021 +0000 ASoC: codecs: wcd934x: return error code correctly from hw_params [ Upstream commit 006ea27c4e7037369085755c7b5389effa508c04 ] Error returned from wcd934x_slim_set_hw_params() are not passed to upper layer, this could be misleading to the user which can start sending stream leading to unnecessary errors. Fix this by properly returning the errors. Fixes: a61f3b4f476e ("ASoC: wcd934x: add support to wcd9340/wcd9341 codec") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20211116114623.11891-3-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit de178246c30378652796248f66ed2dc4eecb1c7a Author: Srinivas Kandagatla Date: Tue Nov 16 11:46:21 2021 +0000 ASoC: codecs: wcd938x: fix volatile register range [ Upstream commit ea157c2ba821dab789a544cd9fbe44dc07036ff8 ] Interrupt Clear registers WCD938X_INTR_CLEAR_0 - WCD938X_INTR_CLEAR_2 are not marked as volatile. This has resulted in a missing interrupt bug while performing runtime pm. regcache_sync() during runtime pm resume path will write to Interrupt clear registers with previous values which basically clears the pending interrupt and actual interrupt handler never sees this interrupt. This issue is more visible with headset plug-in plug-out case compared to headset button. Fix this by adding the Interrupt clear registers to volatile range Fixes: 8d78602aa87a ("ASoC: codecs: wcd938x: add basic driver") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20211116114623.11891-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 49475a2b29b3085aab54beae3baa10d902e74723 Author: Takashi Iwai Date: Tue Nov 16 08:18:12 2021 +0100 ASoC: topology: Add missing rwsem around snd_ctl_remove() calls [ Upstream commit 7e567b5ae06315ef2d70666b149962e2bb4b97af ] snd_ctl_remove() has to be called with card->controls_rwsem held (when called after the card instantiation). This patch add the missing rwsem calls around it. Fixes: 8a9782346dcc ("ASoC: topology: Add topology core") Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20211116071812.18109-1-tiwai@suse.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f4c465bf918aa6a3ee0620e9c201aca602700a0f Author: Srinivas Kandagatla Date: Tue Nov 16 11:47:19 2021 +0000 ASoC: qdsp6: q6asm: fix q6asm_dai_prepare error handling [ Upstream commit 721a94b4352dc8e47bff90b549a0118c39776756 ] Error handling in q6asm_dai_prepare() seems to be completely broken, Fix this by handling it properly. Fixes: 2a9e92d371db ("ASoC: qdsp6: q6asm: Add q6asm dai driver") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20211116114721.12517-4-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f61e5332fe241c26141d06a482bd7b0b71f15b18 Author: Srinivas Kandagatla Date: Tue Nov 16 11:47:18 2021 +0000 ASoC: qdsp6: q6routing: Conditionally reset FrontEnd Mixer [ Upstream commit 861afeac7990587588d057b2c0b3222331c3da29 ] Stream IDs are reused across multiple BackEnd mixers, do not reset the stream mixers if they are not already set for that particular FrontEnd. Ex: amixer cset iface=MIXER,name='SLIMBUS_0_RX Audio Mixer MultiMedia1' 1 would set the MultiMedia1 steam for SLIMBUS_0_RX, however doing below command will reset previously setup MultiMedia1 stream, because both of them are using MultiMedia1 PCM stream. amixer cset iface=MIXER,name='SLIMBUS_2_RX Audio Mixer MultiMedia1' 0 reset the FrontEnd Mixers conditionally to fix this issue. This is more noticeable in desktop setup, where in alsactl tries to restore the alsa state and overwriting the previous mixer settings. Fixes: e3a33673e845 ("ASoC: qdsp6: q6routing: Add q6routing driver") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20211116114721.12517-3-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 322eebada5e39870a56681f0efacbba9395b267b Author: Florian Fainelli Date: Fri Oct 29 14:09:26 2021 -0700 ARM: dts: bcm2711: Fix PCIe interrupts [ Upstream commit 98481f3d72fb88cb5b973153434061015f094925 ] The PCIe host bridge has two interrupt lines, one that goes towards it PCIE_INTR2 second level interrupt controller and one for its MSI second level interrupt controller. The first interrupt line is not currently managed by the driver, which is why it was not a functional problem. The interrupt-map property was also only listing the PCI_INTA interrupts when there are also the INTB, C and D. Reported-by: Jim Quinlan Fixes: d5c8dc0d4c88 ("ARM: dts: bcm2711: Enable PCIe controller") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 6012bea743440b29114c351ebec9b91e81181fdc Author: Florian Fainelli Date: Thu Oct 28 09:46:53 2021 -0700 ARM: dts: BCM5301X: Add interrupt properties to GPIO node [ Upstream commit 40f7342f0587639e5ad625adaa15efdd3cffb18f ] The GPIO controller is also an interrupt controller provider and is currently missing the appropriate 'interrupt-controller' and '#interrupt-cells' properties to denote that. Fixes: fb026d3de33b ("ARM: BCM5301X: Add Broadcom's bus-axi to the DTS file") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit b14b8cf0d1c6a5914b3547b032f9933973e08e74 Author: Florian Fainelli Date: Wed Oct 27 12:37:29 2021 -0700 ARM: dts: BCM5301X: Fix I2C controller interrupt [ Upstream commit 754c4050a00e802e122690112fc2c3a6abafa7e2 ] The I2C interrupt controller line is off by 32 because the datasheet describes interrupt inputs into the GIC which are for Shared Peripheral Interrupts and are starting at offset 32. The ARM GIC binding expects the SPI interrupts to be numbered from 0 relative to the SPI base. Fixes: bb097e3e0045 ("ARM: dts: BCM5301X: Add I2C support to the DT") Tested-by: Christian Lamparter Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 03339d10253edea4435bccf7223153f9d9d23a13 Author: Cristian Marussi Date: Fri Nov 12 18:07:05 2021 +0000 firmware: arm_scmi: Fix null de-reference on error path [ Upstream commit 95161165727650a707bc34ecfac286a418b6bb00 ] During channel setup a failure in the call of scmi_vio_feed_vq_rx() leads to an attempt to access a dev pointer by dereferencing vioch->cinfo at a time when vioch->cinfo has still to be initialized. Fix it by providing the device reference directly to scmi_vio_feed_vq_rx. Link: https://lore.kernel.org/r/20211112180705.41601-1-cristian.marussi@arm.com Fixes: 46abe13b5e3db ("firmware: arm_scmi: Add virtio transport") Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 75fa2dadb7c26010eef19185eaff40c960a185fd Author: Arnd Bergmann Date: Tue Oct 26 06:49:54 2021 +0100 media: v4l2-core: fix VIDIOC_DQEVENT handling on non-x86 [ Upstream commit 678d92b6126b9f55419b6a51ef0a88bce2ef2f20 ] My previous bugfix addressed an API inconsistency found by syzbot, and it correctly fixed the issue on x86-64 machines, which now behave correctly for both native and compat tasks. Unfortunately, John found that the patch broke compat mode on all other architectures, as they can no longer rely on the VIDIOC_DQEVENT_TIME32 code from the native handler as a fallback in the compat code. The best way I can see for addressing this is to generalize the VIDIOC_DQEVENT32_TIME32 code from x86 and use that for all architectures, leaving only the VIDIOC_DQEVENT32 variant as x86 specific. The original code was trying to be clever and use the same conversion helper for native 32-bit code and compat mode, but that turned out to be too obscure so even I missed that bit I had introduced myself when I made the fix. Fixes: c344f07aa1b4 ("media: v4l2-core: ignore native time32 ioctls on 64-bit") Reported-by: John Stultz Signed-off-by: Arnd Bergmann Tested-by: John Stultz Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ed741b849ade9b4fd0b27ca20266be0a121b300e Author: Will Mortensen Date: Sat Nov 6 18:28:21 2021 -0700 netfilter: flowtable: fix IPv6 tunnel addr match [ Upstream commit 39f6eed4cb209643f3f8633291854ed7375d7264 ] Previously the IPv6 addresses in the key were clobbered and the mask was left unset. I haven't tested this; I noticed it while skimming the code to understand an unrelated issue. Fixes: cfab6dbd0ecf ("netfilter: flowtable: add tunnel match offload support") Cc: wenxu Signed-off-by: Will Mortensen Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit e76228cbecc2127c6891e74d358c3243a661bac1 Author: yangxingwu Date: Thu Nov 4 03:10:29 2021 +0100 netfilter: ipvs: Fix reuse connection if RS weight is 0 [ Upstream commit c95c07836fa4c1767ed11d8eca0769c652760e32 ] We are changing expire_nodest_conn to work even for reused connections when conn_reuse_mode=0, just as what was done with commit dc7b3eb900aa ("ipvs: Fix reuse connection if real server is dead"). For controlled and persistent connections, the new connection will get the needed real server depending on the rules in ip_vs_check_template(). Fixes: d752c3645717 ("ipvs: allow rescheduling of new connections when port reuse is detected") Co-developed-by: Chuanqi Liu Signed-off-by: Chuanqi Liu Signed-off-by: yangxingwu Acked-by: Simon Horman Acked-by: Julian Anastasov Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 49f8783307587247b8b1b89bf7bdd106059d7232 Author: Florent Fourcot Date: Wed Nov 3 23:21:55 2021 +0100 netfilter: ctnetlink: do not erase error code with EINVAL [ Upstream commit 77522ff02f333434612bd72df9b376f8d3836e4d ] And be consistent in error management for both orig/reply filtering Fixes: cb8aa9a3affb ("netfilter: ctnetlink: add kernel side filtering for dump") Signed-off-by: Florent Fourcot Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 59a0088fde86739acaec38a9d7f3a094afea93d9 Author: Florent Fourcot Date: Wed Nov 3 23:21:54 2021 +0100 netfilter: ctnetlink: fix filtering with CTA_TUPLE_REPLY [ Upstream commit ad81d4daf6a3f4769a346e635d5e1e967ca455d9 ] filter->orig_flags was used for a reply context. Fixes: cb8aa9a3affb ("netfilter: ctnetlink: add kernel side filtering for dump") Signed-off-by: Florent Fourcot Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 37c8d485cb72250e0bba48486a83c9c33993fb21 Author: Kai Vehmanen Date: Fri Nov 5 13:16:55 2021 +0200 ASoC: SOF: Intel: hda: fix hotplug when only codec is suspended [ Upstream commit fd572393baf0350835e8d822db588f679dc7bcb8 ] If codec is in runtime suspend, but controller is not, hotplug events are missed as the codec has no way to alert the controller. Problem does not occur if both controller and codec are active, or when both are suspended. An easy way to reproduce is to play an audio stream on one codec (e.g. to HDMI/DP display codec), wait for other HDA codec to go to runtime suspend, and then plug in a headset to the suspended codec. The jack event is not reported correctly in this case. Another way to reproduce is to force controller to stay active with "snd_sof_pci.sof_pci_debug=0x1" Fix the issue by reconfiguring the WAKEEN register when powering up/down individual links, and handling control events in the interrupt handler. Fixes: 87fc20e4a0cb ("ASoC: SOF: Intel: hda: use hdac_ext fine-grained link management") Reported-by: Hui Wang Signed-off-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Péter Ujfalusi Link: https://lore.kernel.org/r/20211105111655.668777-1-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7b3a34f08d11e7f05cd00b8e09adaa15192f0ad1 Author: David Hildenbrand Date: Fri Nov 19 16:43:58 2021 -0800 proc/vmcore: fix clearing user buffer by properly using clear_user() commit c1e63117711977cc4295b2ce73de29dd17066c82 upstream. To clear a user buffer we cannot simply use memset, we have to use clear_user(). With a virtio-mem device that registers a vmcore_cb and has some logically unplugged memory inside an added Linux memory block, I can easily trigger a BUG by copying the vmcore via "cp": systemd[1]: Starting Kdump Vmcore Save Service... kdump[420]: Kdump is using the default log level(3). kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[465]: saving vmcore-dmesg.txt complete kdump[467]: saving vmcore BUG: unable to handle page fault for address: 00007f2374e01000 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867 Oops: 0003 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86 Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81 RSP: 0018:ffffc9000073be08 EFLAGS: 00010212 RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000 RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008 RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50 R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000 R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8 FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0 Call Trace: read_vmcore+0x236/0x2c0 proc_reg_read+0x55/0xa0 vfs_read+0x95/0x190 ksys_read+0x4f/0xc0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access Prevention (SMAP)", which is used to detect wrong access from the kernel to user buffers like this: SMAP triggers a permissions violation on wrong access. In the x86-64 variant of clear_user(), SMAP is properly handled via clac()+stac(). To fix, properly use clear_user() when we're dealing with a user buffer. Link: https://lkml.kernel.org/r/20211112092750.6921-1-david@redhat.com Fixes: 997c136f518c ("fs/proc/vmcore.c: add hook to read_from_oldmem() to check for non-ram pages") Signed-off-by: David Hildenbrand Acked-by: Baoquan He Cc: Dave Young Cc: Baoquan He Cc: Vivek Goyal Cc: Philipp Rudo Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit de6231fc7f2b8825e328953e2c7729d76f4b62bd Author: Roman Li Date: Wed Nov 17 10:05:36 2021 -0500 drm/amd/display: Fix OLED brightness control on eDP commit dab60582685aabdae2d4ff7ce716456bd0dc7a0f upstream. [Why] After commit ("drm/amdgpu/display: add support for multiple backlights") number of eDPs is defined while registering backlight device. However the panel's extended caps get updated once before register call. That leads to regression with extended caps like oled brightness control. [How] Update connector ext caps after register_backlight_device Fixes: 7fd13baeb7a3a4 ("drm/amdgpu/display: add support for multiple backlights") Link: https://www.reddit.com/r/AMDLaptops/comments/qst0fm/after_updating_to_linux_515_my_brightness/ Signed-off-by: Roman Li Tested-by: Samuel Čavoj Acked-by: Alex Deucher Reviewed-by: Jasdeep Dhillon Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit edd145cd09029aa1ecec22eea079f4c8659bb8ee Author: Pali Rohár Date: Tue Oct 5 20:09:50 2021 +0200 PCI: aardvark: Fix link training commit f76b36d40beee0a13aa8f6aa011df0d7cbbb8a7f upstream. Fix multiple link training issues in aardvark driver. The main reason of these issues was misunderstanding of what certain registers do, since their names and comments were misleading: before commit 96be36dbffac ("PCI: aardvark: Replace custom macros by standard linux/pci_regs.h macros"), the pci-aardvark.c driver used custom macros for accessing standard PCIe Root Bridge registers, and misleading comments did not help to understand what the code was really doing. After doing more tests and experiments I've come to the conclusion that the SPEED_GEN register in aardvark sets the PCIe revision / generation compliance and forces maximal link speed. Both GEN3 and GEN2 values set the read-only PCI_EXP_FLAGS_VERS bits (PCIe capabilities version of Root Bridge) to value 2, while GEN1 value sets PCI_EXP_FLAGS_VERS to 1, which matches with PCI Express specifications revisions 3, 2 and 1 respectively. Changing SPEED_GEN also sets the read-only bits PCI_EXP_LNKCAP_SLS and PCI_EXP_LNKCAP2_SLS to corresponding speed. (Note that PCI Express rev 1 specification does not define PCI_EXP_LNKCAP2 and PCI_EXP_LNKCTL2 registers and when SPEED_GEN is set to GEN1 (which also sets PCI_EXP_FLAGS_VERS set to 1), lspci cannot access PCI_EXP_LNKCAP2 and PCI_EXP_LNKCTL2 registers.) Changing PCIe link speed can be done via PCI_EXP_LNKCTL2_TLS bits of PCI_EXP_LNKCTL2 register. Armada 3700 Functional Specifications says that the default value of PCI_EXP_LNKCTL2_TLS is based on SPEED_GEN value, but tests showed that the default value is always 8.0 GT/s, independently of speed set by SPEED_GEN. So after setting SPEED_GEN, we must also set value in PCI_EXP_LNKCTL2 register via PCI_EXP_LNKCTL2_TLS bits. Triggering PCI_EXP_LNKCTL_RL bit immediately after setting LINK_TRAINING_EN bit actually doesn't do anything. Tests have shown that a delay is needed after enabling LINK_TRAINING_EN bit. As triggering PCI_EXP_LNKCTL_RL currently does nothing, remove it. Commit 43fc679ced18 ("PCI: aardvark: Improve link training") introduced code which sets SPEED_GEN register based on negotiated link speed from PCI_EXP_LNKSTA_CLS bits of PCI_EXP_LNKSTA register. This code was added to fix detection of Compex WLE900VX (Atheros QCA9880) WiFi GEN1 PCIe cards, as otherwise these cards were "invisible" on PCIe bus (probably because they crashed). But apparently more people reported the same issues with these cards also with other PCIe controllers [1] and I was able to reproduce this issue also with other "noname" WiFi cards based on Atheros QCA9890 chip (with the same PCI vendor/device ids as Atheros QCA9880). So this is not an issue in aardvark but rather an issue in Atheros QCA98xx chips. Also, this issue only exists if the kernel is compiled with PCIe ASPM support, and a generic workaround for this is to change PCIe Bridge to 2.5 GT/s link speed via PCI_EXP_LNKCTL2_TLS_2_5GT bits in PCI_EXP_LNKCTL2 register [2], before triggering PCI_EXP_LNKCTL_RL bit. This workaround also works when SPEED_GEN is set to value GEN2 (5 GT/s). So remove this hack completely in the aardvark driver and always set SPEED_GEN to value from 'max-link-speed' DT property. Fix for Atheros QCA98xx chips is handled separately by patch [2]. These two things (code for triggering PCI_EXP_LNKCTL_RL bit and changing SPEED_GEN value) also explain why commit 6964494582f5 ("PCI: aardvark: Train link immediately after enabling training") somehow fixed detection of those problematic Compex cards with Atheros chips: if triggering link retraining (via PCI_EXP_LNKCTL_RL bit) was done immediately after enabling link training (via LINK_TRAINING_EN), it did nothing. If there was a specific delay, aardvark HW already initialized PCIe link and therefore triggering link retraining caused the above issue. Compex cards triggered link down event and disappeared from the PCIe bus. Commit f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready before training link") added 100ms sleep before calling 'Start link training' command and explained that it is a requirement of PCI Express specification. But the code after this 100ms sleep was not doing 'Start link training', rather it triggered PCI_EXP_LNKCTL_RL bit via PCIe Root Bridge to put link into Recovery state. The required delay after fundamental reset is already done in function advk_pcie_wait_for_link() which also checks whether PCIe link is up. So after removing the code which triggers PCI_EXP_LNKCTL_RL bit on PCIe Root Bridge, there is no need to wait 100ms again. Remove the extra msleep() call and update comment about the delay required by the PCI Express specification. According to Marvell Armada 3700 Functional Specifications, Link training should be enabled via aardvark register LINK_TRAINING_EN after selecting PCIe generation and x1 lane. There is no need to disable it prior resetting card via PERST# signal. This disabling code was introduced in commit 5169a9851daa ("PCI: aardvark: Issue PERST via GPIO") as a workaround for some Atheros cards. It turns out that this also is Atheros specific issue and affects any PCIe controller, not only aardvark. Moreover this Atheros issue was triggered by juggling with PCI_EXP_LNKCTL_RL, LINK_TRAINING_EN and SPEED_GEN bits interleaved with sleeps. Now, after removing triggering PCI_EXP_LNKCTL_RL, there is no need to explicitly disable LINK_TRAINING_EN bit. So remove this code too. The problematic Compex cards described in previous git commits are correctly detected in advk_pcie_train_link() function even after applying all these changes. Note that with this patch, and also prior this patch, some NVMe disks which support PCIe GEN3 with 8 GT/s speed are negotiated only at the lowest link speed 2.5 GT/s, independently of SPEED_GEN value. After manually triggering PCI_EXP_LNKCTL_RL bit (e.g. from userspace via setpci), these NVMe disks change link speed to 5 GT/s when SPEED_GEN was configured to GEN2. This issue first needs to be properly investigated. I will send a fix in the future. On the other hand, some other GEN2 PCIe cards with 5 GT/s speed are autonomously by HW autonegotiated at full 5 GT/s speed without need of any software interaction. Armada 3700 Functional Specifications describes the following steps for link training: set SPEED_GEN to GEN2, enable LINK_TRAINING_EN, poll until link training is complete, trigger PCI_EXP_LNKCTL_RL, poll until signal rate is 5 GT/s, poll until link training is complete, enable ASPM L0s. The requirement for triggering PCI_EXP_LNKCTL_RL can be explained by the need to achieve 5 GT/s speed (as changing link speed is done by throw to recovery state entered by PCI_EXP_LNKCTL_RL) or maybe as a part of enabling ASPM L0s (but in this case ASPM L0s should have been enabled prior PCI_EXP_LNKCTL_RL). It is unknown why the original pci-aardvark.c driver was triggering PCI_EXP_LNKCTL_RL bit before waiting for the link to be up. This does not align with neither PCIe base specifications nor with Armada 3700 Functional Specification. (Note that in older versions of aardvark, this bit was called incorrectly PCIE_CORE_LINK_TRAINING, so this may be the reason.) It is also unknown why Armada 3700 Functional Specification says that it is needed to trigger PCI_EXP_LNKCTL_RL for GEN2 mode, as according to PCIe base specification 5 GT/s speed negotiation is supposed to be entirely autonomous, even if initial speed is 2.5 GT/s. [1] - https://lore.kernel.org/linux-pci/87h7l8axqp.fsf@toke.dk/ [2] - https://lore.kernel.org/linux-pci/20210326124326.21163-1-pali@kernel.org/ Link: https://lore.kernel.org/r/20211005180952.6812-12-kabel@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Signed-off-by: Marek Behún Signed-off-by: Greg Kroah-Hartman commit cc890665eaa12a5cc7f772023eb53955a834f127 Author: Pali Rohár Date: Tue Oct 5 20:09:49 2021 +0200 PCI: aardvark: Simplify initialization of rootcap on virtual bridge commit 454c53271fc11f3aa5e44e41fd99ca181bd32c62 upstream. PCIe config space can be initialized also before pci_bridge_emul_init() call, so move rootcap initialization after PCI config space initialization. This simplifies the function a little since it removes one if (ret < 0) check. Link: https://lore.kernel.org/r/20211005180952.6812-11-kabel@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Signed-off-by: Marek Behún Signed-off-by: Greg Kroah-Hartman commit 70b131ff35bd90e043d4b07d089059f1d8eb315e Author: Pali Rohár Date: Tue Oct 5 20:09:48 2021 +0200 PCI: aardvark: Implement re-issuing config requests on CRS response commit 223dec14a05337a4155f1deed46d2becce4d00fd upstream. Commit 43f5c77bcbd2 ("PCI: aardvark: Fix reporting CRS value") fixed handling of CRS response and when CRSSVE flag was not enabled it marked CRS response as failed transaction (due to simplicity). But pci-aardvark.c driver is already waiting up to the PIO_RETRY_CNT count for PIO config response and so we can with a small change implement re-issuing of config requests as described in PCIe base specification. This change implements re-issuing of config requests when response is CRS. Set upper bound of wait cycles to around PIO_RETRY_CNT, afterwards the transaction is marked as failed and an all-ones value is returned as before. We do this by returning appropriate error codes from function advk_pcie_check_pio_status(). On CRS we return -EAGAIN and caller then reissues transaction. Link: https://lore.kernel.org/r/20211005180952.6812-10-kabel@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Signed-off-by: Greg Kroah-Hartman commit c37f8369fa0387d5edd708467b3a99aa06127fa6 Author: Marek Behún Date: Tue Oct 5 20:09:47 2021 +0200 PCI: aardvark: Deduplicate code in advk_pcie_rd_conf() commit 67cb2a4c93499c2c22704998fd1fd2bc35194d8e upstream. Avoid code repetition in advk_pcie_rd_conf() by handling errors with goto jump, as is customary in kernel. Link: https://lore.kernel.org/r/20211005180952.6812-9-kabel@kernel.org Fixes: 43f5c77bcbd2 ("PCI: aardvark: Fix reporting CRS value") Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Signed-off-by: Greg Kroah-Hartman commit a0a7875c0305fe103381ad919a85aaf2cc553a7d Author: Benjamin Coddington Date: Tue Nov 16 10:48:13 2021 -0500 NFSv42: Fix pagecache invalidation after COPY/CLONE commit 3f015d89a47cd8855cd92f71fff770095bd885a1 upstream. The mechanism in use to allow the client to see the results of COPY/CLONE is to drop those pages from the pagecache. This forces the client to read those pages once more from the server. However, truncate_pagecache_range() zeros out partial pages instead of dropping them. Let us instead use invalidate_inode_pages2_range() with full-page offsets to ensure the client properly sees the results of COPY/CLONE operations. Cc: # v4.7+ Fixes: 2e72448b07dc ("NFS: Add COPY nfs operation") Signed-off-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 55d2254fd9a0d528dd1de0ff1b9a1499efc9990b Author: Andreas Gruenbacher Date: Wed Nov 17 17:59:01 2021 -0800 iomap: Fix inline extent handling in iomap_readpage commit d8af404ffce71448f29bbc19a05e3d095baf98eb upstream. Before commit 740499c78408 ("iomap: fix the iomap_readpage_actor return value for inline data"), when hitting an IOMAP_INLINE extent, iomap_readpage_actor would report having read the entire page. Since then, it only reports having read the inline data (iomap->length). This will force iomap_readpage into another iteration, and the filesystem will report an unaligned hole after the IOMAP_INLINE extent. But iomap_readpage_actor (now iomap_readpage_iter) isn't prepared to deal with unaligned extents, it will get things wrong on filesystems with a block size smaller than the page size, and we'll eventually run into the following warning in iomap_iter_advance: WARN_ON_ONCE(iter->processed > iomap_length(iter)); Fix that by changing iomap_readpage_iter to return 0 when hitting an inline extent; this will cause iomap_iter to stop immediately. To fix readahead as well, change iomap_readahead_iter to pass on iomap_readpage_iter return values less than or equal to zero. Fixes: 740499c78408 ("iomap: fix the iomap_readpage_actor return value for inline data") Cc: stable@vger.kernel.org # v5.15+ Signed-off-by: Andreas Gruenbacher Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit c4e3ff8b8b1d54f0c755670174c453b06e17114b Author: Christophe Leroy Date: Thu Nov 18 10:39:53 2021 +0100 powerpc/32: Fix hardlockup on vmap stack overflow commit 5bb60ea611db1e04814426ed4bd1c95d1487678e upstream. Since the commit c118c7303ad5 ("powerpc/32: Fix vmap stack - Do not activate MMU before reading task struct") a vmap stack overflow results in a hard lockup. This is because emergency_ctx is still addressed with its virtual address allthough data MMU is not active anymore at that time. Fix it by using a physical address instead. Fixes: c118c7303ad5 ("powerpc/32: Fix vmap stack - Do not activate MMU before reading task struct") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/ce30364fb7ccda489272af4a1612b6aa147e1d23.1637227521.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit 671fbc2e8dea63846935fd1267e4f4c61440ac5d Author: Rafael J. Wysocki Date: Wed Nov 17 14:57:31 2021 +0100 cpufreq: intel_pstate: Fix active mode offline/online EPP handling commit ed38eb49d101e829ae0f8c0a0d3bf5cb6bcbc6b2 upstream. After commit 4adcf2e5829f ("cpufreq: intel_pstate: Add ->offline and ->online callbacks") the EPP value set by the "performance" scaling algorithm in the active mode is not restored after an offline/online cycle which replaces it with the saved EPP value coming from user space. Address this issue by forcing intel_pstate_hwp_set() to set a new EPP value when it runs first time after online. Fixes: 4adcf2e5829f ("cpufreq: intel_pstate: Add ->offline and ->online callbacks") Link: https://lore.kernel.org/linux-pm/adc7132c8655bd4d1c8b6129578e931a14fe1db2.camel@linux.intel.com/ Reported-by: Srinivas Pandruvada Cc: 5.9+ # 5.9+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 7dd74096dd28c9c4d7b7d8e4aa16cb2109399de5 Author: Pingfan Liu Date: Fri Nov 12 13:22:14 2021 +0800 arm64: mm: Fix VM_BUG_ON(mm != &init_mm) for trans_pgd commit d3eb70ead6474ec16f976fcacf10a7a890a95bd3 upstream. trans_pgd_create_copy() can hit "VM_BUG_ON(mm != &init_mm)" in the function pmd_populate_kernel(). This is the combined consequence of commit 5de59884ac0e ("arm64: trans_pgd: pass NULL instead of init_mm to *_populate functions"), which replaced &init_mm with NULL and commit 59511cfd08f3 ("arm64: mm: use XN table mapping attributes for user/kernel mappings"), which introduced the VM_BUG_ON. Since the former sounds reasonable, it is better to work on the later. From the perspective of trans_pgd, two groups of functions are considered in the later one: pmd_populate_kernel() mm == NULL should be fixed, else it hits VM_BUG_ON() p?d_populate() mm == NULL means PXN, that is OK, since trans_pgd only copies a linear map, no execution will happen on the map. So it is good enough to just relax VM_BUG_ON() to disregard mm == NULL Fixes: 59511cfd08f3 ("arm64: mm: use XN table mapping attributes for user/kernel mappings") Signed-off-by: Pingfan Liu Cc: # 5.13.x Cc: Ard Biesheuvel Cc: James Morse Cc: Matthias Brugger Reviewed-by: Catalin Marinas Reviewed-by: Pasha Tatashin Link: https://lore.kernel.org/r/20211112052214.9086-1-kernelfans@gmail.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 9ed3dc3968adb9fcaaa17d30fa4a037d071405d4 Author: Dylan Hung Date: Thu Nov 25 10:44:32 2021 +0800 mdio: aspeed: Fix "Link is Down" issue commit 9dbe33cf371bd70330858370bdbc35c7668f00c3 upstream. The issue happened randomly in runtime. The message "Link is Down" is popped but soon it recovered to "Link is Up". The "Link is Down" results from the incorrect read data for reading the PHY register via MDIO bus. The correct sequence for reading the data shall be: 1. fire the command 2. wait for command done (this step was missing) 3. wait for data idle 4. read data from data register Cc: stable@vger.kernel.org Fixes: f160e99462c6 ("net: phy: Add mdio-aspeed") Reviewed-by: Joel Stanley Signed-off-by: Dylan Hung Reviewed-by: Andrew Lunn Reviewed-by: Russell King (Oracle) Link: https://lore.kernel.org/r/20211125024432.15809-1-dylan_hung@aspeedtech.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4332ead299903138a32a39957239def81a774f9c Author: Adrian Hunter Date: Mon Nov 15 10:23:45 2021 +0200 mmc: sdhci: Fix ADMA for PAGE_SIZE >= 64KiB commit 3d7c194b7c9ad414264935ad4f943a6ce285ebb1 upstream. The block layer forces a minimum segment size of PAGE_SIZE, so a segment can be too big for the ADMA table, if PAGE_SIZE >= 64KiB. Fix by writing multiple descriptors, noting that the ADMA table is sized for 4KiB chunks anyway, so it will be big enough. Reported-and-tested-by: Bough Chen Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211115082345.802238-1-adrian.hunter@intel.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 4721b9ee049ac67785f2221f3bd56735187452dd Author: Tim Harvey Date: Wed Nov 3 09:54:15 2021 -0700 mmc: sdhci-esdhc-imx: disable CMDQ support commit adab993c25191b839b415781bdc7173a77315240 upstream. On IMX SoC's which support CMDQ the following can occur during high a high cpu load: mmc2: cqhci: ============ CQHCI REGISTER DUMP =========== mmc2: cqhci: Caps: 0x0000310a | Version: 0x00000510 mmc2: cqhci: Config: 0x00001001 | Control: 0x00000000 mmc2: cqhci: Int stat: 0x00000000 | Int enab: 0x00000006 mmc2: cqhci: Int sig: 0x00000006 | Int Coal: 0x00000000 mmc2: cqhci: TDL base: 0x8003f000 | TDL up32: 0x00000000 mmc2: cqhci: Doorbell: 0xbf01dfff | TCN: 0x00000000 mmc2: cqhci: Dev queue: 0x00000000 | Dev Pend: 0x08000000 mmc2: cqhci: Task clr: 0x00000000 | SSC1: 0x00011000 mmc2: cqhci: SSC2: 0x00000001 | DCMD rsp: 0x00000800 mmc2: cqhci: RED mask: 0xfdf9a080 | TERRI: 0x00000000 mmc2: cqhci: Resp idx: 0x0000000d | Resp arg: 0x00000000 mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== mmc2: sdhci: Sys addr: 0x7c722000 | Version: 0x00000002 mmc2: sdhci: Blk size: 0x00000200 | Blk cnt: 0x00000020 mmc2: sdhci: Argument: 0x00018000 | Trn mode: 0x00000023 mmc2: sdhci: Present: 0x01f88008 | Host ctl: 0x00000030 mmc2: sdhci: Power: 0x00000002 | Blk gap: 0x00000080 mmc2: sdhci: Wake-up: 0x00000008 | Clock: 0x0000000f mmc2: sdhci: Timeout: 0x0000008f | Int stat: 0x00000000 mmc2: sdhci: Int enab: 0x107f4000 | Sig enab: 0x107f4000 mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000502 mmc2: sdhci: Caps: 0x07eb0000 | Caps_1: 0x8000b407 mmc2: sdhci: Cmd: 0x00000d1a | Max curr: 0x00ffffff mmc2: sdhci: Resp[0]: 0x00000000 | Resp[1]: 0xffc003ff mmc2: sdhci: Resp[2]: 0x328f5903 | Resp[3]: 0x00d07f01 mmc2: sdhci: Host ctl2: 0x00000088 mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0xfe179020 mmc2: sdhci-esdhc-imx: ========= ESDHC IMX DEBUG STATUS DUMP ==== mmc2: sdhci-esdhc-imx: cmd debug status: 0x2120 mmc2: sdhci-esdhc-imx: data debug status: 0x2200 mmc2: sdhci-esdhc-imx: trans debug status: 0x2300 mmc2: sdhci-esdhc-imx: dma debug status: 0x2400 mmc2: sdhci-esdhc-imx: adma debug status: 0x2510 mmc2: sdhci-esdhc-imx: fifo debug status: 0x2680 mmc2: sdhci-esdhc-imx: async fifo debug status: 0x2750 mmc2: sdhci: ============================================ For now, disable CMDQ support on the imx8qm/imx8qxp/imx8mm until the issue is found and resolved. Fixes: bb6e358169bf6 ("mmc: sdhci-esdhc-imx: add CMDQ support") Fixes: cde5e8e9ff146 ("mmc: sdhci-esdhc-imx: Add an new esdhc_soc_data for i.MX8MM") Cc: stable@vger.kernel.org Signed-off-by: Tim Harvey Reviewed-by: Haibo Chen Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20211103165415.2016-1-tharvey@gateworks.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 55bc4437762a6bcc8089e0639d2662e26e3629f6 Author: Steven Rostedt (VMware) Date: Fri Nov 26 17:34:42 2021 -0500 tracing: Fix pid filtering when triggers are attached commit a55f224ff5f238013de8762c4287117e47b86e22 upstream. If a event is filtered by pid and a trigger that requires processing of the event to happen is a attached to the event, the discard portion does not take the pid filtering into account, and the event will then be recorded when it should not have been. Cc: stable@vger.kernel.org Fixes: 3fdaf80f4a836 ("tracing: Implement event pid filtering") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit a3e90db5180fd7f5d38940e2022aee19c3332f3e Author: Jiri Olsa Date: Tue Nov 23 15:28:01 2021 +0100 tracing/uprobe: Fix uprobe_perf_open probes iteration commit 1880ed71ce863318c1ce93bf324876fb5f92854f upstream. Add missing 'tu' variable initialization in the probes loop, otherwise the head 'tu' is used instead of added probes. Link: https://lkml.kernel.org/r/20211123142801.182530-1-jolsa@kernel.org Cc: stable@vger.kernel.org Fixes: 99c9a923e97a ("tracing/uprobe: Fix double perf_event linking on multiprobe uprobe") Acked-by: Masami Hiramatsu Signed-off-by: Jiri Olsa Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 83247fdb9417e7ce9eaf838e43840df8e6ee9a1c Author: Nicholas Piggin Date: Fri Nov 19 13:16:27 2021 +1000 KVM: PPC: Book3S HV: Prevent POWER7/8 TLB flush flushing SLB commit cf0b0e3712f7af90006f8317ff27278094c2c128 upstream. The POWER9 ERAT flush instruction is a SLBIA with IH=7, which is a reserved value on POWER7/8. On POWER8 this invalidates the SLB entries above index 0, similarly to SLBIA IH=0. If the SLB entries are invalidated, and then the guest is bypassed, the host SLB does not get re-loaded, so the bolted entries above 0 will be lost. This can result in kernel stack access causing a SLB fault. Kernel stack access causing a SLB fault was responsible for the infamous mega bug (search "Fix SLB reload bug"). Although since commit 48e7b7695745 ("powerpc/64s/hash: Convert SLB miss handlers to C") that starts using the kernel stack in the SLB miss handler, it might only result in an infinite loop of SLB faults. In any case it's a bug. Fix this by only executing the instruction on >= POWER9 where IH=7 is defined not to invalidate the SLB. POWER7/8 don't require this ERAT flush. Fixes: 500871125920 ("KVM: PPC: Book3S HV: Invalidate ERAT when flushing guest TLB entries") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Nicholas Piggin Reviewed-by: Fabiano Rosas Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211119031627.577853-1-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit 11e659827c3a2facb3a04e08cc97ff14d5091f51 Author: Namjae Jeon Date: Wed Nov 24 10:23:02 2021 +0900 ksmbd: fix memleak in get_file_stream_info() commit 178ca6f85aa3231094467691f5ea1ff2f398aa8d upstream. Fix memleak in get_file_stream_info() Fixes: 34061d6b76a4 ("ksmbd: validate OutputBufferLength of QUERY_DIR, QUERY_INFO, IOCTL requests") Cc: stable@vger.kernel.org # v5.15 Reported-by: Coverity Scan Acked-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 522cd5c6554a0bb56dae7baa2c6155970de4be1d Author: Namjae Jeon Date: Sun Nov 21 11:32:39 2021 +0900 ksmbd: contain default data stream even if xattr is empty commit 1ec72153ff434ce75bace3044dc89a23a05d7064 upstream. If xattr is not supported like exfat or fat, ksmbd server doesn't contain default data stream in FILE_STREAM_INFORMATION response. It will cause ppt or doc file update issue if local filesystem is such as ones. This patch move goto statement to contain it. Fixes: 9f6323311c70 ("ksmbd: add default data stream name in FILE_STREAM_INFORMATION") Cc: stable@vger.kernel.org # v5.15 Acked-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit b05576526e84e50718f24409086d0d51f3d3371c Author: Namjae Jeon Date: Sun Nov 21 07:48:45 2021 +0900 ksmbd: downgrade addition info error msg to debug in smb2_get_info_sec() commit 8e537d1465e7401f352a6e0a728a93f8cad5294a upstream. While file transfer through windows client, This error flood message happen. This flood message will cause performance degradation and misunderstand server has problem. Fixes: e294f78d3478 ("ksmbd: allow PROTECTED_DACL_SECINFO and UNPROTECTED_DACL_SECINFO addition information in smb2 set info security") Cc: stable@vger.kernel.org # v5.15 Acked-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a70414d820f74107882be7b8bd257606ffac7233 Author: Ben Skeggs Date: Thu Nov 18 13:04:13 2021 +1000 drm/nouveau: recognise GA106 commit 46741e4f593ff1bd0e4a140ab7e566701946484b upstream. I've got HW now, appears to work as expected so far. Signed-off-by: Ben Skeggs Cc: # 5.14+ Reviewed-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20211118030413.2610-1-skeggsb@gmail.com Signed-off-by: Greg Kroah-Hartman commit 832c006eec0d423a8956cf4e54700e6624ad4b4a Author: Alex Deucher Date: Tue Nov 23 11:36:01 2021 -0500 drm/amdgpu/pm: fix powerplay OD interface commit d5c7255dc7ff6e1239d794b9c53029d83ced04ca upstream. The overclocking interface currently appends data to a string. Revert back to using sprintf(). Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1774 Fixes: 6db0c87a0a8ee1 ("amdgpu/pm: Replace hwmgr smu usage of sprintf with sysfs_emit") Acked-by: Evan Quan Acked-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2def7fdf5c823ae4dfc65c92701848b27fc7ebe6 Author: Philip Yang Date: Fri Nov 12 19:05:08 2021 -0500 drm/amdgpu: IH process reset count when restart commit 4d62555f624582e60be416fbc4772cd3fcd12b1a upstream. Otherwise when IH process restart, count is zero, the loop will not exit to wake_up_all after processing AMDGPU_IH_MAX_NUM_IVS interrupts. Cc: stable@vger.kernel.org Signed-off-by: Philip Yang Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 1c939a53b26b6b39378a77f76a49be8dd6df7af0 Author: Pavel Begunkov Date: Fri Nov 26 14:38:15 2021 +0000 io_uring: fix link traversal locking commit 6af3f48bf6156a7f02e91aca64e2927c4bebda03 upstream. WARNING: inconsistent lock state 5.16.0-rc2-syzkaller #0 Not tainted inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. ffff888078e11418 (&ctx->timeout_lock ){?.+.}-{2:2} , at: io_timeout_fn+0x6f/0x360 fs/io_uring.c:5943 {HARDIRQ-ON-W} state was registered at: [...] spin_unlock_irq include/linux/spinlock.h:399 [inline] __io_poll_remove_one fs/io_uring.c:5669 [inline] __io_poll_remove_one fs/io_uring.c:5654 [inline] io_poll_remove_one+0x236/0x870 fs/io_uring.c:5680 io_poll_remove_all+0x1af/0x235 fs/io_uring.c:5709 io_ring_ctx_wait_and_kill+0x1cc/0x322 fs/io_uring.c:9534 io_uring_release+0x42/0x46 fs/io_uring.c:9554 __fput+0x286/0x9f0 fs/file_table.c:280 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [inline] do_exit+0xc14/0x2b40 kernel/exit.c:832 674ee8e1b4a41 ("io_uring: correct link-list traversal locking") fixed a data race but introduced a possible deadlock and inconsistentcy in irq states. E.g. io_poll_remove_all() spin_lock_irq(timeout_lock) io_poll_remove_one() spin_lock/unlock_irq(poll_lock); spin_unlock_irq(timeout_lock) Another type of problem is freeing a request while holding ->timeout_lock, which may leads to a deadlock in io_commit_cqring() -> io_flush_timeouts() and other places. Having 3 nested locks is also too ugly. Add io_match_task_safe(), which would briefly take and release timeout_lock for race prevention inside, so the actuall request cancellation / free / etc. code doesn't have it taken. Reported-by: syzbot+ff49a3059d49b0ca0eec@syzkaller.appspotmail.com Reported-by: syzbot+847f02ec20a6609a328b@syzkaller.appspotmail.com Reported-by: syzbot+3368aadcd30425ceb53b@syzkaller.appspotmail.com Reported-by: syzbot+51ce8887cdef77c9ac83@syzkaller.appspotmail.com Reported-by: syzbot+3cb756a49d2f394a9ee3@syzkaller.appspotmail.com Fixes: 674ee8e1b4a41 ("io_uring: correct link-list traversal locking") Cc: stable@kernel.org # 5.15+ Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/397f7ebf3f4171f1abe41f708ac1ecb5766f0b68.1637937097.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3d2a1e68fd9904fdc1b02f2e7d40ca47df7ba39f Author: Pavel Begunkov Date: Fri Nov 26 14:38:14 2021 +0000 io_uring: fail cancellation for EXITING tasks commit 617a89484debcd4e7999796d693cf0b77d2519de upstream. WARNING: CPU: 1 PID: 20 at fs/io_uring.c:6269 io_try_cancel_userdata+0x3c5/0x640 fs/io_uring.c:6269 CPU: 1 PID: 20 Comm: kworker/1:0 Not tainted 5.16.0-rc1-syzkaller #0 Workqueue: events io_fallback_req_func RIP: 0010:io_try_cancel_userdata+0x3c5/0x640 fs/io_uring.c:6269 Call Trace: io_req_task_link_timeout+0x6b/0x1e0 fs/io_uring.c:6886 io_fallback_req_func+0xf9/0x1ae fs/io_uring.c:1334 process_one_work+0x9b2/0x1690 kernel/workqueue.c:2298 worker_thread+0x658/0x11f0 kernel/workqueue.c:2445 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 We need original task's context to do cancellations, so if it's dying and the callback is executed in a fallback mode, fail the cancellation attempt. Fixes: 89b263f6d56e6 ("io_uring: run linked timeouts from task_work") Cc: stable@kernel.org # 5.15+ Reported-by: syzbot+ab0cfe96c2b3cd1c1153@syzkaller.appspotmail.com Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/4c41c5f379c6941ad5a07cd48cb66ed62199cf7e.1637937097.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 09eb40f6776c8b50c2e46a504bf5483440ca607d Author: Pavel Begunkov Date: Tue Nov 23 01:45:35 2021 +0000 io_uring: correct link-list traversal locking commit 674ee8e1b4a41d2fdffc885c55350c3fbb38c22a upstream. As io_remove_next_linked() is now under ->timeout_lock (see io_link_timeout_fn), we should update locking around io_for_each_link() and io_match_task() to use the new lock. Cc: stable@kernel.org # 5.15+ Fixes: 89850fce16a1a ("io_uring: run timeouts from task_work") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/b54541cedf7de59cb5ae36109e58529ca16e66aa.1637631883.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c673d72d2f61c2d887f0cab2cb33d660b9cd7ad0 Author: Stefano Stabellini Date: Tue Nov 23 13:07:48 2021 -0800 xen: detect uninitialized xenbus in xenbus_init commit 36e8f60f0867d3b70d398d653c17108459a04efe upstream. If the xenstore page hasn't been allocated properly, reading the value of the related hvm_param (HVM_PARAM_STORE_PFN) won't actually return error. Instead, it will succeed and return zero. Instead of attempting to xen_remap a bad guest physical address, detect this condition and return early. Note that although a guest physical address of zero for HVM_PARAM_STORE_PFN is theoretically possible, it is not a good choice and zero has never been validly used in that capacity. Also recognize all bits set as an invalid value. For 32-bit Linux, any pfn above ULONG_MAX would get truncated. Pfns above ULONG_MAX should never be passed by the Xen tools to HVM guests anyway, so check for this condition and return early. Cc: stable@vger.kernel.org Signed-off-by: Stefano Stabellini Reviewed-by: Juergen Gross Reviewed-by: Jan Beulich Link: https://lore.kernel.org/r/20211123210748.1910236-1-sstabellini@kernel.org Signed-off-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 6660b61a4182f7f2708807995ca3f64a9f719b92 Author: Stefano Stabellini Date: Mon Nov 15 14:27:19 2021 -0800 xen: don't continue xenstore initialization in case of errors commit 08f6c2b09ebd4b326dbe96d13f94fee8f9814c78 upstream. In case of errors in xenbus_init (e.g. missing xen_store_gfn parameter), we goto out_error but we forget to reset xen_store_domain_type to XS_UNKNOWN. As a consequence xenbus_probe_initcall and other initcalls will still try to initialize xenstore resulting into a crash at boot. [ 2.479830] Call trace: [ 2.482314] xb_init_comms+0x18/0x150 [ 2.486354] xs_init+0x34/0x138 [ 2.489786] xenbus_probe+0x4c/0x70 [ 2.498432] xenbus_probe_initcall+0x2c/0x7c [ 2.503944] do_one_initcall+0x54/0x1b8 [ 2.507358] kernel_init_freeable+0x1ac/0x210 [ 2.511617] kernel_init+0x28/0x130 [ 2.516112] ret_from_fork+0x10/0x20 Cc: Cc: jbeulich@suse.com Signed-off-by: Stefano Stabellini Link: https://lore.kernel.org/r/20211115222719.2558207-1-sstabellini@kernel.org Reviewed-by: Jan Beulich Signed-off-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 695438d30896e8f0b189f8e4059b4f38691a8160 Author: Miklos Szeredi Date: Thu Nov 25 14:05:18 2021 +0100 fuse: release pipe buf after last use commit 473441720c8616dfaf4451f9c7ea14f0eb5e5d65 upstream. Checking buf->flags should be done before the pipe_buf_release() is called on the pipe buffer, since releasing the buffer might modify the flags. This is exactly what page_cache_pipe_buf_release() does, and which results in the same VM_BUG_ON_PAGE(PageLRU(page)) that the original patch was trying to fix. Reported-by: Justin Forbes Fixes: 712a951025c0 ("fuse: fix page stealing") Cc: # v2.6.35 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit c8d3775745adacf9784a7a80a82d047051752573 Author: Dan Carpenter Date: Tue Nov 9 14:49:36 2021 +0300 staging: r8188eu: fix a memory leak in rtw_wx_read32() commit be4ea8f383551b9dae11b8dfff1f38b3b5436e9a upstream. Free "ptmp" before returning -EINVAL. Fixes: 2b42bd58b321 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver") Cc: stable Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20211109114935.GC16587@kili Signed-off-by: Greg Kroah-Hartman commit 788fa64fa8de1052b295d7101060a71e74cdc904 Author: Michael Straube Date: Mon Nov 8 11:55:37 2021 +0100 staging: r8188eu: use GFP_ATOMIC under spinlock commit 4a293eaf92a510ff688dc7b3f0815221f99c9d1b upstream. In function rtw_report_sec_ie() kzalloc() is called under a spinlock, so the allocation have to be atomic. Call tree: -> rtw_select_and_join_from_scanned_queue() <- takes a spinlock -> rtw_joinbss_cmd() -> rtw_restruct_sec_ie() -> rtw_report_sec_ie() Fixes: 2b42bd58b321 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver") Cc: stable Signed-off-by: Michael Straube Link: https://lore.kernel.org/r/20211108105537.31655-1-straube.linux@gmail.com Signed-off-by: Greg Kroah-Hartman commit b0d61266f56ae394b697dcc05698b46be6b1a194 Author: Larry Finger Date: Sun Nov 7 11:35:43 2021 -0600 staging: r8188eu: Fix breakage introduced when 5G code was removed commit d5f0b804368951b6b4a77d2f14b5bb6a04b0e011 upstream. In commit 221abd4d478a ("staging: r8188eu: Remove no more necessary definitions and code"), two entries were removed from RTW_ChannelPlanMap[], but not replaced with zeros. The position within this table is important, thus the patch broke systems operating in regulatory domains osted later than entry 0x13 in the table. Unfortunately, the FCC entry comes before that point and most testers did not see this problem. Fixes: 221abd4d478a ("staging: r8188eu: Remove no more necessary definitions and code") Cc: Stable # v5.5+ Reported-and-tested-by: Zameer Manji Reported-by: kernel test robot Reviewed-by: Phillip Potter Signed-off-by: Larry Finger Link: https://lore.kernel.org/r/20211107173543.7486-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman commit 51bdb198872cc18afb986c443f985cd389e1e834 Author: Fabio M. De Francesco Date: Mon Nov 1 20:18:47 2021 +0100 staging: r8188eu: Use kzalloc() with GFP_ATOMIC in atomic context commit c15a059f85de49c542e6ec2464967dd2b2aa18f6 upstream. Use the GFP_ATOMIC flag of kzalloc() with two memory allocation in report_del_sta_event(). This function is called while holding spinlocks, therefore it is not allowed to sleep. With the GFP_ATOMIC type flag, the allocation is high priority and must not sleep. This issue is detected by Smatch which emits the following warning: "drivers/staging/r8188eu/core/rtw_mlme_ext.c:6848 report_del_sta_event() warn: sleeping in atomic context". After the change, the post-commit hook output the following message: "CHECK: Prefer kzalloc(sizeof(*pcmd_obj)...) over kzalloc(sizeof(struct cmd_obj)...)". According to the above "CHECK", use the preferred style in the first kzalloc(). Fixes: 79f712ea994d ("staging: r8188eu: Remove wrappers for kalloc() and kzalloc()") Fixes: 15865124feed ("staging: r8188eu: introduce new core dir for RTL8188eu driver") Signed-off-by: Fabio M. De Francesco Link: https://lore.kernel.org/r/20211101191847.6749-1-fmdefrancesco@gmail.com Signed-off-by: Greg Kroah-Hartman Cc: stable commit e27ee2f607fe6a9b923ef1fc65461c0613c97594 Author: Dan Carpenter Date: Wed Nov 17 10:20:16 2021 +0300 staging: rtl8192e: Fix use after free in _rtl92e_pci_disconnect() commit b535917c51acc97fb0761b1edec85f1f3d02bda4 upstream. The free_rtllib() function frees the "dev" pointer so there is use after free on the next line. Re-arrange things to avoid that. Fixes: 66898177e7e5 ("staging: rtl8192e: Fix unload/reload problem") Cc: stable Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20211117072016.GA5237@kili Signed-off-by: Greg Kroah-Hartman commit f0340bea83020c09bd1661e472d5068fb1570888 Author: Takashi Iwai Date: Tue Nov 16 08:20:27 2021 +0100 staging: greybus: Add missing rwsem around snd_ctl_remove() calls commit ffcf7ae90f4489047d7b076539ba207024dea5f6 upstream. snd_ctl_remove() has to be called with card->controls_rwsem held (when called after the card instantiation). This patch adds the missing rwsem calls around it. Fixes: 510e340efe0c ("staging: greybus: audio: Add helper APIs for dynamic audio modules") Cc: stable Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20211116072027.18466-1-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit d58ec6e81803e679a838f20acdcbb4e7a23e308f Author: Noralf Trønnes Date: Fri Nov 5 21:43:58 2021 +0100 staging/fbtft: Fix backlight commit 7865dd24934ad580d1bcde8f63c39f324211a23b upstream. Commit b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate") forgot to update fbtft breaking its backlight support when FB_BACKLIGHT is a module. Since FB_TFT selects FB_BACKLIGHT there's no need for this conditional so just remove it and we're good. Fixes: b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate") Cc: Acked-by: Sam Ravnborg Signed-off-by: Noralf Trønnes Link: https://lore.kernel.org/r/20211105204358.2991-1-noralf@tronnes.org Signed-off-by: Greg Kroah-Hartman commit d048d3eb3ca7e2f847b78125b12bdb9d86681495 Author: Jason Gerecke Date: Mon Nov 8 16:31:01 2021 -0800 HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts commit 7fb0413baa7f8a04caef0c504df9af7e0623d296 upstream. The HID descriptor of many of Wacom's touch input devices include a "Confidence" usage that signals if a particular touch collection contains useful data. The driver does not look at this flag, however, which causes even invalid contacts to be reported to userspace. A lucky combination of kernel event filtering and device behavior (specifically: contact ID 0 == invalid, contact ID >0 == valid; and order all data so that all valid contacts are reported before any invalid contacts) spare most devices from any visibly-bad behavior. The DTH-2452 is one example of an unlucky device that misbehaves. It uses ID 0 for both the first valid contact and all invalid contacts. Because we report both the valid and invalid contacts, the kernel reports that contact 0 first goes down (valid) and then goes up (invalid) in every report. This causes ~100 clicks per second simply by touching the screen. This patch inroduces new `confidence` flag in our `hid_data` structure. The value is initially set to `true` at the start of a report and can be set to `false` if an invalid touch usage is seen. Link: https://github.com/linuxwacom/input-wacom/issues/270 Fixes: f8b6a74719b5 ("HID: wacom: generic: Support multiple tools per report") Signed-off-by: Jason Gerecke Tested-by: Joshua Dickens Cc: Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 28849ab40bac4e8bfa5be1b9017091af4b135071 Author: Helge Deller Date: Sun Nov 21 11:10:55 2021 +0100 Revert "parisc: Fix backtrace to always include init funtion names" commit 98400ad75e95860e9a10ec78b0b90ab66184a2ce upstream. This reverts commit 279917e27edc293eb645a25428c6ab3f3bca3f86. With the CONFIG_HARDENED_USERCOPY option enabled, this patch triggers kernel bugs at runtime: usercopy: Kernel memory overwrite attempt detected to kernel text (offset 2084839, size 6)! kernel BUG at mm/usercopy.c:99! Backtrace: IAOQ[0]: usercopy_abort+0xc4/0xe8 [<00000000406ed1c8>] __check_object_size+0x174/0x238 [<00000000407086d4>] copy_strings.isra.0+0x3e8/0x708 [<0000000040709a20>] do_execveat_common.isra.0+0x1bc/0x328 [<000000004070b760>] compat_sys_execve+0x7c/0xb8 [<0000000040303eb8>] syscall_exit+0x0/0x14 The problem is, that we have an init section of at least 2MB size which starts at _stext and is freed after bootup. If then later some kernel data is (temporarily) stored in this free memory, check_kernel_text_object() will trigger a bug since the data appears to be inside the kernel text (>=_stext) area: if (overlaps(ptr, len, _stext, _etext)) usercopy_abort("kernel text"); Signed-off-by: Helge Deller Cc: stable@kernel.org # 5.4+ Signed-off-by: Greg Kroah-Hartman commit 02130f5e7ca3770daf2a086b3bee22134901a488 Author: Hans Verkuil Date: Tue Nov 2 12:24:26 2021 +0000 media: cec: copy sequence field for the reply commit 13cbaa4c2b7bf9f8285e1164d005dbf08244ecd5 upstream. When the reply for a non-blocking transmit arrives, the sequence field for that reply was never filled in, so userspace would have no way of associating the reply to the original transmit. Copy the sequence field to ensure that this is now possible. Signed-off-by: Hans Verkuil Fixes: 0dbacebede1e ([media] cec: move the CEC framework out of staging and to media) Cc: Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 238c04518ff1871352217706c0998ff8d43223ad Author: Takashi Iwai Date: Thu Nov 18 08:16:36 2021 +0100 ALSA: hda/realtek: Fix LED on HP ProBook 435 G7 commit 05ec7161084565365ecf267e9909a897a95f243a upstream. HP ProBook 435 G7 (SSID 103c:8735) needs the similar quirk as another HP ProBook for enabling the mute and the mic-mute LEDs. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215021 Cc: Link: https://lore.kernel.org/r/20211118071636.14738-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4e6ef09400484f0ad25afa469d589a522f0bcd80 Author: Werner Sembach Date: Fri Nov 12 12:07:04 2021 +0100 ALSA: hda/realtek: Add quirk for ASRock NUC Box 1100 commit 174a7fb3859ae75b0f0e35ef852459d8882b55b5 upstream. This applies a SND_PCI_QUIRK(...) to the ASRock NUC Box 1100 series. This fixes the issue of the headphone jack not being detected unless warm rebooted from a certain other OS. When booting a certain other OS some coeff settings are changed that enable the audio jack. These settings are preserved on a warm reboot and can be easily dumped. The relevant indexes and values where gathered by naively diff-ing and reading a working and a non-working coeff dump. Signed-off-by: Werner Sembach Cc: Link: https://lore.kernel.org/r/20211112110704.1022501-1-wse@tuxedocomputers.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 25aa8e9f1031a88184d71cfc88e98d4f96e9c373 Author: Takashi Iwai Date: Thu Nov 18 22:57:29 2021 +0100 ALSA: ctxfi: Fix out-of-range access commit 76c47183224c86e4011048b80f0e2d0d166f01c2 upstream. The master and next_conj of rcs_ops are used for iterating the resource list entries, and currently those are supposed to return the current value. The problem is that next_conf may go over the last entry before the loop abort condition is evaluated, and it may return the "current" value that is beyond the array size. It was caught recently as a GPF, for example. Those return values are, however, never actually evaluated, hence basically we don't have to consider the current value as the return at all. By dropping those return values, the potential out-of-range access above is also fixed automatically. This patch changes the return type of master and next_conj callbacks to void and drop the superfluous code accordingly. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214985 Cc: Link: https://lore.kernel.org/r/20211118215729.26257-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 849d86e85951ea409b09e384d1f0060a3adfdb58 Author: Todd Kjos Date: Fri Nov 12 10:07:20 2021 -0800 binder: fix test regression due to sender_euid change commit c21a80ca0684ec2910344d72556c816cb8940c01 upstream. This is a partial revert of commit 29bc22ac5e5b ("binder: use euid from cred instead of using task"). Setting sender_euid using proc->cred caused some Android system test regressions that need further investigation. It is a partial reversion because subsequent patches rely on proc->cred. Fixes: 29bc22ac5e5b ("binder: use euid from cred instead of using task") Cc: stable@vger.kernel.org # 4.4+ Acked-by: Christian Brauner Signed-off-by: Todd Kjos Change-Id: I9b1769a3510fed250bb21859ef8beebabe034c66 Link: https://lore.kernel.org/r/20211112180720.2858135-1-tkjos@google.com Signed-off-by: Greg Kroah-Hartman commit 816904fd873b2b1245939589147c3bc6082c5286 Author: Mathias Nyman Date: Tue Nov 23 12:16:56 2021 +0200 usb: hub: Fix locking issues with address0_mutex commit 6cca13de26eea6d32a98d96d916a048d16a12822 upstream. Fix the circular lock dependency and unbalanced unlock of addess0_mutex introduced when fixing an address0_mutex enumeration retry race in commit ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Make sure locking order between port_dev->status_lock and address0_mutex is correct, and that address0_mutex is not unlocked in hub_port_connect "done:" codepath which may be reached without locking address0_mutex Fixes: 6ae6dc22d2d1 ("usb: hub: Fix usb enumeration issue due to address0 race") Cc: Reported-by: Marek Szyprowski Tested-by: Hans de Goede Tested-by: Marek Szyprowski Acked-by: Hans de Goede Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20211123101656.1113518-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 55197c24c6f13c89bba401cd7f2c2800ef02c024 Author: Mathias Nyman Date: Tue Nov 16 00:16:30 2021 +0200 usb: hub: Fix usb enumeration issue due to address0 race commit 6ae6dc22d2d1ce6aa77a6da8a761e61aca216f8b upstream. xHC hardware can only have one slot in default state with address 0 waiting for a unique address at a time, otherwise "undefined behavior may occur" according to xhci spec 5.4.3.4 The address0_mutex exists to prevent this across both xhci roothubs. If hub_port_init() fails, it may unlock the mutex and exit with a xhci slot in default state. If the other xhci roothub calls hub_port_init() at this point we end up with two slots in default state. Make sure the address0_mutex protects the slot default state across hub_port_init() retries, until slot is addressed or disabled. Note, one known minor case is not fixed by this patch. If device needs to be reset during resume, but fails all hub_port_init() retries in usb_reset_and_verify_device(), then it's possible the slot is still left in default state when address0_mutex is unlocked. Cc: Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel") Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20211115221630.871204-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 631a7e0afebd7613cc414541fca347b0949bd2c4 Author: Dmitry Osipenko Date: Mon Nov 8 01:44:55 2021 +0300 usb: xhci: tegra: Check padctrl interrupt presence in device tree commit 51f2246158f686c881859f4b620f831f06e296e1 upstream. Older device-trees don't specify padctrl interrupt and xhci-tegra driver now fails to probe with -EINVAL using those device-trees. Check interrupt presence and keep runtime PM disabled if it's missing to fix the trouble. Fixes: 971ee247060d ("usb: xhci: tegra: Enable ELPG for runtime/system PM") Cc: # 5.14+ Reported-by: Nicolas Chauvet Tested-by: Nicolas Chauvet # T124 TK1 Tested-by: Thomas Graichen # T124 Nyan Big Tested-by: Thierry Reding # Tegra CI Acked-by: Thierry Reding Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20211107224455.10359-1-digetx@gmail.com Signed-off-by: Greg Kroah-Hartman commit 907f68f03f4f9c932b7d325c20c93fa7388056a8 Author: Ondrej Jirman Date: Mon Nov 8 11:28:32 2021 +0100 usb: typec: fusb302: Fix masking of comparator and bc_lvl interrupts commit 362468830dd5bea8bf6ad5203b2ea61f8a4e8288 upstream. The code that enables either BC_LVL or COMP_CHNG interrupt in tcpm_set_cc wrongly assumes that the interrupt is unmasked by writing 1 to the apropriate bit in the mask register. In fact, interrupts are enabled when the mask is 0, so the tcpm_set_cc enables interrupt for COMP_CHNG when it expects BC_LVL interrupt to be enabled. This causes inability of the driver to recognize cable unplug events in host mode (unplug is recognized only via a COMP_CHNG interrupt). In device mode this bug was masked by simultaneous triggering of the VBUS change interrupt, because of loss of VBUS when the port peer is providing power. Fixes: 48242e30532b ("usb: typec: fusb302: Revert "Resolve fixed power role contract setup"") Cc: stable Cc: Hans de Goede Reviewed-by: Hans de Goede Acked-by: Heikki Krogerus Signed-off-by: Ondrej Jirman Link: https://lore.kernel.org/r/20211108102833.2793803-1-megous@megous.com Signed-off-by: Greg Kroah-Hartman commit a815c169c8c4f1dac2444ca4d0217b766fbbd2af Author: Dan Carpenter Date: Wed Nov 17 10:49:23 2021 +0300 usb: chipidea: ci_hdrc_imx: fix potential error pointer dereference in probe commit d4d2e5329ae9dfd6742c84d79f7d143d10410f1b upstream. If the first call to devm_usb_get_phy_by_phandle(dev, "fsl,usbphy", 0) fails with something other than -ENODEV then it leads to an error pointer dereference. For those errors we should just jump directly to the error handling. Fixes: 8253a34bfae3 ("usb: chipidea: ci_hdrc_imx: Also search for 'phys' phandle") Cc: stable Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20211117074923.GF5237@kili Signed-off-by: Greg Kroah-Hartman commit 39509d76a9a3d02f379d52cb4b1449469c56c0e0 Author: Nikolay Aleksandrov Date: Tue Nov 23 12:27:19 2021 +0200 net: nexthop: fix null pointer dereference when IPv6 is not enabled commit 1c743127cc54b112b155f434756bd4b5fa565a99 upstream. When we try to add an IPv6 nexthop and IPv6 is not enabled (!CONFIG_IPV6) we'll hit a NULL pointer dereference[1] in the error path of nh_create_ipv6() due to calling ipv6_stub->fib6_nh_release. The bug has been present since the beginning of IPv6 nexthop gateway support. Commit 1aefd3de7bc6 ("ipv6: Add fib6_nh_init and release to stubs") tells us that only fib6_nh_init has a dummy stub because fib6_nh_release should not be called if fib6_nh_init returns an error, but the commit below added a call to ipv6_stub->fib6_nh_release in its error path. To fix it return the dummy stub's -EAFNOSUPPORT error directly without calling ipv6_stub->fib6_nh_release in nh_create_ipv6()'s error path. [1] Output is a bit truncated, but it clearly shows the error. BUG: kernel NULL pointer dereference, address: 000000000000000000 #PF: supervisor instruction fetch in kernel modede #PF: error_code(0x0010) - not-present pagege PGD 0 P4D 0 Oops: 0010 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 638 Comm: ip Kdump: loaded Not tainted 5.16.0-rc1+ #446 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffff888109f5b8f0 EFLAGS: 00010286^Ac RAX: 0000000000000000 RBX: ffff888109f5ba28 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8881008a2860 RBP: ffff888109f5b9d8 R08: 0000000000000000 R09: 0000000000000000 R10: ffff888109f5b978 R11: ffff888109f5b948 R12: 00000000ffffff9f R13: ffff8881008a2a80 R14: ffff8881008a2860 R15: ffff8881008a2840 FS: 00007f98de70f100(0000) GS:ffff88822bf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000100efc000 CR4: 00000000000006e0 Call Trace: nh_create_ipv6+0xed/0x10c rtm_new_nexthop+0x6d7/0x13f3 ? check_preemption_disabled+0x3d/0xf2 ? lock_is_held_type+0xbe/0xfd rtnetlink_rcv_msg+0x23f/0x26a ? check_preemption_disabled+0x3d/0xf2 ? rtnl_calcit.isra.0+0x147/0x147 netlink_rcv_skb+0x61/0xb2 netlink_unicast+0x100/0x187 netlink_sendmsg+0x37f/0x3a0 ? netlink_unicast+0x187/0x187 sock_sendmsg_nosec+0x67/0x9b ____sys_sendmsg+0x19d/0x1f9 ? copy_msghdr_from_user+0x4c/0x5e ? rcu_read_lock_any_held+0x2a/0x78 ___sys_sendmsg+0x6c/0x8c ? asm_sysvec_apic_timer_interrupt+0x12/0x20 ? lockdep_hardirqs_on+0xd9/0x102 ? sockfd_lookup_light+0x69/0x99 __sys_sendmsg+0x50/0x6e do_syscall_64+0xcb/0xf2 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f98dea28914 Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41 89 d4 55 48 89 f5 53 RSP: 002b:00007fff859f5e68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e2e RAX: ffffffffffffffda RBX: 00000000619cb810 RCX: 00007f98dea28914 RDX: 0000000000000000 RSI: 00007fff859f5ed0 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000008 R10: fffffffffffffce6 R11: 0000000000000246 R12: 0000000000000001 R13: 000055c0097ae520 R14: 000055c0097957fd R15: 00007fff859f63a0 Modules linked in: bridge stp llc bonding virtio_net Cc: stable@vger.kernel.org Fixes: 53010f991a9f ("nexthop: Add support for IPv6 gateways") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 54619c356f6c0004ca1631cc98fe7cc4b1600b9d Author: Martyn Welch Date: Mon Nov 22 18:44:45 2021 +0000 net: usb: Correct PHY handling of smsc95xx commit a049a30fc27c1cb2e12889bbdbd463dbf750103a upstream. The smsc95xx driver is dropping phy speed settings and causing a stack trace at device unbind: [  536.379147] smsc95xx 2-1:1.0 eth1: unregister 'smsc95xx' usb-ci_hdrc.2-1, smsc95xx USB 2.0 Ethernet [  536.425029] ------------[ cut here ]------------ [  536.429650] WARNING: CPU: 0 PID: 439 at fs/kernfs/dir.c:1535 kernfs_remove_by_name_ns+0xb8/0xc0 [  536.438416] kernfs: can not remove 'attached_dev', no directory [  536.444363] Modules linked in: xts dm_crypt dm_mod atmel_mxt_ts smsc95xx usbnet [  536.451748] CPU: 0 PID: 439 Comm: sh Tainted: G        W         5.15.0 #1 [  536.458636] Hardware name: Freescale i.MX53 (Device Tree Support) [  536.464735] Backtrace:  [  536.467190] [<80b1c904>] (dump_backtrace) from [<80b1cb48>] (show_stack+0x20/0x24) [  536.474787]  r7:000005ff r6:8035b294 r5:600f0013 r4:80d8af78 [  536.480449] [<80b1cb28>] (show_stack) from [<80b1f764>] (dump_stack_lvl+0x48/0x54) [  536.488035] [<80b1f71c>] (dump_stack_lvl) from [<80b1f788>] (dump_stack+0x18/0x1c) [  536.495620]  r5:00000009 r4:80d9b820 [  536.499198] [<80b1f770>] (dump_stack) from [<80124fac>] (__warn+0xfc/0x114) [  536.506187] [<80124eb0>] (__warn) from [<80b1d21c>] (warn_slowpath_fmt+0xa8/0xdc) [  536.513688]  r7:000005ff r6:80d9b820 r5:80d9b8e0 r4:83744000 [  536.519349] [<80b1d178>] (warn_slowpath_fmt) from [<8035b294>] (kernfs_remove_by_name_ns+0xb8/0xc0) [  536.528416]  r9:00000001 r8:00000000 r7:824926dc r6:00000000 r5:80df6c2c r4:00000000 [  536.536162] [<8035b1dc>] (kernfs_remove_by_name_ns) from [<80b1f56c>] (sysfs_remove_link+0x4c/0x50) [  536.545225]  r6:7f00f02c r5:80df6c2c r4:83306400 [  536.549845] [<80b1f520>] (sysfs_remove_link) from [<806f9c8c>] (phy_detach+0xfc/0x11c) [  536.557780]  r5:82492000 r4:83306400 [  536.561359] [<806f9b90>] (phy_detach) from [<806f9cf8>] (phy_disconnect+0x4c/0x58) [  536.568943]  r7:824926dc r6:7f00f02c r5:82492580 r4:83306400 [  536.574604] [<806f9cac>] (phy_disconnect) from [<7f00a310>] (smsc95xx_disconnect_phy+0x30/0x38 [smsc95xx]) [  536.584290]  r5:82492580 r4:82492580 [  536.587868] [<7f00a2e0>] (smsc95xx_disconnect_phy [smsc95xx]) from [<7f001570>] (usbnet_stop+0x70/0x1a0 [usbnet]) [  536.598161]  r5:82492580 r4:82492000 [  536.601740] [<7f001500>] (usbnet_stop [usbnet]) from [<808baa70>] (__dev_close_many+0xb4/0x12c) [  536.610466]  r8:83744000 r7:00000000 r6:83744000 r5:83745b74 r4:82492000 [  536.617170] [<808ba9bc>] (__dev_close_many) from [<808bab78>] (dev_close_many+0x90/0x120) [  536.625365]  r7:00000001 r6:83745b74 r5:83745b8c r4:82492000 [  536.631026] [<808baae8>] (dev_close_many) from [<808bf408>] (unregister_netdevice_many+0x15c/0x704) [  536.640094]  r9:00000001 r8:81130b98 r7:83745b74 r6:83745bc4 r5:83745b8c r4:82492000 [  536.647840] [<808bf2ac>] (unregister_netdevice_many) from [<808bfa50>] (unregister_netdevice_queue+0xa0/0xe8) [  536.657775]  r10:8112bcc0 r9:83306c00 r8:83306c80 r7:8291e420 r6:83744000 r5:00000000 [  536.665608]  r4:82492000 [  536.668143] [<808bf9b0>] (unregister_netdevice_queue) from [<808bfac0>] (unregister_netdev+0x28/0x30) [  536.677381]  r6:7f01003c r5:82492000 r4:82492000 [  536.682000] [<808bfa98>] (unregister_netdev) from [<7f000b40>] (usbnet_disconnect+0x64/0xdc [usbnet]) [  536.691241]  r5:82492000 r4:82492580 [  536.694819] [<7f000adc>] (usbnet_disconnect [usbnet]) from [<8076b958>] (usb_unbind_interface+0x80/0x248) [  536.704406]  r5:7f01003c r4:83306c80 [  536.707984] [<8076b8d8>] (usb_unbind_interface) from [<8061765c>] (device_release_driver_internal+0x1c4/0x1cc) [  536.718005]  r10:8112bcc0 r9:80dff1dc r8:83306c80 r7:83744000 r6:7f01003c r5:00000000 [  536.725838]  r4:8291e420 [  536.728373] [<80617498>] (device_release_driver_internal) from [<80617684>] (device_release_driver+0x20/0x24) [  536.738302]  r7:83744000 r6:810d4f4c r5:8291e420 r4:8176ae30 [  536.743963] [<80617664>] (device_release_driver) from [<806156cc>] (bus_remove_device+0xf0/0x148) [  536.752858] [<806155dc>] (bus_remove_device) from [<80610018>] (device_del+0x198/0x41c) [  536.760880]  r7:83744000 r6:8116e2e4 r5:8291e464 r4:8291e420 [  536.766542] [<8060fe80>] (device_del) from [<80768fe8>] (usb_disable_device+0xcc/0x1e0) [  536.774576]  r10:8112bcc0 r9:80dff1dc r8:00000001 r7:8112bc48 r6:8291e400 r5:00000001 [  536.782410]  r4:83306c00 [  536.784945] [<80768f1c>] (usb_disable_device) from [<80769c30>] (usb_set_configuration+0x514/0x8dc) [  536.794011]  r10:00000000 r9:00000000 r8:832c3600 r7:00000004 r6:810d5688 r5:00000000 [  536.801844]  r4:83306c00 [  536.804379] [<8076971c>] (usb_set_configuration) from [<80775fac>] (usb_generic_driver_disconnect+0x34/0x38) [  536.814236]  r10:832c3610 r9:83745ef8 r8:832c3600 r7:00000004 r6:810d5688 r5:83306c00 [  536.822069]  r4:83306c00 [  536.824605] [<80775f78>] (usb_generic_driver_disconnect) from [<8076b850>] (usb_unbind_device+0x30/0x70) [  536.834100]  r5:83306c00 r4:810d5688 [  536.837678] [<8076b820>] (usb_unbind_device) from [<8061765c>] (device_release_driver_internal+0x1c4/0x1cc) [  536.847432]  r5:822fb480 r4:83306c80 [  536.851009] [<80617498>] (device_release_driver_internal) from [<806176a8>] (device_driver_detach+0x20/0x24) [  536.860853]  r7:00000004 r6:810d4f4c r5:810d5688 r4:83306c80 [  536.866515] [<80617688>] (device_driver_detach) from [<80614d98>] (unbind_store+0x70/0xe4) [  536.874793] [<80614d28>] (unbind_store) from [<80614118>] (drv_attr_store+0x30/0x3c) [  536.882554]  r7:00000000 r6:00000000 r5:83739200 r4:80614d28 [  536.888217] [<806140e8>] (drv_attr_store) from [<8035cb68>] (sysfs_kf_write+0x48/0x54) [  536.896154]  r5:83739200 r4:806140e8 [  536.899732] [<8035cb20>] (sysfs_kf_write) from [<8035be84>] (kernfs_fop_write_iter+0x11c/0x1d4) [  536.908446]  r5:83739200 r4:00000004 [  536.912024] [<8035bd68>] (kernfs_fop_write_iter) from [<802b87fc>] (vfs_write+0x258/0x3e4) [  536.920317]  r10:00000000 r9:83745f58 r8:83744000 r7:00000000 r6:00000004 r5:00000000 [  536.928151]  r4:82adacc0 [  536.930687] [<802b85a4>] (vfs_write) from [<802b8b0c>] (ksys_write+0x74/0xf4) [  536.937842]  r10:00000004 r9:007767a0 r8:83744000 r7:00000000 r6:00000000 r5:82adacc0 [  536.945676]  r4:82adacc0 [  536.948213] [<802b8a98>] (ksys_write) from [<802b8ba4>] (sys_write+0x18/0x1c) [  536.955367]  r10:00000004 r9:83744000 r8:80100244 r7:00000004 r6:76f47b58 r5:76fc0350 [  536.963200]  r4:00000004 [  536.965735] [<802b8b8c>] (sys_write) from [<80100060>] (ret_fast_syscall+0x0/0x48) [  536.973320] Exception stack(0x83745fa8 to 0x83745ff0) [  536.978383] 5fa0:                   00000004 76fc0350 00000001 007767a0 00000004 00000000 [  536.986569] 5fc0: 00000004 76fc0350 76f47b58 00000004 76f47c7c 76f48114 00000000 7e87991c [  536.994753] 5fe0: 00000498 7e879908 76e6dce8 76eca2e8 [  536.999922] ---[ end trace 9b835d809816b435 ]--- The driver should not be connecting and disconnecting the PHY when the device is opened and closed, it should be stopping and starting the PHY. The phy should be connected as part of binding and disconnected during unbinding. As this results in the PHY not being reset during open, link speed, etc. settings set prior to the link coming up are now not being lost. It is necessary for phy_stop() to only be called when the phydev still exists (resolving the above stack trace). When unbinding, ".unbind" will be called prior to ".stop", with phy_disconnect() already having called phy_stop() before the phydev becomes inaccessible. Signed-off-by: Martyn Welch Cc: Steve Glendinning Cc: UNGLinuxDriver@microchip.com Cc: "David S. Miller" Cc: Jakub Kicinski Cc: stable@kernel.org # v5.15 Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 70ba56d4f464d9ad380fd99f21b3279cfc6201f8 Author: Albert Wang Date: Tue Nov 9 17:26:42 2021 +0800 usb: dwc3: gadget: Fix null pointer exception commit 26288448120b28af1dfd85a6fa6b6d55a16c7f2f upstream. In the endpoint interrupt functions dwc3_gadget_endpoint_transfer_in_progress() and dwc3_gadget_endpoint_trbs_complete() will dereference the endpoint descriptor. But it could be cleared in __dwc3_gadget_ep_disable() when accessory disconnected. So we need to check whether it is null or not before dereferencing it. Fixes: f09ddcfcb8c5 ("usb: dwc3: gadget: Prevent EP queuing while stopping transfers") Cc: stable Reviewed-by: Jack Pham Signed-off-by: Albert Wang Link: https://lore.kernel.org/r/20211109092642.3507692-1-albertccwang@google.com Signed-off-by: Greg Kroah-Hartman commit ecba9bc9946b9dc36d454b3b9708a9be5178eb83 Author: Thinh Nguyen Date: Mon Oct 25 16:35:06 2021 -0700 usb: dwc3: gadget: Check for L1/L2/U3 for Start Transfer commit 63c4c320ccf77074ffe9019ac596603133c1b517 upstream. The programming guide noted that the driver needs to verify if the link state is in U0 before executing the Start Transfer command. If it's not in U0, the driver needs to perform remote wakeup. This is not accurate. If the link state is in U1/U2, then the controller will not respond to link recovery request from DCTL.ULSTCHNGREQ. The Start Transfer command will trigger a link recovery if it is in U1/U2. A clarification will be added to the programming guide for all controller versions. The current implementation shouldn't cause any functional issue. It may occasionally report an invalid time out warning from failed link recovery request. The driver will still go ahead with the Start Transfer command if the remote wakeup fails. The new change only initiates remote wakeup where it is needed, which is when the link state is in L1/L2/U3. Fixes: c36d8e947a56 ("usb: dwc3: gadget: put link to U0 before Start Transfer") Cc: Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/05b4a5fbfbd0863fc9b1d7af934a366219e3d0b4.1635204761.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit d92d8b5893668db88483fd85f96b7f9e5dadf544 Author: Thinh Nguyen Date: Mon Oct 25 16:21:10 2021 -0700 usb: dwc3: gadget: Ignore NoStream after End Transfer commit d74dc3e9f58c28689cef1faccf918e06587367d3 upstream. The End Transfer command from a stream endpoint will generate a NoStream event, and we should ignore it. Currently we set the flag DWC3_EP_IGNORE_NEXT_NOSTREAM to track this prior to sending the command, and it will be cleared on the next stream event. However, a stream event may be generated before the End Transfer command completion and prematurely clear the flag. Fix this by setting the flag on End Transfer completion instead. Fixes: 140ca4cfea8a ("usb: dwc3: gadget: Handle stream transfers") Cc: Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/cee1253af4c3600edb878d11c9c08b040817ae23.1635203975.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 949fac2e09ddd1efdfbbe0ee155c3ac6c143e336 Author: Thinh Nguyen Date: Mon Oct 25 16:15:32 2021 -0700 usb: dwc3: core: Revise GHWPARAMS9 offset commit 250fdabec6ffcaf895c5e0dedca62706ef10d8f6 upstream. During our predesign phase for DWC_usb32, the GHWPARAMS9 register offset was 0xc680. We revised our final design, and the GHWPARAMS9 offset is now moved to 0xc6e8 on release. Fixes: 16710380d3aa ("usb: dwc3: Capture new capability register GHWPARAMS9") Cc: Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/1541737108266a97208ff827805be1f32852590c.1635202893.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit a6cc2445103ef6c406e735cb545b44e3edeb18bb Author: Fabio Aiuto Date: Sat Nov 13 15:29:59 2021 +0100 usb: dwc3: leave default DMA for PCI devices commit 47ce45906ca9870cf5267261f155fb7c70307cf0 upstream. in case of a PCI dwc3 controller, leave the default DMA mask. Calling of a 64 bit DMA mask breaks the driver on cherrytrail based tablets like Cyberbook T116. Fixes: 45d39448b4d0 ("usb: dwc3: support 64 bit DMA in platform driver") Cc: stable Reported-by: Hans De Goede Tested-by: Fabio Aiuto Tested-by: Hans de Goede Signed-off-by: Fabio Aiuto Link: https://lore.kernel.org/r/20211113142959.27191-1-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman commit a5e1211d44519e0c25d64b7cabefdf59c19029be Author: Nathan Chancellor Date: Fri Nov 5 07:58:03 2021 -0700 usb: dwc2: hcd_queue: Fix use of floating point literal commit 310780e825f3ffd211b479b8f828885a6faedd63 upstream. A new commit in LLVM causes an error on the use of 'long double' when '-mno-x87' is used, which the kernel does through an alias, '-mno-80387' (see the LLVM commit below for more details around why it does this). drivers/usb/dwc2/hcd_queue.c:1744:25: error: expression requires 'long double' type support, but target 'x86_64-unknown-linux-gnu' does not support it delay = ktime_set(0, DWC2_RETRY_WAIT_DELAY); ^ drivers/usb/dwc2/hcd_queue.c:62:34: note: expanded from macro 'DWC2_RETRY_WAIT_DELAY' #define DWC2_RETRY_WAIT_DELAY (1 * 1E6L) ^ 1 error generated. This happens due to the use of a 'long double' literal. The 'E6' part of '1E6L' causes the literal to be a 'double' then the 'L' suffix promotes it to 'long double'. There is no visible reason for a floating point value in this driver, as the value is only used as a parameter to a function that expects an integer type. Use NSEC_PER_MSEC, which is the same integer value as '1E6L', to avoid changing functionality but fix the error. Link: https://github.com/ClangBuiltLinux/linux/issues/1497 Link: https://github.com/llvm/llvm-project/commit/a8083d42b1c346e21623a1d36d1f0cadd7801d83 Fixes: 6ed30a7d8ec2 ("usb: dwc2: host: use hrtimer for NAK retries") Cc: stable Reviewed-by: Nick Desaulniers Reviewed-by: John Keeping Acked-by: Minas Harutyunyan Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20211105145802.2520658-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 581f42756d29cdbbfa219f9edb0107d653b31005 Author: Minas Harutyunyan Date: Thu Nov 4 11:36:01 2021 +0400 usb: dwc2: gadget: Fix ISOC flow for elapsed frames commit 7ad4a0b1d46b2612f4429a72afd8f137d7efa9a9 upstream. Added updating of request frame number for elapsed frames, otherwise frame number will remain as previous use of request. This will allow function driver to correctly track frames in case of Missed ISOC occurs. Added setting request actual length to 0 for elapsed frames. In Slave mode when pushing data to RxFIFO by dwords, request actual length incrementing accordingly. But before whole packet will be pushed into RxFIFO and send to host can occurs Missed ISOC and data will not send to host. So, in this case request actual length should be reset to 0. Fixes: 91bb163e1e4f ("usb: dwc2: gadget: Fix ISOC flow for BDMA and Slave") Cc: stable Reviewed-by: John Keeping Signed-off-by: Minas Harutyunyan Link: https://lore.kernel.org/r/c356baade6e9716d312d43df08d53ae557cb8037.1636011277.git.Minas.Harutyunyan@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 8228d7b0281c541807af67de598e001dceaacb84 Author: Mingjie Zhang Date: Tue Nov 23 21:37:57 2021 +0800 USB: serial: option: add Fibocom FM101-GL variants commit 88459e3e42760abb2299bbf6cb1026491170e02a upstream. Update the USB serial option driver support for the Fibocom FM101-GL Cat.6 LTE modules as there are actually several different variants. - VID:PID 2cb7:01a2, FM101-GL are laptop M.2 cards (with MBIM interfaces for /Linux/Chrome OS) - VID:PID 2cb7:01a4, FM101-GL for laptop debug M.2 cards(with adb interface for /Linux/Chrome OS) 0x01a2: mbim, tty, tty, diag, gnss 0x01a4: mbim, diag, tty, adb, gnss, gnss Here are the outputs of lsusb -v and usb-devices: T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 86 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2cb7 ProdID=01a2 Rev= 5.04 S: Manufacturer=Fibocom Wireless Inc. S: Product=Fibocom FM101-GL Module S: SerialNumber=673326ce C:* #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=(none) I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=(none) I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none) I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=(none) Bus 002 Device 084: ID 2cb7:01a2 Fibocom Wireless Inc. Fibocom FM101-GL Module Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2cb7 idProduct 0x01a2 bcdDevice 5.04 iManufacturer 1 Fibocom Wireless Inc. iProduct 2 Fibocom FM101-GL Module iSerial 3 673326ce bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x015d bNumInterfaces 6 bConfigurationValue 1 iConfiguration 4 MBIM_DUN_DUN_DIAG_NMEA bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 896mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 14 bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 14 bInterfaceProtocol 0 iInterface 5 Fibocom FM101-GL LTE Modem CDC Header: bcdCDC 1.10 CDC Union: bMasterInterface 0 bSlaveInterface 1 CDC MBIM: bcdMBIMVersion 1.00 wMaxControlMessage 4096 bNumberFilters 32 bMaxFilterSize 128 wMaxSegmentSize 2048 bmNetworkCapabilities 0x20 8-byte ntb input size CDC MBIM Extended: bcdMBIMExtendedVersion 1.00 bMaxOutstandingCommandMessages 64 wMTU 1500 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 9 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 2 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 2 iInterface 6 MBIM Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0f EP 15 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 2 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 64 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 64 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 64 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 85 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=2cb7 ProdID=01a4 Rev= 5.04 S: Manufacturer=Fibocom Wireless Inc. S: Product=Fibocom FM101-GL Module S: SerialNumber=673326ce C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=896mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none) I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=(none) I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=(none) I:* If#= 6 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=40 Driver=(none) Bus 002 Device 085: ID 2cb7:01a4 Fibocom Wireless Inc. Fibocom FM101-GL Module Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 3.20 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x2cb7 idProduct 0x01a4 bcdDevice 5.04 iManufacturer 1 Fibocom Wireless Inc. iProduct 2 Fibocom FM101-GL Module iSerial 3 673326ce bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0180 bNumInterfaces 7 bConfigurationValue 1 iConfiguration 4 MBIM_DIAG_DUN_ADB_GNSS_GNSS bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 896mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass 2 Communications bFunctionSubClass 14 bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 14 bInterfaceProtocol 0 iInterface 5 Fibocom FM101-GL LTE Modem CDC Header: bcdCDC 1.10 CDC Union: bMasterInterface 0 bSlaveInterface 1 CDC MBIM: bcdMBIMVersion 1.00 wMaxControlMessage 4096 bNumberFilters 32 bMaxFilterSize 128 wMaxSegmentSize 2048 bmNetworkCapabilities 0x20 8-byte ntb input size CDC MBIM Extended: bcdMBIMExtendedVersion 1.00 bMaxOutstandingCommandMessages 64 wMTU 1500 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 9 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 2 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 10 CDC Data bInterfaceSubClass 0 bInterfaceProtocol 2 iInterface 6 MBIM Data Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0f EP 15 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 2 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 48 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 64 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 66 bInterfaceProtocol 1 iInterface 8 ADB Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 64 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 64 iInterface 0 ** UNRECOGNIZED: 05 24 00 10 01 ** UNRECOGNIZED: 05 24 01 00 00 ** UNRECOGNIZED: 04 24 02 02 ** UNRECOGNIZED: 05 24 06 00 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x89 EP 9 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 9 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x88 EP 8 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Signed-off-by: Mingjie Zhang Link: https://lore.kernel.org/r/20211123133757.37475-1-superzmj@fibocom.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 616dc7809103143b331e992c3645329bd477b369 Author: Daniele Palmas Date: Fri Nov 19 15:03:19 2021 +0100 USB: serial: option: add Telit LE910S1 0x9200 composition commit e353f3e88720300c3d72f49a4bea54f42db1fa5e upstream. Add the following Telit LE910S1 composition: 0x9200: tty Signed-off-by: Daniele Palmas Link: https://lore.kernel.org/r/20211119140319.10448-1-dnlplm@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit ea773394a0035e5f90843476200b633a0a9ead9d Author: Johan Hovold Date: Tue Nov 23 10:10:17 2021 +0100 USB: serial: pl2303: fix GC type detection commit aa5721a9e0c9fb8a4bdfe0c8751377cd537d6174 upstream. At least some PL2303GC have a bcdDevice of 0x105 instead of 0x100 as the datasheet claims. Add it to the list of known release numbers for the HXN (G) type. Note the chip type could only be determined indirectly based on its package being of QFP type, which appears to only be available for PL2303GC. Fixes: 894758d0571d ("USB: serial: pl2303: tighten type HXN (G) detection") Cc: stable@vger.kernel.org # 5.13 Reported-by: Anton Lundin Link: https://lore.kernel.org/r/20211123071613.GZ108031@montezuma.acc.umu.se Link: https://lore.kernel.org/r/20211123091017.30708-1-johan@kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit e0b8e1ae8306ab8d8e56d8bbc32327eba5f12a42 Author: Rafael J. Wysocki Date: Thu Nov 18 14:37:38 2021 +0100 ACPI: CPPC: Add NULL pointer check to cppc_get_perf() commit 935dff305da2be7957a5ce8f07f45d6c4c1c6984 upstream. Check cpc_desc against NULL in cppc_get_perf(), so it doesn't crash down the road if cpc_desc is NULL. Fixes: 0654cf05d17b ("ACPI: CPPC: Introduce cppc_get_nominal_perf()") Reported-by: Kai-Heng Feng Signed-off-by: Rafael J. Wysocki Cc: 5.15+ # 5.15+ Tested-by: Kai-Heng Feng Signed-off-by: Greg Kroah-Hartman commit dbd961095ed44585fc628962d7c7da866852f9a5 Author: Sakari Ailus Date: Wed Nov 17 20:07:34 2021 +0200 ACPI: Get acpi_device's parent from the parent field commit 9054fc6d57e80c27c0b0632966416144f2092c2b upstream. Printk modifier %pfw is used to print the full path of the device name. This is obtained device by device until a device no longer has a parent. On ACPI getting the parent fwnode is done by calling acpi_get_parent() which tries to down() a semaphore. But local IRQs are now disabled in vprintk_store() before the mutex is acquired. This is obviously a problem. Luckily struct device, embedded in struct acpi_device, has a parent field already. Use that field to get the parent instead of relying on acpi_get_parent(). Fixes: 3bd32d6a2ee6 ("lib/vsprintf: Add %pfw conversion specifier for printing fwnode names") Cc: 5.5+ # 5.5+ Signed-off-by: Sakari Ailus Reviewed-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c82cd4eed1282806e48345e3c4d37a3c1d3f90e7 Author: Damien Le Moal Date: Fri Aug 20 16:02:55 2021 +0900 scsi: sd: Fix sd_do_mode_sense() buffer length handling commit c749301ebee82eb5e97dec14b6ab31a4aabe37a6 upstream. For devices that explicitly asked for MODE SENSE(10) use, make sure that scsi_mode_sense() is called with a buffer of at least 8 bytes so that the sense header fits. Link: https://lore.kernel.org/r/20210820070255.682775-4-damien.lemoal@wdc.com Signed-off-by: Damien Le Moal Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman