- Dec 27, 2019
-
-
hulk inclusion category: feature bugzilla: 13228 CVE: NA --------------------------- A single CPU can spend an excessive amount of time in the kernel operating on large amounts of data. Often these situations arise during initialization- and destruction-related tasks, where the data involved scales with system size. These long-running jobs can slow startup and shutdown of applications and the system itself while extra CPUs sit idle. To ensure that applications and the kernel continue to perform well as core counts and memory sizes increase, harness these idle CPUs to complete such jobs more quickly. ktask is a generic framework for parallelizing CPU-intensive work in the kernel. The API is generic enough to add concurrency to many different kinds of tasks--for example, zeroing a range of pages or evicting a list of inodes--and aims to save its clients the trouble of splitting up the work, choosing the number of threads to use, maintaining an efficient concurrency level, starting these threads, and load balancing the work between them. The Documentation patch earlier in this series, from which the above was swiped, has more background. Inspired by work from Pavel Tatashin, Steve Sistare, and Jonathan Adams. Signed-off-by:
Daniel Jordan <daniel.m.jordan@oracle.com>
Suggested-by: Pavel Tatashin <Pavel.Tatashin@microsoft.com>
Suggested-by: Steve Sistare <steven.sistare@oracle.com>
Suggested-by: Jonathan Adams <jwadams@google.com>
Signed-off-by: Hongbo Yao <yaohongbo@huawei.com>
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
Tested-by: Hongbo Yao <yaohongbo@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
hulk inclusion category: feature bugzilla: 13228 CVE: NA --------------------------- Motivates and explains the ktask API for kernel clients. Signed-off-by:
Daniel Jordan <daniel.m.jordan@oracle.com>
Signed-off-by: Hongbo Yao <yaohongbo@huawei.com>
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
Tested-by: Hongbo Yao <yaohongbo@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
hulk inclusion category: bugfix bugzilla: 18685 CVE: NA ----------------------------- The rcu_dereference() should be used under rcu_read_lock(), or else it will complain about it may be a suspicious RCU usage. WARNING: suspicious RCU usage [...] ----------------------------- fs/ext4/block_validity.c:331 suspicious rcu_dereference_check() usage! [...] Because ext4_release_system_zone() always under protection of sb->s_umount, so the proper fix is switch to use rcu_dereference_protected() instead. Fixes: fb9fd3ade129be ("ext4: fix potential use after free in system zone via remount with noblock_validity") Reviewed-by:ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Yi Zhang <yi.zhang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
hulk inclusion category: bugfix bugzilla: 16625 CVE: NA --------------------------- If user specify a large enough value of "commit=" option, it may trigger signed integer overflow which may lead to sbi->s_commit_interval becomes a large or small value, zero in particular. UBSAN: Undefined behaviour in ../fs/ext4/super.c:1592:31 signed integer overflow: 536870912 * 1000 cannot be represented in type 'int' [...] Call trace: [...] [<ffffff9008a2d120>] ubsan_epilogue+0x34/0x9c lib/ubsan.c:166 [<ffffff9008a2d8b8>] handle_overflow+0x228/0x280 lib/ubsan.c:197 [<ffffff9008a2d95c>] __ubsan_handle_mul_overflow+0x4c/0x68 lib/ubsan.c:218 [<ffffff90086d070c>] handle_mount_opt fs/ext4/super.c:1592 [inline] [<ffffff90086d070c>] parse_options+0x1724/0x1a40 fs/ext4/super.c:1773 [<ffffff90086d51c4>] ext4_remount+0x2ec/0x14a0 fs/ext4/super.c:4834 [...] Although it is not a big deal, still silence the UBSAN by limit the input value. Link: https://patchwork.ozlabs.org/patch/1153233 Signed-off-by:
zhangyi (F) <yi.zhang@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Yi Zhang <yi.zhang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
hulk inclusion category: bugfix bugzilla: 20799 CVE: NA --------------------------- The following patch didn't consider the situation when we boot the system using device tree but 'CONFIG_ACPI' is enabled. In this situation, we also need to set all the CPU as present CPU. Fixes: 280637f70ab5 ("arm64: mark all the GICC nodes in MADT as possible cpu") Signed-off-by:Xiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
mainline inclusion from mainline-v5.3-rc6 commit 1fb254aa category: bugfix bugzilla: 13690 CVE: CVE-2019-15538 ------------------------------------------------- Benjamin Moody reported to Debian that XFS partially wedges when a chgrp fails on account of being out of disk quota. I ran his reproducer script: (and then as user dummy) $ dd if=/dev/urandom bs=1M count=50 of=/mnt/dummy/foo $ chgrp plugdev /mnt/dummy/foo and saw: Reviewed-by:
zhengbin <zhengbin13@huawei.com>
================================================
WARNING: lock held when returning to user space!
5.3.0-rc5 #rc5 Tainted: G W
------------------------------------------------
chgrp/47006 is leaving the kernel with locks still held!
1 lock held by chgrp/47006:
#0: 000000006664ea2d (&xfs_nondir_ilock_class){++++}, at: xfs_ilock+0xd2/0x290 [xfs]
...which is clearly caused by xfs_setattr_nonsize failing to unlock the
ILOCK after the xfs_qm_vop_chown_reserve call fails. Add the missing
unlock.
Reported-by: <benjamin.moody@gmail.com>
Fixes: 253f4911 ("xfs: better xfs_trans_alloc interface")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Salvatore Bonaccorso <carnil@debian.org>
Reviewed-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
mainline inclusion from mainline-v5.3-rc6 commit ae148243 category: bugfix bugzilla: 20701 CVE: NA ------------------------------------------------- In commit 6096d91a ("dm space map metadata: fix occasional leak of a metadata block on resize"), we refactor the commit logic to a new function 'apply_bops'. But when that logic was replaced in out() the return value was not stored. This may lead out() returning a wrong value to the caller. Fixes: 6096d91a ("dm space map metadata: fix occasional leak of a metadata block on resize") Cc: stable@vger.kernel.org Signed-off-by:
ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
mainline inclusion from mainline-v5.3-rc6 commit e4f9d601 category: bugfix bugzilla: 20701 CVE: NA ------------------------------------------------- When btree_split_beneath() splits a node to two new children, it will allocate two blocks: left and right. If right block's allocation failed, the left block will be unlocked and marked dirty. If this happened, the left block'ss content is zero, because it wasn't initialized with the btree struct before the attempot to allocate the right block. Upon return, when flushing the left block to disk, the validator will fail when check this block. Then a BUG_ON is raised. Fix this by completely initializing the left block before allocating and initializing the right block. Fixes: 4dcb8b57 ("dm btree: fix leak of bufio-backed block in btree_split_beneath error path") Cc: stable@vger.kernel.org Signed-off-by:
ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Reviewed-by: Yufen Yu <yuyufen@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
driver inclusion category: bugfix bugzilla: NA CVE: NA Functions is used only in the declared file. So we need to add a keyword static for them to Reduce coupling. Those functions inclding as below: hclge_func_reset_sync_vf(). This patch as a supplement to patch 26380194. Fix tag: 26380194 (" some functions can be static ") Feature or Bugfix:Bugfix Signed-off-by:liaoguojia <liaoguojia@huawei.com>
Reviewed-by: lipeng <lipeng321@huawei.com>
Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com>
Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
driver inclusion category: bugfix bugzilla: NA CVE: NA This patch fixes some incorrect type in assignment reported by sparse. Those sparse warning as below: - warning : restricted __le16 degrades to integer - warning : cast from restricted __le32 - warning : expected restricted __le32 - warning : cast from restricted __be32 - warning : cast from restricted __be16 - warning : cast to restricted __le16 Feature or Bugfix:Bugfix Signed-off-by:
liaoguojia <liaoguojia@huawei.com>
Reviewed-by: lipeng <lipeng321@huawei.com>
Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com>
Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
driver inclusion category: bugfix bugzilla: NA CVE: NA When doing loopback test, it should set HCLGE_SWITCH_ALW_LPBK_B intead of HCLGE_SWITCH_ALW_LCL_LPBK_B, which may cause loopback test fail. Feature or Bugfix:Bugfix Signed-off-by:
shenjian (K) <shenjian15@huawei.com>
Reviewed-by: huangdaode <huangdaode@hisilicon.com>
Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com>
Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
driver inclusion category: bugfix bugzilla: NA CVE: NA This patch adds support for spoof check configuration for VFs. When it is enabled, "spoof checking" is done for both mac address and VLAN. For each VF, the HW ensures that the source MAC address (or VLAN) of every outgoing packet exists in the MAC-list (or VLAN-list) configured for RX filtering for that VF. If not, the packet is dropped. Feature or Bugfix:Bugfix Signed-off-by:
shenjian (K) <shenjian15@huawei.com>
Reviewed-by: lipeng <lipeng321@huawei.com>
Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com>
Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
mainline inclusion from mainline-v4.20-rc5 commit 77cfe950 category: bugfix bugzilla: 5611 CVE: NA The dummy node ID is marked into all memory ranges on the system. So the dummy node really extends the entire memblock.memory. Hence report correct extent information for the dummy node using memblock range helper functions instead of the range [0LLU, PFN_PHYS(max_pfn) - 1)]. Fixes: 1a2db300 ("arm64, numa: Add NUMA support for arm64 platforms") Acked-by:
Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Xuefeng Wang <wxf.wang@hisilicon.com>
Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
mainline inclusion from mainline-v4.20-rc5 commit 8c11ea5c category: bugfix bugzilla: 5654 CVE: NA The arm64 JIT has the same issue as ppc64 JIT in that the relative BPF to BPF call offset can be too far away from core kernel in that relative encoding into imm is not sufficient and could potentially be truncated, see also fd045f6c ("arm64: add support for module PLTs") which adds spill-over space for module_alloc() and therefore bpf_jit_binary_alloc(). Therefore, use the recently added bpf_jit_get_func_addr() helper for properly fetching the address through prog->aux->func[off]->bpf_func instead. This also has the benefit to optimize normal helper calls since their address can use the optimized emission. Tested on Cavium ThunderX CN8890. Fixes: db496944 ("bpf: arm64: add JIT support for multi-function programs") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Xuefeng Wang <wxf.wang@hisilicon.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
mainline inclusion from mainline-v4.20-rc5 commit e2c95a61 category: bugfix bugzilla: 5654 CVE: NA Make fetching of the BPF call address from ppc64 JIT generic. ppc64 was using a slightly different variant rather than through the insns' imm field encoding as the target address would not fit into that space. Therefore, the target subprog number was encoded into the insns' offset and fetched through fp->aux->func[off]->bpf_func instead. Given there are other JITs with this issue and the mechanism of fetching the address is JIT-generic, move it into the core as a helper instead. On the JIT side, we get information on whether the retrieved address is a fixed one, that is, not changing through JIT passes, or a dynamic one. For the former, JITs can optimize their imm emission because this doesn't change jump offsets throughout JIT process. Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
Tested-by: Sandipan Das <sandipan@linux.ibm.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Xuefeng Wang <wxf.wang@hisilicon.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
driver inclusion category: bugfix bugzilla: NA CVE: NA HNS3 driver use unsigned int to calculate the shaper parameter, when the configured bandwidth is small, like 1M, the actual result is 1.28M in the chip side. This bug only appears when the bandwidth is less than 20M. This patch plus the ir_s one more time when the calculated result is equals to the configured bandwidth, so that can get a value closer to the configured bandwidth. Feature or Bugfix:Bugfix Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com>
Reviewed-by: linyunsheng <linyunsheng@huawei.com>
Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
mainline inclusion from mainline-5.1-rc1 commit 87c9607d category: bugfix bugzilla: 18943 CVE: NA --------------------------- Fix an off-by-one error in the realtime bitmap "is used" cross-reference helper function if the realtime extent size is a single block. Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: yu kuai <yukuai3@huawei.com>
Reviewed-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
mainline inclusion from mainline-5.3-rc6 commit 46d0b24c category: 13690 bugzilla: NA CVE: CVE-2019-3892 ------------------------------------------------- userfaultfd_release() should clear vm_flags/vm_userfaultfd_ctx even if mm->core_state != NULL. Otherwise a page fault can see userfaultfd_missing() == T and use an already freed userfaultfd_ctx. Link: http://lkml.kernel.org/r/20190820160237.GB4983@redhat.com Fixes: 04f5866e ("coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping") Signed-off-by:
Oleg Nesterov <oleg@redhat.com>
Reported-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Jann Horn <jannh@google.com>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
driver inclusion category: feature bugzilla: NA CVE: NA enable hisi pcie debug driver for hiarmtool. Signed-off-by:
liuyanshi <liuyanshi@huawei.com>
Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
driver inclusion category: feature bugzilla: NA CVE: NA hisi_pcie_cae:hisi pcie debug driver for hiarmtool. This driver can create /dev/pcie_reg_dev file and map pcie regs to userspace. Hiarmtool can use this file to access pcie regs in order to get useful dfx information about pcie module. Signed-off-by:
liuyanshi <liuyanshi@huawei.com>
Reviewed-by: Li Jingyi <jingyi.li@huawei.com>
Acked-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
driver inclusion category: feature bugzilla: NA CVE: NA This patch fix the issue of SAS panic in 1616 scenario. set the numa_num_per_node parameter with the default value.. Signed-off-by:
Yupeng Zhou <zhouyupeng1@huawei.com>
Reviewed-by: Jian Luo <luojian5@huawei.com>
Reviewed-by: Chuan Gao <gaochuan4@huawei.com>
Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
driver inclusion category: feature bugzilla: NA CVE: NA This patch fix the issue of disk in fail when only 1 cpu online. alloc the DQ number according to the interrupt allocated. Signed-off-by:
Yupeng Zhou <zhouyupeng1@huawei.com>
Reviewed-by: Jian Luo <luojian5@huawei.com>
Reviewed-by: Chuan Gao <gaochuan4@huawei.com>
Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
driver inclusion category: bugfix bugzilla: NA CVE: NA We set a default value to pf capbilities previously, now we get most of them from NCL_CONFIG by commands to suit different type of hardware. Feature or Bugfix:Bugfix Signed-off-by:
Lijun Ou <oulijun@huawei.com>
Reviewed-by: xavier.huwei <xavier.huwei@huawei.com>
Reviewed-by: Yixian Liu <liuyixian@huawei.com>
Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
driver inclusion category: bugfix bugzilla: NA CVE: NA Feature or Bugfix:Bugfix Signed-off-by:
tanshukun (A) <tanshukun1@huawei.com>
Reviewed-by: xuzaibo <xuzaibo@huawei.com>
Reviewed-by: Zhou Wang <wangzhou1@hisilicon.com>
Reviewed-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
hulk inclusion category: feature bugzilla: 20208 CVE: NA --------------------------- To support CPU hotplug, we need to implement 'acpi_(un)map_cpu()' and 'arch_(un)register_cpu()' for ARM64. These functions are called in 'acpi_processor_hotadd_init()/acpi_processor_remove()' when the CPU is hot added into or hot removed from the system. Note: This patch only support core hotplug and does not support socket hotplug because we don't support live configuration of GIC. Signed-off-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com>
Acked-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
hulk inclusion category: feature bugzilla: 20208 CVE: NA --------------------------- We set 'cpu_possible_mask' based on the enabled GICC node in MADT. If the GICC node is disabled, we will skip initializing the kernel data structure for that CPU. To support CPU hotplug, we need to initialize some CPU related data structure in advance. This patch mark all the GICC nodes as possible CPU and only these enabled GICC nodes as present CPU. Signed-off-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com>
Acked-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
Merge 91 patches from 4.19.67 stable branch (92 total) beside 1 already merged patches: 06dc921 tty/ldsem, locking/rwsem: Add missing ACQUIRE to read_failed sleep loop Signed-off-by:Yang Yingliang <yangyingliang@huawei.com> -
commit f5a47fae upstream. We erroneously added a check for FW API version 41 before sending GEO_TX_POWER_LIMIT, but this was already implemented in version 38. Additionally, it was cherry-picked to older versions, namely 17, 26 and 29, so check for those as well. Cc: stable@vger.kernel.org Fixes: eca1e56c ("iwlwifi: mvm: don't send GEO_TX_POWER_LIMIT to old firmwares") Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
commit 39bd984c upstream. Firmware versions before 41 don't support the GEO_TX_POWER_LIMIT command, and sending it to the firmware will cause a firmware crash. We allow this via debugfs, so we need to return an error value in case it's not supported. This had already been fixed during init, when we send the command if the ACPI WGDS table is present. Fix it also for the other, userspace-triggered case. Cc: stable@vger.kernel.org Fixes: 7fe90e0e ("iwlwifi: mvm: refactor geo init") Signed-off-by:
Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
commit ba3224db upstream. The index for the elements of the ACPI object we dereference was static. This means that if we called the function twice we wouldn't start from 3 again, but rather from the latest index we reached in the previous call. This was dutifully reported by KASAN. Fix this. Cc: stable@vger.kernel.org Fixes: 69964905 ("iwlwifi: mvm: add support for EWRD (Dynamic SAR) ACPI table") Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
commit 87e7e25a upstream. In order to remember how to unmap a memory (as single or as page), we maintain a bit per Transmit Buffer (TBs) in the meta data (structure iwl_cmd_meta). We maintain a bitmap: 1 bit per TB. If the TB is set, we will free the memory as a page. This bitmap was never cleared. Fix this. Cc: stable@vger.kernel.org Fixes: 3cd1980b ("iwlwifi: pcie: introduce new tfd and tb formats") Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
commit df612421 upstream. Commit 63d7ef36 ("mwifiex: Don't abort on small, spec-compliant vendor IEs") adjusted the ieee_types_vendor_header struct, which inadvertently messed up the offsets used in mwifiex_is_wpa_oui_present(). Add that offset back in, mirroring mwifiex_is_rsn_oui_present(). As it stands, commit 63d7ef36 breaks compatibility with WPA (not WPA2) 802.11n networks, since we hit the "info: Disable 11n if AES is not supported by AP" case in mwifiex_is_network_compatible(). Fixes: 63d7ef36 ("mwifiex: Don't abort on small, spec-compliant vendor IEs") Cc: <stable@vger.kernel.org> Signed-off-by:
Brian Norris <briannorris@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
commit 17e433b5 upstream. After commit d73eb57b (KVM: Boost vCPUs that are delivering interrupts), a five years old bug is exposed. Running ebizzy benchmark in three 80 vCPUs VMs on one 80 pCPUs Skylake server, a lot of rcu_sched stall warning splatting in the VMs after stress testing: INFO: rcu_sched detected stalls on CPUs/tasks: { 4 41 57 62 77} (detected by 15, t=60004 jiffies, g=899, c=898, q=15073) Call Trace: flush_tlb_mm_range+0x68/0x140 tlb_flush_mmu.part.75+0x37/0xe0 tlb_finish_mmu+0x55/0x60 zap_page_range+0x142/0x190 SyS_madvise+0x3cd/0x9c0 system_call_fastpath+0x1c/0x21 swait_active() sustains to be true before finish_swait() is called in kvm_vcpu_block(), voluntarily preempted vCPUs are taken into account by kvm_vcpu_on_spin() loop greatly increases the probability condition kvm_arch_vcpu_runnable(vcpu) is checked and can be true, when APICv is enabled the yield-candidate vCPU's VMCS RVI field leaks(by vmx_sync_pir_to_irr()) into spinning-on-a-taken-lock vCPU's current VMCS. This patch fixes it by checking conservatively a subset of events. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Marc Zyngier <Marc.Zyngier@arm.com> Cc: stable@vger.kernel.org Fixes: 98f4a146 (KVM: add kvm_arch_vcpu_runnable() test to kvm_vcpu_on_spin() loop) Signed-off-by:
Wanpeng Li <wanpengli@tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
commit 09a54f0e upstream. If the user specifies an open mode of 3, then we don't have a NFSv4 state attached to the context, and so we Oops when we try to dereference it. Reported-by:
Olga Kornievskaia <aglo@umich.edu>
Fixes: 29b59f94 ("NFSv4: change nfs4_do_setattr to take...")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: stable@vger.kernel.org # v4.10: 991eedb1: NFSv4: Only pass the...
Cc: stable@vger.kernel.org # v4.10+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
commit 8d33096a upstream. We had a report of a server which did not do a DFS referral because the session setup Capabilities field was set to 0 (unlike negotiate protocol where we set CAP_DFS). Better to send it session setup in the capabilities as well (this also more closely matches Windows client behavior). Signed-off-by:
Steve French <stfrench@microsoft.com>
Reviewed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
commit e99c63e4 upstream. Currently we skip SMB2_TREE_CONNECT command when checking during reconnect because Tree Connect happens when establishing an SMB session. For SMB 3.0 protocol version the code also calls validate negotiate which results in SMB2_IOCL command being sent over the wire. This may deadlock on trying to acquire a mutex when checking for reconnect. Fix this by skipping SMB2_IOCL command when doing the reconnect check. Signed-off-by:
Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
commit d75996dd upstream. Vivek: "As of now dax_layout_busy_page() calls unmap_mapping_range() with last argument as 1, which says even unmap cow pages. I am wondering who needs to get rid of cow pages as well. I noticed one interesting side affect of this. I mount xfs with -o dax and mmaped a file with MAP_PRIVATE and wrote some data to a page which created cow page. Then I called fallocate() on that file to zero a page of file. fallocate() called dax_layout_busy_page() which unmapped cow pages as well and then I tried to read back the data I wrote and what I get is old data from persistent memory. I lost the data I had written. This read basically resulted in new fault and read back the data from persistent memory. This sounds wrong. Are there any users which need to unmap cow pages as well? If not, I am proposing changing it to not unmap cow pages. I noticed this while while writing virtio_fs code where when I tried to reclaim a memory range and that corrupted the executable and I was running from virtio-fs and program got segment violation." Dan: "In fact the unmap_mapping_range() in this path is only to synchronize against get_user_pages_fast() and force it to call back into the filesystem to re-establish the mapping. COW pages should be left untouched by dax_layout_busy_page()." Cc: <stable@vger.kernel.org> Fixes: 5fac7408 ("mm, fs, dax: handle layout changes to pinned dax mappings") Signed-off-by:
Vivek Goyal <vgoyal@redhat.com>
Link: https://lore.kernel.org/r/20190802192956.GA3032@redhat.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
commit 05aaa5c9 upstream. In a very similar spirit to commit c470bdc1 ("mac80211: don't WARN on bad WMM parameters from buggy APs"), an AP may not transmit a fully-formed WMM IE. For example, it may miss or repeat an Access Category. The above loop won't catch that and will instead leave one of the four ACs zeroed out. This triggers the following warning in drv_conf_tx() wlan0: invalid CW_min/CW_max: 0/0 and it may leave one of the hardware queues unconfigured. If we detect such a case, let's just print a warning and fall back to the defaults. Tested with a hacked version of hostapd, intentionally corrupting the IEs in hostapd_eid_wmm(). Cc: stable@vger.kernel.org Signed-off-by:
Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20190726224758.210953-1-briannorris@chromium.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
commit c02f77d3 upstream. A long-time problem on the recent AMD chip (X370, X470, B450, etc with PCI ID 1022:1457) with Realtek codecs is the crackled or distorted sound for capture streams, as well as occasional playback hiccups. After lengthy debugging sessions, the workarounds we've found are like the following: - Set up the proper driver caps for this controller, similar as the other AMD controller. - Correct the DMA position reporting with the fixed FIFO size, which is similar like as workaround used for VIA chip set. - Even after the position correction, PulseAudio still shows mysterious stalls of playback streams when a capture is triggered in timer-scheduled mode. Since we have no clear way to eliminate the stall, pass the BATCH PCM flag for PA to suppress the tsched mode as a temporary workaround. This patch implements the workarounds. For the driver caps, it defines a new preset, AXZ_DCAPS_PRESET_AMD_SB. It enables the FIFO- corrected position reporting (corresponding to the new position_fix=6) and enforces the SNDRV_PCM_INFO_BATCH flag. Note that the current implementation is merely a workaround. Hopefully we'll find a better alternative in future, especially about removing the BATCH flag hack again. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195303 Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> -
commit c1c6c877 upstream. The commit bfcba288 ("ALSA - hda: Add support for link audio time reporting") introduced the conditional PCM hw info setup, but it overwrites the global azx_pcm_hw object. This will cause a problem if any other HD-audio controller, as it'll inherit the same bit flag although another controller doesn't support that feature. Fix the bug by setting the PCM hw info flag locally. Fixes: bfcba288 ("ALSA - hda: Add support for link audio time reporting") Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
-