Skip to main content

Browse the archive

https://github.com/torvalds/linux
05 April 2024, 19:05:47 UTC
sort by:
Revision Author Date Message Commit Date
dd0b455 Seevalamuthu Mariappan 19 March 2021, 14:18:52 UTC mac80211: clear sta->fast_rx when STA removed from 4-addr VLAN In some race conditions, with more clients and traffic configuration, below crash is seen when making the interface down. sta->fast_rx wasn't cleared when STA gets removed from 4-addr AP_VLAN interface. The crash is due to try accessing 4-addr AP_VLAN interface's net_device (fast_rx->dev) which has been deleted already. Resolve this by clearing sta->fast_rx pointer when STA removes from a 4-addr VLAN. [ 239.449529] Unable to handle kernel NULL pointer dereference at virtual address 00000004 [ 239.449531] pgd = 80204000 ... [ 239.481496] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.4.60 #227 [ 239.481591] Hardware name: Generic DT based system [ 239.487665] task: be05b700 ti: be08e000 task.ti: be08e000 [ 239.492360] PC is at get_rps_cpu+0x2d4/0x31c [ 239.497823] LR is at 0xbe08fc54 ... [ 239.778574] [<80739740>] (get_rps_cpu) from [<8073cb10>] (netif_receive_skb_internal+0x8c/0xac) [ 239.786722] [<8073cb10>] (netif_receive_skb_internal) from [<8073d578>] (napi_gro_receive+0x48/0xc4) [ 239.795267] [<8073d578>] (napi_gro_receive) from [<c7b83e8c>] (ieee80211_mark_rx_ba_filtered_frames+0xbcc/0x12d4 [mac80211]) [ 239.804776] [<c7b83e8c>] (ieee80211_mark_rx_ba_filtered_frames [mac80211]) from [<c7b84d4c>] (ieee80211_rx_napi+0x7b8/0x8c8 [mac8 0211]) [ 239.815857] [<c7b84d4c>] (ieee80211_rx_napi [mac80211]) from [<c7f63d7c>] (ath11k_dp_process_rx+0x7bc/0x8c8 [ath11k]) [ 239.827757] [<c7f63d7c>] (ath11k_dp_process_rx [ath11k]) from [<c7f5b6c4>] (ath11k_dp_service_srng+0x2c0/0x2e0 [ath11k]) [ 239.838484] [<c7f5b6c4>] (ath11k_dp_service_srng [ath11k]) from [<7f55b7dc>] (ath11k_ahb_ext_grp_napi_poll+0x20/0x84 [ath11k_ahb] ) [ 239.849419] [<7f55b7dc>] (ath11k_ahb_ext_grp_napi_poll [ath11k_ahb]) from [<8073ce1c>] (net_rx_action+0xe0/0x28c) [ 239.860945] [<8073ce1c>] (net_rx_action) from [<80324868>] (__do_softirq+0xe4/0x228) [ 239.871269] [<80324868>] (__do_softirq) from [<80324c48>] (irq_exit+0x98/0x108) [ 239.879080] [<80324c48>] (irq_exit) from [<8035c59c>] (__handle_domain_irq+0x90/0xb4) [ 239.886114] [<8035c59c>] (__handle_domain_irq) from [<8030137c>] (gic_handle_irq+0x50/0x94) [ 239.894100] [<8030137c>] (gic_handle_irq) from [<803024c0>] (__irq_svc+0x40/0x74) Signed-off-by: Seevalamuthu Mariappan <seevalam@codeaurora.org> Link: https://lore.kernel.org/r/1616163532-3881-1-git-send-email-seevalam@codeaurora.org Signed-off-by: Johannes Berg <johannes.berg@intel.com> 08 April 2021, 08:14:42 UTC
c8426b2 Takashi Iwai 07 April 2021, 09:57:30 UTC ALSA: hda/realtek: Fix speaker amp setup on Acer Aspire E1 We've got a report about Acer Aspire E1 (PCI SSID 1025:0840) that loses the speaker output after resume. With the comparison of COEF dumps, it was identified that the COEF 0x0d bits 0x6000 corresponds to the speaker amp. This patch adds the specific quirk for the device to restore the COEF bits at the codec (re-)initialization. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1183869 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210407095730.12560-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> 08 April 2021, 08:04:05 UTC
2bbbb07 Dave Airlie 08 April 2021, 07:11:09 UTC Merge tag 'amd-drm-fixes-5.12-2021-04-08' of https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-5.12-2021-04-08: amdgpu: - DCN3 fix - Fix CAC setting regression for TOPAZ - Fix ttm regression radeon: - Fix ttm regression Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210408045512.3879-1-alexander.deucher@amd.com 08 April 2021, 07:11:11 UTC
cdcc108 Alex Deucher 07 April 2021, 13:28:23 UTC drm/amdgpu/smu7: fix CAC setting on TOPAZ We need to enable MC CAC for mclk switching to work. Fixes: d765129a719f ("drm/amd/pm: correct sclk/mclk dpm enablement") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1561 Tested-by: Konstantin Kharlamov <Hi-Angel@yandex.ru> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org 08 April 2021, 04:36:40 UTC
2efc021 xinhui pan 07 April 2021, 12:57:50 UTC drm/radeon: Fix size overflow ttm->num_pages is uint32. Hit overflow when << PAGE_SHIFT directly Fixes: 230c079fdcf4 ("drm/ttm: make num_pages uint32_t") Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org 08 April 2021, 04:36:40 UTC
1b0b6e9 xinhui pan 07 April 2021, 11:29:39 UTC drm/amdgpu: Fix size overflow ttm->num_pages is uint32. Hit overflow when << PAGE_SHIFT directly Fixes: 230c079fdcf4 ("drm/ttm: make num_pages uint32_t") Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org 08 April 2021, 04:36:40 UTC
6ad7f23 Pavel Begunkov 08 April 2021, 00:54:39 UTC io_uring: clear F_REISSUE right after getting it There are lots of ways r/w request may continue its path after getting REQ_F_REISSUE, it's not necessarily io-wq and can be, e.g. apoll, and submitted via io_async_task_func() -> __io_req_task_submit() Clear the flag right after getting it, so the next attempt is well prepared regardless how the request will be executed. Fixes: 230d50d448ac ("io_uring: move reissue into regular IO path") Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> Link: https://lore.kernel.org/r/11dcead939343f4e27cab0074d34afcab771bfa4.1617842918.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk> 08 April 2021, 04:10:19 UTC
0fc9322 Maciek Borzecki 06 April 2021, 15:02:29 UTC cifs: escape spaces in share names Commit 653a5efb849a ("cifs: update super_operations to show_devname") introduced the display of devname for cifs mounts. However, when mounting a share which has a whitespace in the name, that exact share name is also displayed in mountinfo. Make sure that all whitespace is escaped. Signed-off-by: Maciek Borzecki <maciek.borzecki@gmail.com> CC: <stable@vger.kernel.org> # 5.11+ Reviewed-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com> 08 April 2021, 02:30:27 UTC
d135be0 Wan Jiabing 01 April 2021, 07:51:17 UTC fs: cifs: Remove unnecessary struct declaration struct cifs_readdata is declared twice. One is declared at 208th line. And struct cifs_readdata is defined blew. The declaration here is not needed. Remove the duplicate. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Reviewed-by: Shyam Prasad N <sprasad@microsoft.com> Signed-off-by: Steve French <stfrench@microsoft.com> 08 April 2021, 02:30:27 UTC
4e456b3 Shyam Prasad N 31 March 2021, 14:35:24 UTC cifs: On cifs_reconnect, resolve the hostname again. On cifs_reconnect, make sure that DNS resolution happens again. It could be the cause of connection to go dead in the first place. This also contains the fix for a build issue identified by Intel bot. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com> CC: <stable@vger.kernel.org> # 5.11+ Signed-off-by: Steve French <stfrench@microsoft.com> 08 April 2021, 02:29:36 UTC
9ad6e9c Ondrej Mosnacek 07 April 2021, 07:24:43 UTC selinux: fix race between old and new sidtab Since commit 1b8b31a2e612 ("selinux: convert policy read-write lock to RCU"), there is a small window during policy load where the new policy pointer has already been installed, but some threads may still be holding the old policy pointer in their read-side RCU critical sections. This means that there may be conflicting attempts to add a new SID entry to both tables via sidtab_context_to_sid(). See also (and the rest of the thread): https://lore.kernel.org/selinux/CAFqZXNvfux46_f8gnvVvRYMKoes24nwm2n3sPbMjrB8vKTW00g@mail.gmail.com/ Fix this by installing the new policy pointer under the old sidtab's spinlock along with marking the old sidtab as "frozen". Then, if an attempt to add new entry to a "frozen" sidtab is detected, make sidtab_context_to_sid() return -ESTALE to indicate that a new policy has been installed and that the caller will have to abort the policy transaction and try again after re-taking the policy pointer (which is guaranteed to be a newer policy). This requires adding a retry-on-ESTALE logic to all callers of sidtab_context_to_sid(), but fortunately these are easy to determine and aren't that many. This seems to be the simplest solution for this problem, even if it looks somewhat ugly. Note that other places in the kernel (e.g. do_mknodat() in fs/namei.c) use similar stale-retry patterns, so I think it's reasonable. Cc: stable@vger.kernel.org Fixes: 1b8b31a2e612 ("selinux: convert policy read-write lock to RCU") Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by: Paul Moore <paul@paul-moore.com> 08 April 2021, 00:42:56 UTC
e1ad897 Kamal Heib 04 April 2021, 12:55:01 UTC RDMA/qedr: Fix kernel panic when trying to access recv_cq As INI QP does not require a recv_cq, avoid the following null pointer dereference by checking if the qp_type is not INI before trying to extract the recv_cq. BUG: kernel NULL pointer dereference, address: 00000000000000e0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 54250 Comm: mpitests-IMB-MP Not tainted 5.12.0-rc5 #1 Hardware name: Dell Inc. PowerEdge R320/0KM5PX, BIOS 2.7.0 08/19/2019 RIP: 0010:qedr_create_qp+0x378/0x820 [qedr] Code: 02 00 00 50 e8 29 d4 a9 d1 48 83 c4 18 e9 65 fe ff ff 48 8b 53 10 48 8b 43 18 44 8b 82 e0 00 00 00 45 85 c0 0f 84 10 74 00 00 <8b> b8 e0 00 00 00 85 ff 0f 85 50 fd ff ff e9 fd 73 00 00 48 8d bd RSP: 0018:ffff9c8f056f7a70 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff9c8f056f7b58 RCX: 0000000000000009 RDX: ffff8c41a9744c00 RSI: ffff9c8f056f7b58 RDI: ffff8c41c0dfa280 RBP: ffff8c41c0dfa280 R08: 0000000000000002 R09: 0000000000000001 R10: 0000000000000000 R11: ffff8c41e06fc608 R12: ffff8c4194052000 R13: 0000000000000000 R14: ffff8c4191546070 R15: ffff8c41c0dfa280 FS: 00007f78b2787b80(0000) GS:ffff8c43a3200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e0 CR3: 00000001011d6002 CR4: 00000000001706f0 Call Trace: ib_uverbs_handler_UVERBS_METHOD_QP_CREATE+0x4e4/0xb90 [ib_uverbs] ? ib_uverbs_cq_event_handler+0x30/0x30 [ib_uverbs] ib_uverbs_run_method+0x6f6/0x7a0 [ib_uverbs] ? ib_uverbs_handler_UVERBS_METHOD_QP_DESTROY+0x70/0x70 [ib_uverbs] ? __cond_resched+0x15/0x30 ? __kmalloc+0x5a/0x440 ib_uverbs_cmd_verbs+0x195/0x360 [ib_uverbs] ? xa_load+0x6e/0x90 ? cred_has_capability+0x7c/0x130 ? avc_has_extended_perms+0x17f/0x440 ? vma_link+0xae/0xb0 ? vma_set_page_prot+0x2a/0x60 ? mmap_region+0x298/0x6c0 ? do_mmap+0x373/0x520 ? selinux_file_ioctl+0x17f/0x220 ib_uverbs_ioctl+0xa7/0x110 [ib_uverbs] __x64_sys_ioctl+0x84/0xc0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f78b120262b Fixes: 06e8d1df46ed ("RDMA/qedr: Add support for user mode XRC-SRQ's") Link: https://lore.kernel.org/r/20210404125501.154789-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib <kamalheib1@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 07 April 2021, 23:28:26 UTC
b6a37a9 Takashi Iwai 02 April 2021, 08:23:17 UTC drm/i915: Fix invalid access to ACPI _DSM objects intel_dsm_platform_mux_info() tries to parse the ACPI package data from _DSM for the debug information, but it assumes the fixed format without checking what values are stored in the elements actually. When an unexpected value is returned from BIOS, it may lead to GPF or NULL dereference, as reported recently. Add the checks of the contents in the returned values and skip the values for invalid cases. v1->v2: Check the info contents before dereferencing, too BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074 Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210402082317.871-1-tiwai@suse.de (cherry picked from commit 337d7a1621c7f02af867229990ac67c97da1b53a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> 07 April 2021, 23:07:44 UTC
50ce682 Dmitry Baryshkov 06 April 2021, 23:06:06 UTC clk: fixed: fix double free in resource managed fixed-factor clock devm_clk_hw_register_fixed_factor_release(), the release function for the devm_clk_hw_register_fixed_factor(), calls clk_hw_unregister_fixed_factor(), which will kfree() the clock. However after that the devres functions will also kfree the allocated data, resulting in double free/memory corruption. Just call clk_hw_unregister() instead, leaving kfree() to devres code. Reported-by: Rob Clark <robdclark@chromium.org> Cc: Daniel Palmer <daniel@0x0f.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210406230606.3007138-1-dmitry.baryshkov@linaro.org Fixes: 0b9266d295ce ("clk: fixed: add devm helper for clk_hw_register_fixed_factor()") [sboyd@kernel.org: Remove ugly cast] Signed-off-by: Stephen Boyd <sboyd@kernel.org> 07 April 2021, 23:01:25 UTC
8a12f88 Anirudh Rayabharam 07 April 2021, 17:27:22 UTC net: hso: fix null-ptr-deref during tty device unregistration Multiple ttys try to claim the same the minor number causing a double unregistration of the same device. The first unregistration succeeds but the next one results in a null-ptr-deref. The get_free_serial_index() function returns an available minor number but doesn't assign it immediately. The assignment is done by the caller later. But before this assignment, calls to get_free_serial_index() would return the same minor number. Fix this by modifying get_free_serial_index to assign the minor number immediately after one is found to be and rename it to obtain_minor() to better reflect what it does. Similary, rename set_serial_by_index() to release_minor() and modify it to free up the minor number of the given hso_serial. Every obtain_minor() should have corresponding release_minor() call. Fixes: 72dc1c096c705 ("HSO: add option hso driver") Reported-by: syzbot+c49fe6089f295a05e6f8@syzkaller.appspotmail.com Tested-by: syzbot+c49fe6089f295a05e6f8@syzkaller.appspotmail.com Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Anirudh Rayabharam <mail@anirudhrb.com> Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 22:18:15 UTC
5d1dbac David S. Miller 07 April 2021, 22:04:55 UTC Merge tag 'ieee802154-for-davem-2021-04-07' of git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan Stefan Schmidt says: ==================== pull-request: ieee802154 for net 2021-04-07 An update from ieee802154 for your *net* tree. Most of these are coming from the flood of syzkaller reports lately got for the ieee802154 subsystem. There are likely to come more for this, but this is a good batch to get out for now. Alexander Aring created a patchset to avoid llsec handling on a monitor interface, which we do not support. Alex Shi removed a unused macro. Pavel Skripkin fixed another protection fault found by syzkaller. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 22:04:55 UTC
107adc6 David S. Miller 07 April 2021, 21:57:35 UTC Merge tag 'wireless-drivers-2021-04-07' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers Kalle Valo says: ==================== wireless-drivers fixes for v5.12 Third, and last, set of fixes for v5.12. Small fixes, iwlwifi having most of them. brcmfmac regression caused by cfg80211 changes is the most important here. iwlwifi * fix a lockdep warning * fix regulatory feature detection in certain firmware versions * new hardware support * fix lockdep warning * mvm: fix beacon protection checks mt76 * mt7921: fix airtime reporting brcmfmac * fix a deadlock regression ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 21:57:35 UTC
3cf1482 David S. Miller 07 April 2021, 21:53:04 UTC Merge branch 'ethtool-link_mode' Danielle Ratson says: ==================== Fix link_mode derived params functionality Currently, link_mode parameter derives 3 other link parameters, speed, lanes and duplex, and the derived information is sent to user space. Few bugs were found in that functionality. First, some drivers clear the 'ethtool_link_ksettings' struct in their get_link_ksettings() callback and cause receiving wrong link mode information in user space. And also, some drivers can report random values in the 'link_mode' field and cause general protection fault. Second, the link parameters are only derived in netlink path so in ioctl path, we don't any reasonable values. Third, setting 'speed 10000 lanes 1' fails since the lanes parameter wasn't set for ETHTOOL_LINK_MODE_10000baseR_FEC_BIT. Patch #1 solves the first two problems by removing link_mode parameter and deriving the link parameters in driver instead of ethtool. Patch #2 solves the third one, by setting the lanes parameter for the link_mode. v3: * Remove the link_mode parameter in the first patch to solve both two issues from patch#1 and patch#2. * Add the second patch to solve the third issue. v2: * Add patch #2. * Introduce 'cap_link_mode_supported' instead of adding a validity field to 'ethtool_link_ksettings' struct in patch #1. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 21:53:04 UTC
fde32db Danielle Ratson 07 April 2021, 10:06:52 UTC ethtool: Add lanes parameter for ETHTOOL_LINK_MODE_10000baseR_FEC_BIT Lanes field is missing for ETHTOOL_LINK_MODE_10000baseR_FEC_BIT link mode and it causes a failure when trying to set 'speed 10000 lanes 1' on Spectrum-2 machines when autoneg is set to on. Add the lanes parameter for ETHTOOL_LINK_MODE_10000baseR_FEC_BIT link mode. Fixes: c8907043c6ac9 ("ethtool: Get link mode in use instead of speed and duplex parameters") Signed-off-by: Danielle Ratson <danieller@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 21:53:04 UTC
a975d7d Danielle Ratson 07 April 2021, 10:06:51 UTC ethtool: Remove link_mode param and derive link params from driver Some drivers clear the 'ethtool_link_ksettings' struct in their get_link_ksettings() callback, before populating it with actual values. Such drivers will set the new 'link_mode' field to zero, resulting in user space receiving wrong link mode information given that zero is a valid value for the field. Another problem is that some drivers (notably tun) can report random values in the 'link_mode' field. This can result in a general protection fault when the field is used as an index to the 'link_mode_params' array [1]. This happens because such drivers implement their set_link_ksettings() callback by simply overwriting their private copy of 'ethtool_link_ksettings' struct with the one they get from the stack, which is not always properly initialized. Fix these problems by removing 'link_mode' from 'ethtool_link_ksettings' and instead have drivers call ethtool_params_from_link_mode() with the current link mode. The function will derive the link parameters (e.g., speed) from the link mode and fill them in the 'ethtool_link_ksettings' struct. v3: * Remove link_mode parameter and derive the link parameters in the driver instead of passing link_mode parameter to ethtool and derive it there. v2: * Introduce 'cap_link_mode_supported' instead of adding a validity field to 'ethtool_link_ksettings' struct. [1] general protection fault, probably for non-canonical address 0xdffffc00f14cc32c: 0000 [#1] PREEMPT SMP KASAN KASAN: probably user-memory-access in range [0x000000078a661960-0x000000078a661967] CPU: 0 PID: 8452 Comm: syz-executor360 Not tainted 5.11.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__ethtool_get_link_ksettings+0x1a3/0x3a0 net/ethtool/ioctl.c:446 Code: b7 3e fa 83 fd ff 0f 84 30 01 00 00 e8 16 b0 3e fa 48 8d 3c ed 60 d5 69 8a 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 +38 d0 7c 08 84 d2 0f 85 b9 RSP: 0018:ffffc900019df7a0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff888026136008 RCX: 0000000000000000 RDX: 00000000f14cc32c RSI: ffffffff873439ca RDI: 000000078a661960 RBP: 00000000ffff8880 R08: 00000000ffffffff R09: ffff88802613606f R10: ffffffff873439bc R11: 0000000000000000 R12: 0000000000000000 R13: ffff88802613606c R14: ffff888011d0c210 R15: ffff888011d0c210 FS: 0000000000749300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004b60f0 CR3: 00000000185c2000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: linkinfo_prepare_data+0xfd/0x280 net/ethtool/linkinfo.c:37 ethnl_default_notify+0x1dc/0x630 net/ethtool/netlink.c:586 ethtool_notify+0xbd/0x1f0 net/ethtool/netlink.c:656 ethtool_set_link_ksettings+0x277/0x330 net/ethtool/ioctl.c:620 dev_ethtool+0x2b35/0x45d0 net/ethtool/ioctl.c:2842 dev_ioctl+0x463/0xb70 net/core/dev_ioctl.c:440 sock_do_ioctl+0x148/0x2d0 net/socket.c:1060 sock_ioctl+0x477/0x6a0 net/socket.c:1177 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: c8907043c6ac9 ("ethtool: Get link mode in use instead of speed and duplex parameters") Signed-off-by: Danielle Ratson <danieller@nvidia.com> Reported-by: Eric Dumazet <eric.dumazet@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 21:53:04 UTC
bb58023 David S. Miller 07 April 2021, 21:34:03 UTC Merge tag 'mlx5-fixes-2021-04-06' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5 fixes 2021-04-06 This series provides some fixes to mlx5 driver. Please pull and let me know if there is any problem. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 21:34:03 UTC
df7232c Qingqing Zhuo 25 March 2021, 07:44:11 UTC drm/amd/display: Add missing mask for DCN3 [Why] DCN3 is not reusing DCN1 mask_sh_list, causing SURFACE_FLIP_INT_MASK missing in the mapping. [How] Add the corresponding entry to DCN3 list. Signed-off-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> 07 April 2021, 21:30:39 UTC
a79ace4 Zheng Yongjun 07 April 2021, 01:59:45 UTC net: tipc: Fix spelling errors in net/tipc module These patches fix a series of spelling errors in net/tipc module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 21:29:29 UTC
9d68039 Kurt Kanzenbach 06 April 2021, 07:35:09 UTC net: hsr: Reset MAC header for Tx path Reset MAC header in HSR Tx path. This is needed, because direct packet transmission, e.g. by specifying PACKET_QDISC_BYPASS does not reset the MAC header. This has been observed using the following setup: |$ ip link add name hsr0 type hsr slave1 lan0 slave2 lan1 supervision 45 version 1 |$ ifconfig hsr0 up |$ ./test hsr0 The test binary is using mmap'ed sockets and is specifying the PACKET_QDISC_BYPASS socket option. This patch resolves the following warning on a non-patched kernel: |[ 112.725394] ------------[ cut here ]------------ |[ 112.731418] WARNING: CPU: 1 PID: 257 at net/hsr/hsr_forward.c:560 hsr_forward_skb+0x484/0x568 |[ 112.739962] net/hsr/hsr_forward.c:560: Malformed frame (port_src hsr0) The warning can be safely removed, because the other call sites of hsr_forward_skb() make sure that the skb is prepared correctly. Fixes: d346a3fae3ff ("packet: introduce PACKET_QDISC_BYPASS socket option") Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 21:25:12 UTC
cd90437 David S. Miller 07 April 2021, 21:22:49 UTC Merge branch 'ethtool-doc' Jakub Kicinski says: ==================== ethtool: kdoc fixes Number of kdoc fixes to ethtool headers. All comment changes. With all the patches posted kdoc script seems happy: $ ./scripts/kernel-doc -none include/uapi/linux/ethtool.h include/linux/ethtool.h $ Note that some of the changes are in -next, e.g. the FEC documentation update so full effect will be seen after trees converge. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 21:22:49 UTC
d9c65de Jakub Kicinski 07 April 2021, 00:28:27 UTC ethtool: fix kdoc in headers Fix remaining issues with kdoc in the ethtool headers. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 21:22:49 UTC
83e5fee Jakub Kicinski 07 April 2021, 00:28:26 UTC ethtool: document reserved fields in the uAPI Add a note on expected handling of reserved fields, and references to all kdocs. This fixes a bunch of kdoc warnings. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 21:22:49 UTC
f0ebc2b Jakub Kicinski 07 April 2021, 00:28:25 UTC ethtool: un-kdocify extended link state Extended link state structures and enums use kdoc headers but then do not describe any of the members. Convert to normal comments. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 21:22:49 UTC
0c85a7e Aditya Pakki 07 April 2021, 00:09:12 UTC net/rds: Avoid potential use after free in rds_send_remove_from_sock In case of rs failure in rds_send_remove_from_sock(), the 'rm' resource is freed and later under spinlock, causing potential use-after-free. Set the free pointer to NULL to avoid undefined behavior. Signed-off-by: Aditya Pakki <pakki001@umn.edu> Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> 07 April 2021, 21:01:24 UTC
454859c Linus Torvalds 07 April 2021, 20:21:21 UTC Merge tag 'arc-5.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc Pull ARC fixlets from Vineet Gupta: "A few straggler fixes for ARC" * tag 'arc-5.12-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: treewide: avoid the pointer addition with NULL pointer arc: kernel: Return -EFAULT if copy_to_user() fails ARC: haps: bump memory to 1 GB 07 April 2021, 20:21:21 UTC
92f1e8a Ian Rogers 07 April 2021, 15:39:55 UTC perf arm-spe: Avoid potential buffer overrun SPE extended headers are > 1 byte so ensure the buffer contains at least this before reading. This issue was detected by fuzzing. Signed-off-by: Ian Rogers <irogers@google.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andre Przywara <andre.przywara@arm.com> Cc: Dave Martin <dave.martin@arm.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Leo Yan <leo.yan@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Will Deacon <will@kernel.org> Link: http://lore.kernel.org/lkml/20210407153955.317215-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 07 April 2021, 19:23:20 UTC
f201327 Jin Yao 07 April 2021, 02:44:52 UTC perf report: Fix wrong LBR block sorting When '--total-cycles' is specified, it supports sorting for all blocks by 'Sampled Cycles%'. This is useful to concentrate on the globally hottest blocks. 'Sampled Cycles%' - block sampled cycles aggregation / total sampled cycles But in current code, it doesn't use the cycles aggregation. Part of 'cycles' counting is possibly dropped for some overlap jumps. But for identifying the hot block, we always need the full cycles. # perf record -b ./triad_loop # perf report --total-cycles --stdio Before: # # Sampled Cycles% Sampled Cycles Avg Cycles% Avg Cycles [Program Block Range] Shared Object # ............... .............. ........... .......... ............................................................. ................. # 0.81% 793 4.32% 793 [setup-vdso.h:34 -> setup-vdso.h:40] ld-2.27.so 0.49% 480 0.87% 160 [native_write_msr+0 -> native_write_msr+16] [kernel.kallsyms] 0.48% 476 0.52% 95 [native_read_msr+0 -> native_read_msr+29] [kernel.kallsyms] 0.31% 303 1.65% 303 [nmi_restore+0 -> nmi_restore+37] [kernel.kallsyms] 0.26% 255 1.39% 255 [nohz_balance_exit_idle+75 -> nohz_balance_exit_idle+162] [kernel.kallsyms] 0.24% 234 1.28% 234 [end_repeat_nmi+67 -> end_repeat_nmi+83] [kernel.kallsyms] 0.23% 227 1.24% 227 [__irqentry_text_end+96 -> __irqentry_text_end+126] [kernel.kallsyms] 0.20% 194 1.06% 194 [native_set_debugreg+52 -> native_set_debugreg+56] [kernel.kallsyms] 0.11% 106 0.14% 26 [native_sched_clock+0 -> native_sched_clock+98] [kernel.kallsyms] 0.10% 97 0.53% 97 [trigger_load_balance+0 -> trigger_load_balance+67] [kernel.kallsyms] 0.09% 85 0.46% 85 [get-dynamic-info.h:102 -> get-dynamic-info.h:111] ld-2.27.so ... 0.00% 92.7K 0.02% 4 [triad_loop.c:64 -> triad_loop.c:65] triad_loop The hottest block '[triad_loop.c:64 -> triad_loop.c:65]' is not at the top of output. After: # Sampled Cycles% Sampled Cycles Avg Cycles% Avg Cycles [Program Block Range] Shared Object # ............... .............. ........... .......... .............................................................. ................. # 94.35% 92.7K 0.02% 4 [triad_loop.c:64 -> triad_loop.c:65] triad_loop 0.81% 793 4.32% 793 [setup-vdso.h:34 -> setup-vdso.h:40] ld-2.27.so 0.49% 480 0.87% 160 [native_write_msr+0 -> native_write_msr+16] [kernel.kallsyms] 0.48% 476 0.52% 95 [native_read_msr+0 -> native_read_msr+29] [kernel.kallsyms] 0.31% 303 1.65% 303 [nmi_restore+0 -> nmi_restore+37] [kernel.kallsyms] 0.26% 255 1.39% 255 [nohz_balance_exit_idle+75 -> nohz_balance_exit_idle+162] [kernel.kallsyms] 0.24% 234 1.28% 234 [end_repeat_nmi+67 -> end_repeat_nmi+83] [kernel.kallsyms] 0.23% 227 1.24% 227 [__irqentry_text_end+96 -> __irqentry_text_end+126] [kernel.kallsyms] 0.20% 194 1.06% 194 [native_set_debugreg+52 -> native_set_debugreg+56] [kernel.kallsyms] 0.11% 106 0.14% 26 [native_sched_clock+0 -> native_sched_clock+98] [kernel.kallsyms] 0.10% 97 0.53% 97 [trigger_load_balance+0 -> trigger_load_balance+67] [kernel.kallsyms] 0.09% 85 0.46% 85 [get-dynamic-info.h:102 -> get-dynamic-info.h:111] ld-2.27.so 0.08% 82 0.06% 11 [intel_pmu_drain_pebs_nhm+580 -> intel_pmu_drain_pebs_nhm+627] [kernel.kallsyms] 0.08% 77 0.42% 77 [lru_add_drain_cpu+0 -> lru_add_drain_cpu+133] [kernel.kallsyms] 0.08% 74 0.10% 18 [handle_pmi_common+271 -> handle_pmi_common+310] [kernel.kallsyms] 0.08% 74 0.40% 74 [get-dynamic-info.h:131 -> get-dynamic-info.h:157] ld-2.27.so 0.07% 69 0.09% 17 [intel_pmu_drain_pebs_nhm+432 -> intel_pmu_drain_pebs_nhm+468] [kernel.kallsyms] Now the hottest block is reported at the top of output. Fixes: b65a7d372b1a55db ("perf hist: Support block formats with compare/sort/display") Signed-off-by: Jin Yao <yao.jin@linux.intel.com> Reviewed-by: Andi Kleen <ak@linux.intel.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Jin Yao <yao.jin@intel.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Kan Liang <kan.liang@linux.intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20210407024452.29988-1-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> 07 April 2021, 19:18:49 UTC
5de61a4 Mike Marciniszyn 29 March 2021, 13:48:19 UTC IB/hfi1: Fix probe time panic when AIP is enabled with a buggy BIOS A panic can result when AIP is enabled: BUG: unable to handle kernel NULL pointer dereference at 000000000000000 PGD 0 P4D 0 Oops: 0000 1 SMP PTI CPU: 70 PID: 981 Comm: systemd-udevd Tainted: G OE --------- - - 4.18.0-240.el8.x86_64 #1 Hardware name: Intel Corporation S2600KP/S2600KP, BIOS SE5C610.86B.01.01.0005.101720141054 10/17/2014 RIP: 0010:__bitmap_and+0x1b/0x70 RSP: 0018:ffff99aa0845f9f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8d5a6fc18000 RCX: 0000000000000048 RDX: 0000000000000000 RSI: ffffffffc06336f0 RDI: ffff8d5a8fa67750 RBP: 0000000000000079 R08: 0000000fffffffff R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffffffffc06336f0 R13: 00000000000000a0 R14: ffff8d5a6fc18000 R15: 0000000000000003 FS: 00007fec137a5980(0000) GS:ffff8d5a9fa80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000a04b48002 CR4: 00000000001606e0 Call Trace: hfi1_num_netdev_contexts+0x7c/0x110 [hfi1] hfi1_init_dd+0xd7f/0x1a90 [hfi1] ? pci_bus_read_config_dword+0x49/0x70 ? pci_mmcfg_read+0x3e/0xe0 do_init_one.isra.18+0x336/0x640 [hfi1] local_pci_probe+0x41/0x90 pci_device_probe+0x105/0x1c0 really_probe+0x212/0x440 driver_probe_device+0x49/0xc0 device_driver_attach+0x50/0x60 __driver_attach+0x61/0x130 ? device_driver_attach+0x60/0x60 bus_for_each_dev+0x77/0xc0 ? klist_add_tail+0x3b/0x70 bus_add_driver+0x14d/0x1e0 ? dev_init+0x10b/0x10b [hfi1] driver_register+0x6b/0xb0 ? dev_init+0x10b/0x10b [hfi1] hfi1_mod_init+0x1e6/0x20a [hfi1] do_one_initcall+0x46/0x1c3 ? free_unref_page_commit+0x91/0x100 ? _cond_resched+0x15/0x30 ? kmem_cache_alloc_trace+0x140/0x1c0 do_init_module+0x5a/0x220 load_module+0x14b4/0x17e0 ? __do_sys_finit_module+0xa8/0x110 __do_sys_finit_module+0xa8/0x110 do_syscall_64+0x5b/0x1a0 The issue happens when pcibus_to_node() returns NO_NUMA_NODE. Fix this issue by moving the initialization of dd->node to hfi1_devdata allocation and remove the other pcibus_to_node() calls in the probe path and use dd->node instead. Affinity logic is adjusted to use a new field dd->affinity_entry as a guard instead of dd->node. Fixes: 4730f4a6c6b2 ("IB/hfi1: Activate the dummy netdev") Link: https://lore.kernel.org/r/1617025700-31865-4-git-send-email-dennis.dalessandro@cornelisnetworks.com Cc: stable@vger.kernel.org Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 07 April 2021, 18:31:59 UTC
603c469 Potnuri Bharat Teja 31 March 2021, 13:57:15 UTC RDMA/cxgb4: check for ipv6 address properly while destroying listener ipv6 bit is wrongly set by the below which causes fatal adapter lookup engine errors for ipv4 connections while destroying a listener. Fix it to properly check the local address for ipv6. Fixes: 3408be145a5d ("RDMA/cxgb4: Fix adapter LE hash errors while destroying ipv6 listening server") Link: https://lore.kernel.org/r/20210331135715.30072-1-bharat@chelsio.com Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> 07 April 2021, 18:31:45 UTC
649cab5 Frank Rowand 05 April 2021, 03:28:45 UTC of: properly check for error returned by fdt_get_name() fdt_get_name() returns error values via a parameter pointer instead of in function return. Fix check for this error value in populate_node() and callers of populate_node(). Chasing up the caller tree showed callers of various functions failing to initialize the value of pointer parameters that can return error values. Initialize those values to NULL. The bug was introduced by commit e6a6928c3ea1 ("of/fdt: Convert FDT functions to use libfdt") but this patch can not be backported directly to that commit because the relevant code has further been restructured by commit dfbd4c6eff35 ("drivers/of: Split unflatten_dt_node()") The bug became visible by triggering a crash on openrisc with: commit 79edff12060f ("scripts/dtc: Update to upstream version v1.6.0-51-g183df9e9c2b9") as reported in: https://lore.kernel.org/lkml/20210327224116.69309-1-linux@roeck-us.net/ Fixes: 79edff12060f ("scripts/dtc: Update to upstream version v1.6.0-51-g183df9e9c2b9") Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Frank Rowand <frank.rowand@sony.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20210405032845.1942533-1-frowand.list@gmail.com Signed-off-by: Rob Herring <robh@kernel.org> 07 April 2021, 18:07:30 UTC
fa26d0c Vitaly Kuznetsov 06 April 2021, 15:56:40 UTC ACPI: processor: Fix build when CONFIG_ACPI_PROCESSOR=m Commit 8cdddd182bd7 ("ACPI: processor: Fix CPU0 wakeup in acpi_idle_play_dead()") tried to fix CPU0 hotplug breakage by copying wakeup_cpu0() + start_cpu0() logic from hlt_play_dead()//mwait_play_dead() into acpi_idle_play_dead(). The problem is that these functions are not exported to modules so when CONFIG_ACPI_PROCESSOR=m build fails. The issue could've been fixed by exporting both wakeup_cpu0()/start_cpu0() (the later from assembly) but it seems putting the whole pattern into a new function and exporting it instead is better. Reported-by: kernel test robot <lkp@intel.com> Fixes: 8cdddd182bd7 ("CPI: processor: Fix CPU0 wakeup in acpi_idle_play_dead()") Cc: <stable@vger.kernel.org> # 5.10+ Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 07 April 2021, 17:02:43 UTC
3a22981 Linus Torvalds 07 April 2021, 16:26:50 UTC Merge tag 'arm-fixes-5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "Most of the changes again are devicetree fixes, but there are also five trivial build fixes for issues I found when test building with gcc-11 or when running 'make W=1', and some OMAP platform specific code fixups. Broadcom: - One revert for a Raspberry pi interrupt controller change that caused a regression. TI OMAP: - Remove unused duplicate sha2md5_fck clock node that can race with the OMAP4_SHA2MD5_CLKCTRL clock node for disable for unused clocks - Add aliases for omap4/5 mmc to put the slots back into the right order again - Fix typo for bionic voltage controllers that accidentally use mpu for all instances instead of mpu, core and iva - Fix random hangs for droid4 caused by missing fix from TI Android kernel tree to do a dummy smc call on cpuidle wakeup path NXP i.MX: - Fix a system failure on imx6qdl-phytec-pfla02 board when booting from SD, by adding missing vmmc supply for SD interfaces. - Fix address typo in i.MX8MM/Q IOMUXC_SD1_DATA0_GPIO2_IO2 definition. Marvell mvebu: - Fix storm interrupt on Turris Omnia - Enable hardware buffer management as it should be ... and build fixes for PXA, Freescale, Marvell, OMAP1 and Keystone" * tag 'arm-fixes-5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin ARM: dts: turris-omnia: fix hardware buffer management Revert "arm64: dts: marvell: armada-cp110: Switch to per-port SATA interrupts" ARM: mvebu: avoid clang -Wtautological-constant warning ARM: pxa: mainstone: avoid -Woverride-init warning ARM: omap1: fix building with clang IAS soc/fsl: qbman: fix conflicting alignment attributes ARM: keystone: fix integer overflow warning ARM: dts: imx6: pbab01: Set vmmc supply for both SD interfaces arm64: dts: imx8mm/q: Fix pad control of SD1_DATA0 ARM: OMAP4: PM: update ROM return address for OSWR and OFF ARM: OMAP4: Fix PMIC voltage domains for bionic ARM: dts: Fix moving mmc devices with aliases for omap4 & 5 ARM: dts: Drop duplicate sha2md5_fck to fix clk_disable race Revert "ARM: dts: bcm2711: Add the BSC interrupt controller" 07 April 2021, 16:26:50 UTC
dbaa5d1 Linus Torvalds 07 April 2021, 16:20:07 UTC Merge branch 'parisc-5.12-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: "One link error fix found by the kernel test robot, one sparse warning fix, remove a duplicate declaration and some spelling fixes" * 'parisc-5.12-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: math-emu: Few spelling fixes in the file fpu.h parisc: avoid a warning on u8 cast for cmpxchg on u8 pointers parisc: parisc-agp requires SBA IOMMU driver parisc: Remove duplicate struct task_struct declaration 07 April 2021, 16:20:07 UTC
5ba091d Linus Torvalds 07 April 2021, 16:14:04 UTC Merge tag 'platform-drivers-x86-v5.12-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver fix from Hans de Goede: "A single bugfix to fix spurious wakeups from suspend caused by recent intel-hid driver changes" * tag 'platform-drivers-x86-v5.12-3' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: platform/x86: intel-hid: Fix spurious wakeups caused by tablet-mode events during suspend 07 April 2021, 16:14:04 UTC
e3bb2f4 Linus Torvalds 07 April 2021, 16:08:36 UTC Merge tag 'regulator-fix-v5.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "bd9571mwv regulator fixes for v5.12. A set of driver specific fixes here, the main one is a fix to not try to set unsupported voltages on this device. The other two patches clean up the error handling and eliminate the possibility that we could overflow the page when writing sysfs output (which AFAICT wasn't an issue but better to be sure)" * tag 'regulator-fix-v5.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: bd9571mwv: Convert device attribute to sysfs_emit() regulator: bd9571mwv: Fix regulator name printed on registration failure regulator: bd9571mwv: Fix AVS and DVFS voltage range 07 April 2021, 16:08:36 UTC
d120198 Luca Fancellu 06 April 2021, 10:51:04 UTC xen/evtchn: Change irq_info lock to raw_spinlock_t Unmask operation must be called with interrupt disabled, on preempt_rt spin_lock_irqsave/spin_unlock_irqrestore don't disable/enable interrupts, so use raw_* implementation and change lock variable in struct irq_info from spinlock_t to raw_spinlock_t Cc: stable@vger.kernel.org Fixes: 25da4618af24 ("xen/events: don't unmask an event channel when an eoi is pending") Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Wei Liu <wei.liu@kernel.org> Link: https://lore.kernel.org/r/20210406105105.10141-1-luca.fancellu@arm.com Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> 07 April 2021, 13:33:28 UTC
9c31957 Takashi Iwai 07 April 2021, 13:00:33 UTC Merge tag 'asoc-fix-v5.12-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.12 A fairly small batch of driver specific fixes, mainly for various x86 systems with the biggest set being fixes to power down DSPs properly on x86 SOF systems. 07 April 2021, 13:00:33 UTC
ad31a8c Heiko Carstens 05 April 2021, 20:32:27 UTC s390/setup: use memblock_free_late() to free old stack Use memblock_free_late() to free the old machine check stack to the buddy allocator instead of leaking it. Fixes: b61b1595124a ("s390: add stack for machine check handler") Cc: Vasily Gorbik <gor@linux.ibm.com> Acked-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> 07 April 2021, 12:37:28 UTC
3a62583 William Roche 06 April 2021, 15:28:59 UTC RAS/CEC: Correct ce_add_elem()'s returned values ce_add_elem() uses different return values to signal a result from adding an element to the collector. Commit in Fixes: broke the case where the element being added is not found in the array. Correct that. [ bp: Rewrite commit message, add kernel-doc comments. ] Fixes: de0e0624d86f ("RAS/CEC: Check count_threshold unconditionally") Signed-off-by: William Roche <william.roche@oracle.com> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/1617722939-29670-1-git-send-email-william.roche@oracle.com 07 April 2021, 09:52:26 UTC
168632a Jonas Holmberg 07 April 2021, 07:54:28 UTC ALSA: aloop: Fix initialization of controls Add a control to the card before copying the id so that the numid field is initialized in the copy. Otherwise the numid field of active_id, format_id, rate_id and channels_id will be the same (0) and snd_ctl_notify() will not queue the events properly. Signed-off-by: Jonas Holmberg <jonashg@axis.com> Reviewed-by: Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210407075428.2666787-1-jonashg@axis.com Signed-off-by: Takashi Iwai <tiwai@suse.de> 07 April 2021, 08:21:25 UTC
d5f9b00 Xiaoming Ni 05 April 2021, 02:53:39 UTC net/mlx5: fix kfree mismatch in indir_table.c Memory allocated by kvzalloc() should be freed by kvfree(). Fixes: 34ca65352ddf2 ("net/mlx5: E-Switch, Indirect table infrastructur") Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> 07 April 2021, 04:04:36 UTC
534b120 Aya Levin 04 April 2021, 09:55:00 UTC net/mlx5: Fix PBMC register mapping Add reserved mapping to cover all the register in order to avoid setting arbitrary values to newer FW which implements the reserved fields. Fixes: 50b4a3c23646 ("net/mlx5: PPTB and PBMC register firmware command support") Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> 07 April 2021, 04:04:36 UTC
ce28f0f Aya Levin 04 April 2021, 07:50:50 UTC net/mlx5: Fix PPLM register mapping Add reserved mapping to cover all the register in order to avoid setting arbitrary values to newer FW which implements the reserved fields. Fixes: a58837f52d43 ("net/mlx5e: Expose FEC feilds and related capability bit") Signed-off-by: Aya Levin <ayal@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> 07 April 2021, 04:04:35 UTC
a14587d Raed Salem 21 January 2021, 14:01:37 UTC net/mlx5: Fix placement of log_max_flow_counter The cited commit wrongly placed log_max_flow_counter field of mlx5_ifc_flow_table_prop_layout_bits, align it to the HW spec intended placement. Fixes: 16f1c5bb3ed7 ("net/mlx5: Check device capability for maximum flow counters") Signed-off-by: Raed Salem <raeds@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> 07 April 2021, 04:04:35 UTC
1a73704 Eli Cohen 24 March 2021, 07:46:09 UTC net/mlx5: Fix HW spec violation configuring uplink Make sure to modify uplink port to follow only if the uplink_follow capability is set as required by the HW spec. Failure to do so causes traffic to the uplink representor net device to cease after switching to switchdev mode. Fixes: 7d0314b11cdd ("net/mlx5e: Modify uplink state on interface up/down") Signed-off-by: Eli Cohen <elic@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> 07 April 2021, 04:04:35 UTC
4f0ed93 Al Viro 06 April 2021, 23:46:51 UTC LOOKUP_MOUNTPOINT: we are cleaning "jumped" flag too late That (and traversals in case of umount .) should be done before complete_walk(). Either a braino or mismerge damage on queue reorders - either way, I should've spotted that much earlier. Fucked-up-by: Al Viro <viro@zeniv.linux.org.uk> X-Paperbag: Brown Fixes: 161aff1d93ab "LOOKUP_MOUNTPOINT: fold path_mountpointat() into path_lookupat()" Cc: stable@vger.kernel.org # v5.7+ Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 07 April 2021, 00:33:00 UTC
5219d60 Jakub Kicinski 06 April 2021, 22:58:15 UTC docs: ethtool: fix some copy-paste errors Fix incorrect documentation. Mostly referring to other objects, likely because the text was copied and not adjusted. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net> 06 April 2021, 23:55:41 UTC
cca8ea3 Phillip Potter 06 April 2021, 17:45:54 UTC net: tun: set tun->dev->addr_len during TUNSETLINK processing When changing type with TUNSETLINK ioctl command, set tun->dev->addr_len to match the appropriate type, using new tun_get_addr_len utility function which returns appropriate address length for given type. Fixes a KMSAN-found uninit-value bug reported by syzbot at: https://syzkaller.appspot.com/bug?id=0766d38c656abeace60621896d705743aeefed51 Reported-by: syzbot+001516d86dbe88862cec@syzkaller.appspotmail.com Diagnosed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Phillip Potter <phil@philpotter.co.uk> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> 06 April 2021, 23:52:21 UTC
63cf323 Wong Vee Khee 06 April 2021, 13:17:30 UTC ethtool: fix incorrect datatype in set_eee ops The member 'tx_lpi_timer' is defined with __u32 datatype in the ethtool header file. Hence, we should use ethnl_update_u32() in set_eee ops. Fixes: fd77be7bd43c ("ethtool: set EEE settings with EEE_SET request") Cc: <stable@vger.kernel.org> # 5.10.x Cc: Michal Kubecek <mkubecek@suse.cz> Signed-off-by: Wong Vee Khee <vee.khee.wong@linux.intel.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Michal Kubecek <mkubecek@suse.cz> Signed-off-by: David S. Miller <davem@davemloft.net> 06 April 2021, 23:42:25 UTC
ed7bedd Guangbin Huang 06 April 2021, 13:10:43 UTC net: hns3: clear VF down state bit before request link status Currently, the VF down state bit is cleared after VF sending link status request command. There is problem that when VF gets link status replied from PF, the down state bit may still set as 1. In this case, the link status replied from PF will be ignored and always set VF link status to down. To fix this problem, clear VF down state bit before VF requests link status. Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> 06 April 2021, 23:40:06 UTC
f57796a David S. Miller 06 April 2021, 23:34:11 UTC Merge tag 'linux-can-fixes-for-5.12-20210406' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2021-04-06 this is a pull request of 1 patch for net/master. The patch is by me and fixes the SPI half duplex support in the mcp251x CAN driver. ==================== Signed-off-by: David S. Miller <davem@davemloft.net> 06 April 2021, 23:34:11 UTC
66c3f05 Guenter Roeck 06 April 2021, 04:29:22 UTC pcnet32: Use pci_resource_len to validate PCI resource pci_resource_start() is not a good indicator to determine if a PCI resource exists or not, since the resource may start at address 0. This is seen when trying to instantiate the driver in qemu for riscv32 or riscv64. pci 0000:00:01.0: reg 0x10: [io 0x0000-0x001f] pci 0000:00:01.0: reg 0x14: [mem 0x00000000-0x0000001f] ... pcnet32: card has no PCI IO resources, aborting Use pci_resouce_len() instead. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: David S. Miller <davem@davemloft.net> 06 April 2021, 23:30:17 UTC
144748e John Fastabend 01 April 2021, 22:00:40 UTC bpf, sockmap: Fix incorrect fwd_alloc accounting Incorrect accounting fwd_alloc can result in a warning when the socket is torn down, [18455.319240] WARNING: CPU: 0 PID: 24075 at net/core/stream.c:208 sk_stream_kill_queues+0x21f/0x230 [...] [18455.319543] Call Trace: [18455.319556] inet_csk_destroy_sock+0xba/0x1f0 [18455.319577] tcp_rcv_state_process+0x1b4e/0x2380 [18455.319593] ? lock_downgrade+0x3a0/0x3a0 [18455.319617] ? tcp_finish_connect+0x1e0/0x1e0 [18455.319631] ? sk_reset_timer+0x15/0x70 [18455.319646] ? tcp_schedule_loss_probe+0x1b2/0x240 [18455.319663] ? lock_release+0xb2/0x3f0 [18455.319676] ? __release_sock+0x8a/0x1b0 [18455.319690] ? lock_downgrade+0x3a0/0x3a0 [18455.319704] ? lock_release+0x3f0/0x3f0 [18455.319717] ? __tcp_close+0x2c6/0x790 [18455.319736] ? tcp_v4_do_rcv+0x168/0x370 [18455.319750] tcp_v4_do_rcv+0x168/0x370 [18455.319767] __release_sock+0xbc/0x1b0 [18455.319785] __tcp_close+0x2ee/0x790 [18455.319805] tcp_close+0x20/0x80 This currently happens because on redirect case we do skb_set_owner_r() with the original sock. This increments the fwd_alloc memory accounting on the original sock. Then on redirect we may push this into the queue of the psock we are redirecting to. When the skb is flushed from the queue we give the memory back to the original sock. The problem is if the original sock is destroyed/closed with skbs on another psocks queue then the original sock will not have a way to reclaim the memory before being destroyed. Then above warning will be thrown sockA sockB sk_psock_strp_read() sk_psock_verdict_apply() -- SK_REDIRECT -- sk_psock_skb_redirect() skb_queue_tail(psock_other->ingress_skb..) sk_close() sock_map_unref() sk_psock_put() sk_psock_drop() sk_psock_zap_ingress() At this point we have torn down our own psock, but have the outstanding skb in psock_other. Note that SK_PASS doesn't have this problem because the sk_psock_drop() logic releases the skb, its still associated with our psock. To resolve lets only account for sockets on the ingress queue that are still associated with the current socket. On the redirect case we will check memory limits per 6fa9201a89898, but will omit fwd_alloc accounting until skb is actually enqueued. When the skb is sent via skb_send_sock_locked or received with sk_psock_skb_ingress memory will be claimed on psock_other. Fixes: 6fa9201a89898 ("bpf, sockmap: Avoid returning unneeded EAGAIN when redirecting to self") Reported-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/161731444013.68884.4021114312848535993.stgit@john-XPS-13-9370 06 April 2021, 23:29:06 UTC
1c84b33 John Fastabend 01 April 2021, 22:00:19 UTC bpf, sockmap: Fix sk->prot unhash op reset In '4da6a196f93b1' we fixed a potential unhash loop caused when a TLS socket in a sockmap was removed from the sockmap. This happened because the unhash operation on the TLS ctx continued to point at the sockmap implementation of unhash even though the psock has already been removed. The sockmap unhash handler when a psock is removed does the following, void sock_map_unhash(struct sock *sk) { void (*saved_unhash)(struct sock *sk); struct sk_psock *psock; rcu_read_lock(); psock = sk_psock(sk); if (unlikely(!psock)) { rcu_read_unlock(); if (sk->sk_prot->unhash) sk->sk_prot->unhash(sk); return; } [...] } The unlikely() case is there to handle the case where psock is detached but the proto ops have not been updated yet. But, in the above case with TLS and removed psock we never fixed sk_prot->unhash() and unhash() points back to sock_map_unhash resulting in a loop. To fix this we added this bit of code, static inline void sk_psock_restore_proto(struct sock *sk, struct sk_psock *psock) { sk->sk_prot->unhash = psock->saved_unhash; This will set the sk_prot->unhash back to its saved value. This is the correct callback for a TLS socket that has been removed from the sock_map. Unfortunately, this also overwrites the unhash pointer for all psocks. We effectively break sockmap unhash handling for any future socks. Omitting the unhash operation will leave stale entries in the map if a socket transition through unhash, but does not do close() op. To fix set unhash correctly before calling into tls_update. This way the TLS enabled socket will point to the saved unhash() handler. Fixes: 4da6a196f93b1 ("bpf: Sockmap/tls, during free we may call tcp_bpf_unhash() in loop") Reported-by: Cong Wang <xiyou.wangcong@gmail.com> Reported-by: Lorenz Bauer <lmb@cloudflare.com> Suggested-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/161731441904.68884.15593917809745631972.stgit@john-XPS-13-9370 06 April 2021, 23:29:06 UTC
2a2403c Xin Long 06 April 2021, 02:45:23 UTC tipc: increment the tmp aead refcnt before attaching it Li Shuang found a NULL pointer dereference crash in her testing: [] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [] RIP: 0010:tipc_crypto_rcv_complete+0xc8/0x7e0 [tipc] [] Call Trace: [] <IRQ> [] tipc_crypto_rcv+0x2d9/0x8f0 [tipc] [] tipc_rcv+0x2fc/0x1120 [tipc] [] tipc_udp_recv+0xc6/0x1e0 [tipc] [] udpv6_queue_rcv_one_skb+0x16a/0x460 [] udp6_unicast_rcv_skb.isra.35+0x41/0xa0 [] ip6_protocol_deliver_rcu+0x23b/0x4c0 [] ip6_input+0x3d/0xb0 [] ipv6_rcv+0x395/0x510 [] __netif_receive_skb_core+0x5fc/0xc40 This is caused by NULL returned by tipc_aead_get(), and then crashed when dereferencing it later in tipc_crypto_rcv_complete(). This might happen when tipc_crypto_rcv_complete() is called by two threads at the same time: the tmp attached by tipc_crypto_key_attach() in one thread may be released by the one attached by that in the other thread. This patch is to fix it by incrementing the tmp's refcnt before attaching it instead of calling tipc_aead_get() after attaching it. Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Reported-by: Li Shuang <shuali@redhat.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> 06 April 2021, 23:25:34 UTC
0f6925b Eric Dumazet 02 April 2021, 13:26:02 UTC virtio_net: Do not pull payload in skb->head Xuan Zhuo reported that commit 3226b158e67c ("net: avoid 32 x truesize under-estimation for tiny skbs") brought a ~10% performance drop. The reason for the performance drop was that GRO was forced to chain sk_buff (using skb_shinfo(skb)->frag_list), which uses more memory but also cause packet consumers to go over a lot of overhead handling all the tiny skbs. It turns out that virtio_net page_to_skb() has a wrong strategy : It allocates skbs with GOOD_COPY_LEN (128) bytes in skb->head, then copies 128 bytes from the page, before feeding the packet to GRO stack. This was suboptimal before commit 3226b158e67c ("net: avoid 32 x truesize under-estimation for tiny skbs") because GRO was using 2 frags per MSS, meaning we were not packing MSS with 100% efficiency. Fix is to pull only the ethernet header in page_to_skb() Then, we change virtio_net_hdr_to_skb() to pull the missing headers, instead of assuming they were already pulled by callers. This fixes the performance regression, but could also allow virtio_net to accept packets with more than 128bytes of headers. Many thanks to Xuan Zhuo for his report, and his tests/help. Fixes: 3226b158e67c ("net: avoid 32 x truesize under-estimation for tiny skbs") Reported-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Link: https://www.spinics.net/lists/netdev/msg731397.html Co-Developed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Signed-off-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: virtualization@lists.linux-foundation.org Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> 06 April 2021, 23:17:57 UTC
b25b343 Lv Yunlong 02 April 2021, 17:40:19 UTC net: broadcom: bcm4908enet: Fix a double free in bcm4908_enet_dma_alloc In bcm4908_enet_dma_alloc, if callee bcm4908_dma_alloc_buf_descs() failed, it will free the ring->cpu_addr by dma_free_coherent() and return error. Then bcm4908_enet_dma_free() will be called, and free the same cpu_addr by dma_free_coherent() again. My patch set ring->cpu_addr to NULL after it is freed in bcm4908_dma_alloc_buf_descs() to avoid the double free. Fixes: 4feffeadbcb2e ("net: broadcom: bcm4908enet: add BCM4908 controller driver") Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn> Signed-off-by: David S. Miller <davem@davemloft.net> 06 April 2021, 23:15:21 UTC
1180042 Arnd Bergmann 03 April 2021, 19:57:53 UTC Merge tag 'mvebu-fixes-5.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/fixes mvebu fixes for 5.12 (part 1) 2 fixes on on turris-omnia (Armada 38x based:) - Fix storm interrupt - Enable hardware buffer management as it should be Unbreak AHCI on all Marvell Armada 7k8k / CN913x platforms * tag 'mvebu-fixes-5.12-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu: ARM: dts: turris-omnia: configure LED[2]/INTn pin as interrupt pin ARM: dts: turris-omnia: fix hardware buffer management Revert "arm64: dts: marvell: armada-cp110: Switch to per-port SATA interrupts" Link: https://lore.kernel.org/r/87a6qgctit.fsf@BL-laptop Signed-off-by: Arnd Bergmann <arnd@arndb.de> 06 April 2021, 21:21:08 UTC
1165aff Pavel Skripkin 04 March 2021, 15:21:25 UTC net: mac802154: Fix general protection fault syzbot found general protection fault in crypto_destroy_tfm()[1]. It was caused by wrong clean up loop in llsec_key_alloc(). If one of the tfm array members is in IS_ERR() range it will cause general protection fault in clean up function [1]. Call Trace: crypto_free_aead include/crypto/aead.h:191 [inline] [1] llsec_key_alloc net/mac802154/llsec.c:156 [inline] mac802154_llsec_key_add+0x9e0/0xcc0 net/mac802154/llsec.c:249 ieee802154_add_llsec_key+0x56/0x80 net/mac802154/cfg.c:338 rdev_add_llsec_key net/ieee802154/rdev-ops.h:260 [inline] nl802154_add_llsec_key+0x3d3/0x560 net/ieee802154/nl802154.c:1584 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:800 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2502 genl_rcv+0x24/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Reported-by: syzbot+9ec037722d2603a9f52e@syzkaller.appspotmail.com Acked-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210304152125.1052825-1-paskripkin@gmail.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:42:16 UTC
1534efc Alexander Aring 05 April 2021, 00:30:54 UTC net: ieee802154: stop dump llsec params for monitors This patch stops dumping llsec params for monitors which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Reported-by: syzbot+cde43a581a8e5f317bc2@syzkaller.appspotmail.com Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-16-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:34:38 UTC
9dde130 Alexander Aring 05 April 2021, 00:30:53 UTC net: ieee802154: forbid monitor for del llsec seclevel This patch forbids to del llsec seclevel for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Reported-by: syzbot+fbf4fc11a819824e027b@syzkaller.appspotmail.com Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-15-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:32:52 UTC
56b4c65 Krzysztof Kozlowski 05 April 2021, 18:14:05 UTC i2c: exynos5: correct top kerneldoc The top comment is not a kerneldoc, as W=1 build reports: drivers/i2c/busses/i2c-exynos5.c:39: warning: expecting prototype for i2c(). Prototype was for HSI2C_CTL() instead Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> 06 April 2021, 20:32:33 UTC
9ec87e3 Alexander Aring 05 April 2021, 00:30:52 UTC net: ieee802154: forbid monitor for add llsec seclevel This patch forbids to add llsec seclevel for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-14-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:30:50 UTC
4c9b4f5 Alexander Aring 05 April 2021, 00:30:51 UTC net: ieee802154: stop dump llsec seclevels for monitors This patch stops dumping llsec seclevels for monitors which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-13-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:28:34 UTC
6fb8045 Alexander Aring 05 April 2021, 00:30:50 UTC net: ieee802154: forbid monitor for del llsec devkey This patch forbids to del llsec devkey for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-12-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:26:29 UTC
a347b3b Alexander Aring 05 April 2021, 00:30:49 UTC net: ieee802154: forbid monitor for add llsec devkey This patch forbids to add llsec devkey for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-11-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:24:08 UTC
080d1a5 Alexander Aring 05 April 2021, 00:30:48 UTC net: ieee802154: stop dump llsec devkeys for monitors This patch stops dumping llsec devkeys for monitors which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-10-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:21:16 UTC
ad8f9de Alexander Aring 05 April 2021, 00:30:47 UTC net: ieee802154: forbid monitor for del llsec dev This patch forbids to del llsec dev for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-9-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:19:10 UTC
5303f95 Alexander Aring 05 April 2021, 00:30:46 UTC net: ieee802154: forbid monitor for add llsec dev This patch forbids to add llsec dev for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-8-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:12:41 UTC
a3790a8 Hans de Goede 04 April 2021, 14:38:31 UTC platform/x86: intel-hid: Fix spurious wakeups caused by tablet-mode events during suspend Some devices send (duplicate) tablet-mode events when moved around even though the mode has not changed; and they do this even when suspended. Change the tablet-mode event handling when priv->wakeup_mode is set to update the switch state in case it changed and then return immediately (without calling pm_wakeup_hard_event()) to avoid spurious wakeups. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212537 Fixes: 537b0dd4729e ("platform/x86: intel-hid: Add support for SW_TABLET_MODE") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Elia Devito <eliadevito@gmail.com> Link: https://lore.kernel.org/r/20210404143831.25173-1-hdegoede@redhat.com 06 April 2021, 20:10:21 UTC
5582d64 Alexander Aring 05 April 2021, 00:30:45 UTC net: ieee802154: stop dump llsec devs for monitors This patch stops dumping llsec devs for monitors which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-7-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:10:09 UTC
b6e2949 Alexander Aring 05 April 2021, 00:30:44 UTC net: ieee802154: forbid monitor for del llsec key This patch forbids to del llsec key for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-6-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:07:31 UTC
08470c5 Alexander Aring 05 April 2021, 00:30:43 UTC net: ieee802154: forbid monitor for add llsec key This patch forbids to add llsec key for monitor interfaces which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-5-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:03:16 UTC
fb3c5cd Alexander Aring 05 April 2021, 00:30:42 UTC net: ieee802154: stop dump llsec keys for monitors This patch stops dumping llsec keys for monitors which we don't support yet. Otherwise we will access llsec mib which isn't initialized for monitors. Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-4-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 20:00:50 UTC
88c1785 Alexander Aring 05 April 2021, 00:30:41 UTC net: ieee802154: forbid monitor for set llsec params This patch forbids to set llsec params for monitor interfaces which we don't support yet. Reported-by: syzbot+8b6719da8a04beeafcc3@syzkaller.appspotmail.com Signed-off-by: Alexander Aring <aahringo@redhat.com> Link: https://lore.kernel.org/r/20210405003054.256017-3-aahringo@redhat.com Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> 06 April 2021, 19:57:29 UTC
2d74366 Linus Torvalds 06 April 2021, 19:52:49 UTC Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull fs fixes from Al Viro: "Fairly old hostfs bug (in setups that are not used by anyone, apparently) + fix for this cycle regression: extra dput/mntput in LOOKUP_CACHED failure handling" * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: Make sure nd->path.mnt and nd->path.dentry are always valid pointers hostfs: fix memory handling in follow_link() 06 April 2021, 19:52:49 UTC
7d01ef7 Al Viro 06 April 2021, 16:33:07 UTC Make sure nd->path.mnt and nd->path.dentry are always valid pointers Initialize them in set_nameidata() and make sure that terminate_walk() clears them once the pointers become potentially invalid (i.e. we leave RCU mode or drop them in non-RCU one). Currently we have "path_init() always initializes them and nobody accesses them outside of path_init()/terminate_walk() segments", which is asking for trouble. With that change we would have nd->path.{mnt,dentry} 1) always valid - NULL or pointing to currently allocated objects. 2) non-NULL while we are successfully walking 3) NULL when we are not walking at all 4) contributing to refcounts whenever non-NULL outside of RCU mode. Fixes: 6c6ec2b0a3e0 ("fs: add support for LOOKUP_CACHED") Reported-by: syzbot+c88a7030da47945a3cc3@syzkaller.appspotmail.com Tested-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 06 April 2021, 16:33:07 UTC
3b94336 Sebastian Reichel 27 February 2021, 21:45:42 UTC drm/panel: panel-dsi-cm: disable TE for now Disable TE for Droid 4 panel, since implementation is currently broken. Also disable it for N950 panel, which is untested. Reported-by: Tony Lindgren <tony@atomide.com> Reported-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Fixes: 4c1b935fea54 ("drm/omap: dsi: move TE GPIO handling into core") Signed-off-by: Sebastian Reichel <sre@kernel.org> Tested-by: Tony Lindgren <tony@atomide.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210227214542.99961-1-sebastian.reichel@collabora.com 06 April 2021, 13:51:29 UTC
0aa2ddc Bhaskar Chowdhury 17 March 2021, 19:24:27 UTC parisc: math-emu: Few spelling fixes in the file fpu.h with some additional cleanups by Helge. Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Helge Deller <deller@gmx.de> 06 April 2021, 13:34:14 UTC
4d752e5 Gao Xiang 06 April 2021, 04:59:29 UTC parisc: avoid a warning on u8 cast for cmpxchg on u8 pointers commit b344d6a83d01 ("parisc: add support for cmpxchg on u8 pointers") can generate a sparse warning ("cast truncates bits from constant value"), which has been reported several times [1] [2] [3]. The original code worked as expected, but anyway, let silence such sparse warning as what others did [4]. [1] https://lore.kernel.org/r/202104061220.nRMBwCXw-lkp@intel.com [2] https://lore.kernel.org/r/202012291914.T5Agcn99-lkp@intel.com [3] https://lore.kernel.org/r/202008210829.KVwn7Xeh%25lkp@intel.com [4] https://lore.kernel.org/r/20210315131512.133720-2-jacopo+renesas@jmondi.org Cc: Liam Beguin <liambeguin@gmail.com> Cc: Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # v5.8+ Signed-off-by: Gao Xiang <hsiangkao@redhat.com> Signed-off-by: Helge Deller <deller@gmx.de> 06 April 2021, 12:32:12 UTC
c6423ed Takashi Iwai 01 April 2021, 17:13:14 UTC ALSA: hda/conexant: Apply quirk for another HP ZBook G5 model There is another HP ZBook G5 model with the PCI SSID 103c:844f that requires the same quirk for controlling the mute LED. Add the corresponding entry to the quirk table. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212407 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20210401171314.667-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de> 06 April 2021, 11:40:13 UTC
617085f Marc Kleine-Budde 30 March 2021, 09:46:07 UTC can: mcp251x: fix support for half duplex SPI host controllers Some SPI host controllers do not support full-duplex SPI transfers. The function mcp251x_spi_trans() does a full duplex transfer. It is used in several places in the driver, where a TX half duplex transfer is sufficient. To fix support for half duplex SPI host controllers, this patch introduces a new function mcp251x_spi_write() and changes all callers that do a TX half duplex transfer to use mcp251x_spi_write(). Fixes: e0e25001d088 ("can: mcp251x: add support for half duplex controllers") Link: https://lore.kernel.org/r/20210330100246.1074375-1-mkl@pengutronix.de Cc: Tim Harvey <tharvey@gateworks.com> Tested-By: Tim Harvey <tharvey@gateworks.com> Reported-by: Gerhard Bertelsmann <info@gerhard-bertelsmann.de> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> 06 April 2021, 10:31:21 UTC
65db391 Johannes Berg 26 March 2021, 10:57:23 UTC iwlwifi: mvm: fix beacon protection checks Unfortunately, since beacon protection isn't fully available yet, we didn't notice that there are problems with it and that the replay detection isn't working correctly. We were relying only on mac80211, since iwl_mvm_rx_crypto() exits when !ieee80211_has_protected(), which is of course true for protected (but not encrypted) management frames. Fix this to properly detect protected (but not encrypted) management frames and handle them - we continue to only care about beacons since for others everything can and will be checked in mac80211. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: b1fdc2505abc ("iwlwifi: mvm: advertise BIGTK client support if available") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.23c990843369.I09c262a8f6f9852cc8f513cdcb31a7f8f87dd8af@changeid 06 April 2021, 10:26:36 UTC
39fb06f Gregory Greenman 26 March 2021, 10:57:22 UTC iwlwifi: mvm: rfi: don't lock mvm->mutex when sending config command The mutex is already locked in iwl_mvm_mac_start. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Fixes: 21254908cbe9 ("iwlwifi: mvm: add RFI-M support") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.703288ea058d.I82a0312389032d07c3b478bef3e938e06bfa7df6@changeid 06 April 2021, 10:26:25 UTC
08f4b0b Luca Coelho 26 March 2021, 10:57:21 UTC iwlwifi: pcie: add support for So-F devices We have a new type of device that has a different MAC ID, but is otherwise identical to So devices. Add rules to match this new ID accordingly. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.4feea3560def.I2b6ef794c2073a18779dd40fb53f8c942d1ab42d@changeid 06 April 2021, 10:26:12 UTC
9c04fd9 Johannes Berg 26 March 2021, 10:57:20 UTC iwlwifi: fw: fix notification wait locking Since we now call iwl_notification_wait_notify() from the NAPI poll in soft-IRQ, we get a (valid) lockdep complaint that we could get a deadlock by taking the spinlock from sleeping context and then getting the soft-IRQ that also tries to take it (in NAPI polling). Fix this by disabling soft-IRQs for this lock. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: 25edc8f259c7 ("iwlwifi: pcie: properly implement NAPI") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.c3b2e3d6b58b.Ic56f351d04674df70567bab0269cba91bdbc853c@changeid 06 April 2021, 10:25:59 UTC
97195d3 Matt Chen 26 March 2021, 10:57:19 UTC iwlwifi: add support for Qu with AX201 device Add this specific Samsung AX201 sku to driver so it can be detected and initialized successfully. Signed-off-by: Matt Chen <matt.chen@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.30b622037714.Id9fd709cf1c8261c097bbfd7453f6476077dcafc@changeid 06 April 2021, 10:25:54 UTC
25628bc Johannes Berg 26 March 2021, 10:57:18 UTC iwlwifi: pcie: properly set LTR workarounds on 22000 devices As the context info gen3 code is only called for >=AX210 devices (from iwl_trans_pcie_gen2_start_fw()) the code there to set LTR on 22000 devices cannot actually do anything (22000 < AX210). Fix this by moving the LTR code to iwl_trans_pcie_gen2_start_fw() where it can handle both devices. This then requires that we kick the firmware only after that rather than doing it from the context info code. Note that this again had a dead branch in gen3 code, which I've removed here. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: ed0022da8bd9 ("iwlwifi: pcie: set LTR on more devices") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.675486178ed1.Ib61463aba6920645059e366dcdca4c4c77f0ff58@changeid 06 April 2021, 10:25:53 UTC
07cc40f Luca Coelho 26 March 2021, 10:57:17 UTC iwlwifi: fix 11ax disabled bit in the regulatory capability flags When version 2 of the regulatory capability flags API was implemented, the flag to disable 11ax was defined as bit 13, but this was later changed and the bit remained as bit 10, like in version 1. This was never changed in the driver, so we were checking for the wrong bit in newer devices. Fix it. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Fixes: e27c506a985c ("iwlwifi: regulatory: regulatory capabilities api change") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/iwlwifi.20210326125611.6d28516b59cd.Id0248d5e4662695254f49ce37b0268834ed52918@changeid 06 April 2021, 10:25:45 UTC
9054284 Helge Deller 06 April 2021, 09:32:52 UTC parisc: parisc-agp requires SBA IOMMU driver Add a dependency to the SBA IOMMU driver to avoid: ERROR: modpost: "sba_list" [drivers/char/agp/parisc-agp.ko] undefined! Reported-by: kernel test robot <lkp@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Helge Deller <deller@gmx.de> 06 April 2021, 09:46:39 UTC
4033e76 Wan Jiabing 31 March 2021, 01:28:50 UTC parisc: Remove duplicate struct task_struct declaration struct task_struct is declared twice. One has been declared at 154th line. Remove the duplicate. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: Helge Deller <deller@gmx.de> 06 April 2021, 09:46:26 UTC
5cd0f6f Martin Wilck 01 April 2021, 09:11:05 UTC scsi: scsi_transport_srp: Don't block target in SRP_PORT_LOST state rport_dev_loss_timedout() sets the rport state to SRP_PORT_LOST and the SCSI target state to SDEV_TRANSPORT_OFFLINE. If this races with srp_reconnect_work(), a warning is printed: Mar 27 18:48:07 ictm1604s01h4 kernel: dev_loss_tmo expired for SRP port-18:1 / host18. Mar 27 18:48:07 ictm1604s01h4 kernel: ------------[ cut here ]------------ Mar 27 18:48:07 ictm1604s01h4 kernel: scsi_internal_device_block(18:0:0:100) failed: ret = -22 Mar 27 18:48:07 ictm1604s01h4 kernel: Call Trace: Mar 27 18:48:07 ictm1604s01h4 kernel: ? scsi_target_unblock+0x50/0x50 [scsi_mod] Mar 27 18:48:07 ictm1604s01h4 kernel: starget_for_each_device+0x80/0xb0 [scsi_mod] Mar 27 18:48:07 ictm1604s01h4 kernel: target_block+0x24/0x30 [scsi_mod] Mar 27 18:48:07 ictm1604s01h4 kernel: device_for_each_child+0x57/0x90 Mar 27 18:48:07 ictm1604s01h4 kernel: srp_reconnect_rport+0xe4/0x230 [scsi_transport_srp] Mar 27 18:48:07 ictm1604s01h4 kernel: srp_reconnect_work+0x40/0xc0 [scsi_transport_srp] Avoid this by not trying to block targets for rports in SRP_PORT_LOST state. Link: https://lore.kernel.org/r/20210401091105.8046-1-mwilck@suse.com Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin Wilck <mwilck@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> 06 April 2021, 03:14:53 UTC
0352c3d Roman Bolshakov 03 April 2021, 21:54:15 UTC scsi: target: iscsi: Fix zero tag inside a trace event target_sequencer_start event is triggered inside target_cmd_init_cdb(). se_cmd.tag is not initialized with ITT at the moment so the event always prints zero tag. Link: https://lore.kernel.org/r/20210403215415.95077-1-r.bolshakov@yadro.com Cc: stable@vger.kernel.org # 5.10+ Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> 06 April 2021, 03:09:37 UTC
65df7d1 Viswas G 02 April 2021, 05:42:12 UTC scsi: pm80xx: Fix chip initialization failure Inbound and outbound queues were not properly configured and that lead to MPI configuration failure. Fixes: 05c6c029a44d ("scsi: pm80xx: Increase number of supported queues") Cc: stable@vger.kernel.org # 5.10+ Link: https://lore.kernel.org/r/20210402054212.17834-1-Viswas.G@microchip.com.com Reported-and-tested-by: Ash Izat <ash@ai0.uk> Signed-off-by: Viswas G <Viswas.G@microchip.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> 06 April 2021, 03:06:22 UTC
08c27f3 Tetsuo Handa 05 April 2021, 10:16:50 UTC batman-adv: initialize "struct batadv_tvlv_tt_vlan_data"->reserved field KMSAN found uninitialized value at batadv_tt_prepare_tvlv_local_data() [1], for commit ced72933a5e8ab52 ("batman-adv: use CRC32C instead of CRC16 in TT code") inserted 'reserved' field into "struct batadv_tvlv_tt_data" and commit 7ea7b4a142758dea ("batman-adv: make the TT CRC logic VLAN specific") moved that field to "struct batadv_tvlv_tt_vlan_data" but left that field uninitialized. [1] https://syzkaller.appspot.com/bug?id=07f3e6dba96f0eb3cabab986adcd8a58b9bdbe9d Reported-by: syzbot <syzbot+50ee810676e6a089487b@syzkaller.appspotmail.com> Tested-by: syzbot <syzbot+50ee810676e6a089487b@syzkaller.appspotmail.com> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Fixes: ced72933a5e8ab52 ("batman-adv: use CRC32C instead of CRC16 in TT code") Fixes: 7ea7b4a142758dea ("batman-adv: make the TT CRC logic VLAN specific") Acked-by: Sven Eckelmann <sven@narfation.org> Signed-off-by: David S. Miller <davem@davemloft.net> 05 April 2021, 22:06:03 UTC
back to top