- 08 11月, 2021 7 次提交
-
-
由 Jouni Malinen 提交于
stable inclusion from linux-4.19.205 commit 08c613a2cb06c68ef4e7733e052af067b21e5dbb CVE: CVE-2020-3702 -------------------------------- commit ca284802 upstream. Do not delete a key cache entry that is still being referenced by pending frames in TXQs. This avoids reuse of the key cache entry while a frame might still be transmitted using it. To avoid having to do any additional operations during the main TX path operations, track pending key cache entries in a new bitmap and check whether any pending entries can be deleted before every new key add/remove operation. Also clear any remaining entries when stopping the interface. Signed-off-by: NJouni Malinen <jouni@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-6-jouni@codeaurora.org Cc: Pali Rohár <pali@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Jouni Malinen 提交于
stable inclusion from linux-4.19.205 commit 7c5a966edd3c6eec4a9bdf698c1f27712d1781f0 CVE: CVE-2020-3702 -------------------------------- commit 144cd24d upstream. tkip_keymap can be used internally to avoid the reference to key->cipher and with this, only the key index value itself is needed. This allows ath_key_delete() call to be postponed to be handled after the upper layer STA and key entry have already been removed. This is needed to make ath9k key cache management safer. Signed-off-by: NJouni Malinen <jouni@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-5-jouni@codeaurora.org Cc: Pali Rohár <pali@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Jouni Malinen 提交于
stable inclusion from linux-4.19.205 commit fb924bfcecc90ca63ca76b5a10f192bd0e1bb35d CVE: CVE-2020-3702 -------------------------------- commit d2d3e364 upstream. ath9k is going to use this for safer management of key cache entries. Signed-off-by: NJouni Malinen <jouni@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-4-jouni@codeaurora.org Cc: Pali Rohár <pali@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Jouni Malinen 提交于
stable inclusion from linux-4.19.205 commit d2fd9d34210f34cd0ff5b33fa94e9fcc2a513cea CVE: CVE-2020-3702 -------------------------------- commit 73488cb2 upstream. Now that ath/key.c may not be explicitly clearing keys from the key cache, clear all key cache entries when disabling hardware to make sure no keys are left behind beyond this point. Signed-off-by: NJouni Malinen <jouni@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-3-jouni@codeaurora.org Cc: Pali Rohár <pali@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Jouni Malinen 提交于
stable inclusion from linux-4.19.205 commit dd5815f023b89c9a28325d8a2a5f0779b57b7190 CVE: CVE-2020-3702 -------------------------------- commit 56c5485c upstream. It is possible for there to be pending frames in TXQs with a reference to the key cache entry that is being deleted. If such a key cache entry is cleared, those pending frame in TXQ might get transmitted without proper encryption. It is safer to leave the previously used key into the key cache in such cases. Instead, only clear the MAC address to prevent RX processing from using this key cache entry. This is needed in particularly in AP mode where the TXQs cannot be flushed on station disconnection. This change alone may not be able to address all cases where the key cache entry might get reused for other purposes immediately (the key cache entry should be released for reuse only once the TXQs do not have any remaining references to them), but this makes it less likely to get unprotected frames and the more complete changes may end up being significantly more complex. Signed-off-by: NJouni Malinen <jouni@codeaurora.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20201214172118.18100-2-jouni@codeaurora.org Cc: Pali Rohár <pali@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Theodore Ts'o 提交于
mainline inclusion from mainline-5.15-rc1 commit 308c57cc category: bugfix bugzilla: 109297 CVE: NA --------------------------- If the underlying storage device is using thin-provisioning, it's possible for a zeroout operation to return ENOSPC. Commit df22291f ("ext4: Retry block allocation if we have free blocks left") added logic to retry block allocation since we might get free block after we commit a transaction. But the ENOSPC from thin-provisioning will confuse ext4, and lead to an infinite loop. Since using zeroout instead of splitting the extent node is an optimization, if it fails, we might as well fall back to splitting the extent node. Reported-by: Nyangerkun <yangerkun@huawei.com> Signed-off-by: NTheodore Ts'o <tytso@mit.edu> Signed-off-by: Nyangerkun <yangerkun@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Lin, Zhenpeng 提交于
mainline inclusion from mainline-v5.15-rc2 commit d9ea761f category: bugfix bugzilla: 85666 CVE: CVE-2020-16119 ------------------------------------------------- Commit 2677d206 ("dccp: don't free ccid2_hc_tx_sock ...") fixed a UAF but reintroduced CVE-2017-6074. When the sock is cloned, two dccps_hc_tx_ccid will reference to the same ccid. So one can free the ccid object twice from two socks after cloning. This issue was found by "Hadar Manor" as well and assigned with CVE-2020-16119, which was fixed in Ubuntu's kernel. So here I port the patch from Ubuntu to fix it. The patch prevents cloned socks from referencing the same ccid. Fixes: 2677d206 ("dccp: don't free ccid2_hc_tx_sock ...") Signed-off-by: NZhenpeng Lin <zplin@psu.edu> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NLu Wei <luwei32@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 05 11月, 2021 14 次提交
-
-
由 Hou Tao 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- It attaches eBPF program into fs_file_read() and fs_file_release() respectively. The program for fs_file_read() will record read history, calculate read pattern and set f_mode for specific file, And program for fs_file_release() will clean the saved read history. Signed-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- Identify writable tracepoint program by section prefix raw_tracepoint.w/. The correct way is back-porting from commit ccaf12d6 ("libbpf: Support detecting and attaching of writable tracepoint program"), but the refactoring of libbpf makes it hard, so using the same section prefix as ccaf12d6 and post a home-made patch instead. Signed-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- Use fs_file_read_do_trace() and trace_fs_file_release() to do that. Signed-off-by: NHou Tao <houtao1@huawei.com> Acked-by: Nfang wei <fangwei1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- Use fs_file_read_do_trace() and trace_fs_file_release() to do that. Signed-off-by: NHou Tao <houtao1@huawei.com> Acked-by: Nfang wei <fangwei1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- fs_file_read_do_trace() uses writable-tracepoint to update f_mode for file read procedure. Also export it to make it being usable for filesystem kernel module. Signed-off-by: NHou Tao <houtao1@huawei.com> Acked-by: Nfang wei <fangwei1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- Add a writable bare tracepoint fs_file_read() and a bare tracepoint fs_file_release(). A version field is added to fs_file_read() to support extension of fs_file_read_ctx in future. These two tracepoints need to be exported and will be used by filesystem kernel module. Signed-off-by: NHou Tao <houtao1@huawei.com> Acked-by: Nfang wei <fangwei1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
mainline inclusion from mainline-5.16 commit 65223741 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- Commit 9df1c28b ("bpf: add writable context for raw tracepoints") supports writable context for tracepoint, but it misses the support for bare tracepoint which has no associated trace event. Bare tracepoint is defined by DECLARE_TRACE(), so adding a corresponding DECLARE_TRACE_WRITABLE() macro to generate a definition in __bpf_raw_tp_map section for bare tracepoint in a similar way to DEFINE_TRACE_WRITABLE(). Signed-off-by: NHou Tao <houtao1@huawei.com> Signed-off-by: NAndrii Nakryiko <andrii@kernel.org> Acked-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20211004094857.30868-2-hotforest@gmail.comReviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Qais Yousef 提交于
mainline inclusion from mainline-5.12 commit 6939f4ef category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- Some subsystems only have bare tracepoints (a tracepoint with no associated trace event) to avoid the problem of trace events being an ABI that can't be changed. >From bpf presepective, bare tracepoints are what it calls RAW_TRACEPOINT(). Since bpf assumed there's 1:1 mapping, it relied on hooking to DEFINE_EVENT() macro to create bpf mapping of the tracepoints. Since bare tracepoints use DECLARE_TRACE() to create the tracepoint, bpf had no knowledge about their existence. By teaching bpf_probe.h to parse DECLARE_TRACE() in a similar fashion to DEFINE_EVENT(), bpf can find and attach to the new raw tracepoints. Enabling that comes with the contract that changes to raw tracepoints don't constitute a regression if they break existing bpf programs. We need the ability to continue to morph and modify these raw tracepoints without worrying about any ABI. Update Documentation/bpf/bpf_design_QA.rst to document this contract. Signed-off-by: NQais Yousef <qais.yousef@arm.com> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Acked-by: NYonghong Song <yhs@fb.com> Link: https://lore.kernel.org/bpf/20210119122237.2426878-2-qais.yousef@arm.comSigned-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Steven Rostedt (VMware) 提交于
mainline inclusion from mainline-5.10 commit afbe7973 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- As tracepoints are discouraged from being added in a header because it can cause side effects if other tracepoints are in headers, as well as bloat the kernel as the trace_<tracepoint>() function is not a small inline, the common workaround is to add a function call that calls a wrapper function in a C file that then calls the tracepoint. But as function calls add overhead, this function should only be called when the tracepoint in question is enabled. To get around this overhead, a static_branch can be used to only have the tracepoint wrapper get called when the tracepoint is enabled. Add a tracepoint_enabled(tp) macro that gets passed the name of the tracepoint, and this becomes a static_branch that is enabled when the tracepoint is enabled and is a nop when the tracepoint is disabled. Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- There are two issues with the current solution: 1) tracepoint xfs_read_file is visible in tracefs It forms an ABI for userspace. It is bad because new field may be added into xfs_writable_file to export more information to userspace. 2) tracepoint xfs_read_file is specific to xfs HDFS can be stacked on ext4. This reverts commit 4a0a1e84. Signed-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- There are two issues with the current solution: 1) tracepoint xfs_read_file is visible in tracefs It forms an ABI for userspace. It is bad because new field may be added into xfs_writable_file to export more information to userspace. 2) tracepoint xfs_read_file is specific to xfs HDFS can be stacked on ext4. This reverts commit 66844901. Signed-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- There are two issues with the current solution: 1) tracepoint xfs_read_file is visible in tracefs It forms an ABI for userspace. It is bad because new field may be added into xfs_writable_file to export more information to userspace. 2) tracepoint xfs_read_file is specific to xfs HDFS can be stacked on ext4. This reverts commit b1e9dddb, but keep the definitions of FMODE_WILLNEED & FMODE_SPC_READAHEAD. Signed-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- There are two issues with the current solution: 1) tracepoint xfs_read_file is visible in tracefs It forms an ABI for userspace. It is bad because new field may be added into xfs_writable_file to export more information to userspace. 2) tracepoint xfs_read_file is specific to xfs HDFS can be stacked on ext4. This reverts commit 38abc1bb. Signed-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Hou Tao 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4H3JT CVE: NA --------------------------- There are two issues with the current solution: 1) tracepoint xfs_read_file is visible in tracefs It forms an ABI for userspace. It is bad because new field may be added into xfs_writable_file to export more information to userspace. 2) tracepoint xfs_read_file is specific to xfs HDFS can be stacked on ext4. A new solution is proposed which uses vfs bare tracepoint, so reverts commit 69513cfb. Signed-off-by: NHou Tao <houtao1@huawei.com> Reviewed-by: NKuohai Xu <xukuohai@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
- 04 11月, 2021 19 次提交
-
-
由 zhangguijiang 提交于
ascend inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4GVSG CVE: NA ------------------- Struct mmc_host using variable private[0] to point the end of struct mmc_host, at deaf01a6 we modified struct mmc_host but ignored the role of private[0] and not put it to the end of struct mmc_host. It will make mmc card probe failed, so we fix this problem, and now ascend hisi mmc card is able to probe success. Signed-off-by: Nzhangguijiang <zhangguijiang@huawei.com> Reviewed-by: NDing Tianhong <dingtianhong@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
mainline inclusion from mainline-v5.14-rc1 commit 3cfdf8fc category: bugfix bugzilla: NA CVE: CVE-2021-34981 ------------------------------------------------- When cmtp_attach_device fails, cmtp_add_connection returns the error value which leads to the caller to doing fput through sockfd_put. But cmtp_session kthread, which is stopped in this path will also call fput, leading to a potential refcount underflow or a use-after-free. Add a refcount before we signal the kthread to stop. The kthread will try to grab the cmtp_session_sem mutex before doing the fput, which is held when get_file is called, so there should be no races there. Reported-by: Ryota Shiga Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by: NMarcel Holtmann <marcel@holtmann.org> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com> Reviewed-by: Nweiyang wang <wangweiyang2@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Xingui Yang 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA --------------------- To help debugging efforts, print d2h status and error D2H: FIS Status Bits = 0x53 BSY = 0... .... Off DRDY = .1.. .... On DF = ..0. .... Off DSC = ...1 .... On DRQ = .... 0... Off Alignment Error = .... .0.. Off Sense Data Available = .... ..1. On ERR = .... ...1 On FIS Error Bits = 0x40 ICRC = 0... .... Off UNC = .1.. .... On MC (O) = ..0. .... Off IDNF = ...0 .... Off MCR (O) = .... 0... Off ABRT = .... .0.. Off EOM = .... ..0. Off CCTO = .... ...0 Off Here is an example print: hisi_sas_v3_hw 0000:74:02.0: sata d2h status 0x53, error 0x40 Signed-off-by: NXingui Yang <yangxingui@huawei.com> Reviewed by kangfenglong <kangfenglong@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Xingui Yang 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA ----------------------------------------- This reverts commit 5868da04. this optimization patch depends on the patch of the kernel MQ block. If the block MQ patch is not integrated at the upper layer, there is a possibility that the spinlock deadlock occurs. Signed-off-by: NXingui Yang <yangxingui@huawei.com> Reviewed-by: NKangfenglong <kangfenglong@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Xingui Yang 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA --------------------- This reverts commit 2c2ed927. this optimization patch depends on the kernel block MQ patch. If the block MQ patch is not integrated, there is a possibility that the spinlock deadlock occurs. Signed-off-by: NXingui Yang <yangxingui@huawei.com> Reviewed-by: NKangfenglong <kangfenglong@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA ---------------------------- Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Huazhong Tan 提交于
mainline inclusion from mainline-v5.8-rc1 commit 95163521 category: bugfix bugzilla: NA CVE: NA ---------------------------- Remove the redundant 'goto' and return -ENOMEM directly, when allocating memory for 'hdev' fails in hclge_init_ae_dev(). Fixes: a3ecdc004300 ("net: hns3: add a missing mutex destroy in hclge_init_ad_dev()") Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA ---------------------------- If the parameter is not valid in hclge_get_dfx_reg(), the ret is used but not initialized. Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yonglong Liu 提交于
driver inclusion category: bugfix bugzilla: NA CVE: NA ---------------------------- The previous commit 7051ad8d91c9 ("net: hns3: fix kernel crash when unload VF while it is being reset") did not full solve the problem, we should clear the state HCLGEVF_STATE_NIC_REGISTERED after reset handling done. Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Guangbin Huang 提交于
mainline inclusion from mainline-v5.15-rc7 commit 0251d196 category: bugfix bugzilla: NA CVE: NA ---------------------------- Currently, if there is a reset event triggered by RAS during device in initialization process, driver may run reset process concurrently with initialization process. In this case, it may cause problem. For example, the RSS indirection table may has not been alloc memory in initialization process yet, but it is used in reset process, it will cause a call trace like this: [61228.744836] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ... [61228.897677] Workqueue: hclgevf hclgevf_service_task [hclgevf] [61228.911390] pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) [61228.918670] pc : hclgevf_set_rss_indir_table+0xb4/0x190 [hclgevf] [61228.927812] lr : hclgevf_set_rss_indir_table+0x90/0x190 [hclgevf] [61228.937248] sp : ffff8000162ebb50 [61228.941087] x29: ffff8000162ebb50 x28: ffffb77add72dbc0 x27: ffff0820c7dc8080 [61228.949516] x26: 0000000000000000 x25: ffff0820ad4fc880 x24: ffff0820c7dc8080 [61228.958220] x23: ffff0820c7dc8090 x22: 00000000ffffffff x21: 0000000000000040 [61228.966360] x20: ffffb77add72b9c0 x19: 0000000000000000 x18: 0000000000000030 [61228.974646] x17: 0000000000000000 x16: ffffb77ae713feb0 x15: ffff0820ad4fcce8 [61228.982808] x14: ffffffffffffffff x13: ffff8000962eb7f7 x12: 00003834ec70c960 [61228.991990] x11: 00e0fafa8c206982 x10: 9670facc78a8f9a8 x9 : ffffb77add717530 [61229.001123] x8 : ffff0820ad4fd6b8 x7 : 0000000000000000 x6 : 0000000000000011 [61229.010249] x5 : 00000000000cb1b0 x4 : 0000000000002adb x3 : 0000000000000049 [61229.018662] x2 : ffff8000162ebbb8 x1 : 0000000000000000 x0 : 0000000000000480 [61229.027002] Call trace: [61229.030177] hclgevf_set_rss_indir_table+0xb4/0x190 [hclgevf] [61229.039009] hclgevf_rss_init_hw+0x128/0x1b4 [hclgevf] [61229.046809] hclgevf_reset_rebuild+0x17c/0x69c [hclgevf] [61229.053862] hclgevf_reset_service_task+0x4cc/0xa80 [hclgevf] [61229.061306] hclgevf_service_task+0x6c/0x630 [hclgevf] [61229.068491] process_one_work+0x1dc/0x48c [61229.074121] worker_thread+0x15c/0x464 [61229.078562] kthread+0x168/0x16c [61229.082873] ret_from_fork+0x10/0x18 [61229.088221] Code: 7900e7f6 f904a683 d503201f 9101a3e2 (38616b43) [61229.095357] ---[ end trace 153661a538f6768c ]--- To fix this problem, don't schedule reset task before initialization process is done. Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yufeng Mo 提交于
mainline inclusion from mainline-v5.15-rc7 commit 1385cc81 category: bugfix bugzilla: NA CVE: NA ---------------------------- The task of VF reset is performed through the workqueue. It checks the value of hdev->reset_pending to determine whether to exit the loop. However, the value of hdev->reset_pending may also be assigned by the interrupt function hclgevf_misc_irq_handle(), which may cause the loop fail to exit and keep occupying the workqueue. This loop is not necessary, so remove it and the workqueue will be rescheduled if the reset needs to be retried or a new reset occurs. Fixes: 1cc9bc6e ("net: hns3: split hclgevf_reset() into preparing and rebuilding part") Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Guangbin Huang 提交于
mainline inclusion from mainline-v5.15-rc7 commit b63fcaab category: bugfix bugzilla: NA CVE: NA ---------------------------- Currently, DWRR of tc will be initialized to a fixed value when this tc is enabled, but it is not been reset to 0 when this tc is disabled. It cause a problem that the DWRR of unused tc is not 0 after using tc tool to add and delete multi-tc parameters. For examples, after enabling 4 TCs and restoring to 1 TC by follow tc commands: $ tc qdisc add dev eth0 root mqprio num_tc 4 map 0 1 2 3 0 1 2 3 queues \ 8@0 8@8 8@16 8@24 hw 1 mode channel $ tc qdisc del dev eth0 root Now there is just one TC is enabled for eth0, but the tc info querying by debugfs is shown as follow: $ cat /mnt/hns3/0000:7d:00.0/tm/tc_sch_info enabled tc number: 1 weight_offset: 14 TC MODE WEIGHT 0 dwrr 100 1 dwrr 100 2 dwrr 100 3 dwrr 100 4 dwrr 0 5 dwrr 0 6 dwrr 0 7 dwrr 0 This patch fixes it by resetting DWRR of tc to 0 when tc is disabled. Fixes: 84844054 ("net: hns3: Add support of TX Scheduler & Shaper to HNS3 driver") Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yufeng Mo 提交于
mainline inclusion from mainline-v5.15-rc3 commit 5126b9d3 category: bugfix bugzilla: NA CVE: NA ---------------------------- hclge_get_reset_status() should return the tqp reset status. However, if the CMDQ fails, the caller will take it as tqp reset success status by mistake. Therefore, uses a parameters to get the tqp reset status instead. Fixes: 46a3df9f ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Jiaran Zhang 提交于
mainline inclusion from mainline-v5.15-rc2 commit 427900d2 category: bugfix bugzilla: NA CVE: NA ---------------------------- Currently, the VF does not clear the interrupt source immediately after receiving the interrupt. As a result, if the second interrupt task is triggered when processing the first interrupt task, clearing the interrupt source before exiting will clear the interrupt sources of the two tasks at the same time. As a result, no interrupt is triggered for the second task. The VF detects the missed message only when the next interrupt is generated. Clearing it immediately after executing check_evt_cause ensures that: 1. Even if two interrupt tasks are triggered at the same time, they can be processed. 2. If the second task is triggered during the processing of the first task and the interrupt source is not cleared, the interrupt is reported after vector0 is enabled. Fixes: b90fcc5b ("net: hns3: add reset handling for VF when doing Core/Global/IMP reset") Signed-off-by: Jiaran Zhang <zhangjiaran@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yufeng Mo 提交于
mainline inclusion from mainline-v5.15-rc2 commit b81d8948 category: bugfix bugzilla: NA CVE: NA ---------------------------- The firmware will not disable mac in flr process. Therefore, the driver needs to proactively disable mac during flr, which is the same as the function reset. Fixes: 35d93a30 ("net: hns3: adjust the process of PF reset") Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yufeng Mo 提交于
mainline inclusion from mainline-v5.15-rc1 commit 0fc36e37 category: feature bugzilla: NA CVE: NA ---------------------------- Add a trace to get the info of pf responds to the mailbox message of vf. Signed-off-by: NYufeng Mo <moyufeng@huawei.com> Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Huazhong Tan 提交于
mainline inclusion from mainline-v5.8-rc1 commit 3fd8dc26 category: cleanup bugzilla: NA CVE: NA ---------------------------- Since hclge_set_umv_space() is only called by hclge_init_umv_space(), parameter 'allocated_size' will not be NULL. Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Jian Shen 提交于
mainline inclusion from mainline-v5.8-rc1 commit c1c5f66e category: cleanup bugzilla: NA CVE: NA ---------------------------- Since hclge_set_umv_space() is only called by hclge_init_umv_space(), so parameter 'is_alloc' is redundant. Signed-off-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Jian Shen 提交于
mainline inclusion from mainline-v5.13-rc1 commit 5be36fb7 category: feature bugzilla: NA CVE: NA ---------------------------- Currently, if user hasn't change channel number, the rss_size is limited to be no more than the vector number, in order to keep one vector only being mapped to one queue. But the queue number of each tc can be different, and one vector also can be mapped by multiple queues. So remove this limitation. Signed-off-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NYonglong Liu <liuyonglong@huawei.com> Reviewed-by: Nli yongxin <liyongxin1@huawei.com> Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-