- 13 10月, 2022 6 次提交
-
-
由 Lukas Czerner 提交于
mainline inclusion from mainline-v6.0-rc1 commit b8a04fe7 category: bugfix bugzilla: 186639, https://gitee.com/openeuler/kernel/issues/I58WSQ CVE: CVE-2022-1184 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b8a04fe77ef1360fbf73c80fddbdfeaa9407ed1b -------------------------------- ext4_append() must always allocate a new block, otherwise we run the risk of overwriting existing directory block corrupting the directory tree in the process resulting in all manner of problems later on. Add a sanity check to see if the logical block is already allocated and error out if it is. Cc: stable@kernel.org Signed-off-by: NLukas Czerner <lczerner@redhat.com> Reviewed-by: NAndreas Dilger <adilger@dilger.ca> Link: https://lore.kernel.org/r/20220704142721.157985-2-lczerner@redhat.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu> Signed-off-by: NBaokun Li <libaokun1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lukas Czerner 提交于
mainline inclusion from mainline-v6.0-rc1 commit 65f8ea4c category: bugfix bugzilla: 186639, https://gitee.com/openeuler/kernel/issues/I58WSQ CVE: CVE-2022-1184 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65f8ea4cd57dbd46ea13b41dc8bac03176b04233 -------------------------------- Currently ext4 directory handling code implicitly assumes that the directory blocks are always within the i_size. In fact ext4_append() will attempt to allocate next directory block based solely on i_size and the i_size is then appropriately increased after a successful allocation. However, for this to work it requires i_size to be correct. If, for any reason, the directory inode i_size is corrupted in a way that the directory tree refers to a valid directory block past i_size, we could end up corrupting parts of the directory tree structure by overwriting already used directory blocks when modifying the directory. Fix it by catching the corruption early in __ext4_read_dirblock(). Addresses Red-Hat-Bugzilla: #2070205 CVE: CVE-2022-1184 Signed-off-by: NLukas Czerner <lczerner@redhat.com> Cc: stable@vger.kernel.org Reviewed-by: NAndreas Dilger <adilger@dilger.ca> Link: https://lore.kernel.org/r/20220704142721.157985-1-lczerner@redhat.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu> Signed-off-by: NBaokun Li <libaokun1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ding Xiang 提交于
stable inclusion from stable-v5.10.124 commit 0ca74dacfd478a9c03361b7512be48ea6b22e8a5 category: bugfix bugzilla: 186639, https://gitee.com/openeuler/kernel/issues/I58WSQ CVE: CVE-2022-1184 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0ca74dacfd478a9c03361b7512be48ea6b22e8a5 -------------------------------- commit bc75a6eb upstream. Since dx_make_map() may return -EFSCORRUPTED now, so change "count" to be a signed integer so we can correctly check for an error code returned by dx_make_map(). Fixes: 46c116b9 ("ext4: verify dir block before splitting it") Cc: stable@kernel.org Signed-off-by: NDing Xiang <dingxiang@cmss.chinamobile.com> Link: https://lore.kernel.org/r/20220530100047.537598-1-dingxiang@cmss.chinamobile.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NBaokun Li <libaokun1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Kunkun Jiang 提交于
virt inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5UN39 CVE: NA ------------------------------ Two redundant arguements are added to 'iommu_device_register' of 'include/linux/iommu.h' in the commit bbf3b39e ("iommu: Introduce dirty log tracking framework"). As a result, compiling the kernel fails when the CONFIG_IOMMU_API is disabled. Delete the two redundant arguements to solve this problem. Fixes: bbf3b39e ("iommu: Introduce dirty log tracking framework") Reported-by: NYejian Zheng <zhengyejian1@huawei.com> Signed-off-by: NKunkun Jiang <jiangkunkun@huawei.com> Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sasha Levin 提交于
stable inclusion from stable-v5.4.215 commit 4051324a6dafd7053c74c475e80b3ba10ae672b0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5T9C3 CVE: CVE-2022-3303 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs?h=v6.0-rc5&id=8423f0b6d513b259fdab9c9bf4aaa6188d054c2d --------------------------- [ Upstream commit 8423f0b6 ] There is a small race window at snd_pcm_oss_sync() that is called from OSS PCM SNDCTL_DSP_SYNC ioctl; namely the function calls snd_pcm_oss_make_ready() at first, then takes the params_lock mutex for the rest. When the stream is set up again by another thread between them, it leads to inconsistency, and may result in unexpected results such as NULL dereference of OSS buffer as a fuzzer spotted recently. The fix is simply to cover snd_pcm_oss_make_ready() call into the same params_lock mutex with snd_pcm_oss_make_ready_locked() variant. Reported-and-tested-by: Nbutt3rflyh4ck <butterflyhuangxx@gmail.com> Reviewed-by: NJaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA@mail.gmail.com Link: https://lore.kernel.org/r/20220905060714.22549-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NXia Longlong <xialonglong1@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Tejun Heo 提交于
mainline inclusion from mainline-v5.13-rc1 commit f46ec84b category: bugfix bugzilla: 187443, https://gitee.com/openeuler/kernel/issues/I5PFPV CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f46ec84b5acbf8d7067d71a6bbdde213d4b86036 ---------------------------------------------------------------------- ioc_adjust_base_vrate() ignored vrate_min when rq_wait_pct indicates that there is QD contention. The reasoning was that QD depletion always reliably indicates device saturation and thus it's safe to override user specified vrate_min. However, this sometimes leads to unnecessary throttling, especially on really fast devices, because vrate adjustments have delays and inertia. It also confuses users because the behavior violates the explicitly specified configuration. This patch drops the special case handling so that vrate_min is always applied. Signed-off-by: NTejun Heo <tj@kernel.org> Link: https://lore.kernel.org/r/YIIo1HuyNmhDeiNx@slm.duckdns.orgSigned-off-by: NJens Axboe <axboe@kernel.dk> confilict: block/blk-iocost.c Signed-off-by: NLi Nan <linan122@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 11 10月, 2022 1 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @xin3liang Enable NVMe over TCP for arm64. Link:https://gitee.com/openeuler/kernel/pulls/157 Reviewed-by: Liu Chao <liuchao173@huawei.com> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
- 08 10月, 2022 1 次提交
-
-
由 Xinliang Liu 提交于
openEuler inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5SBW1 CVE: NA -------------------------------- Enable NVMe over TCP for arm64. Signed-off-by: NXinliang Liu <xinliang.liu@linaro.org>
-
- 27 9月, 2022 32 次提交
-
-
由 Keqian Zhu 提交于
mainline inclusion from mainline-v5.14-rc1 commit 2aa53d68 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5R1MW CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2aa53d68cee6 ------------------------------------------------------------------ The MMIO region of a device maybe huge (GB level), try to use block mapping in stage2 to speedup both map and unmap. Compared to normal memory mapping, we should consider two more points when try block mapping for MMIO region: 1. For normal memory mapping, the PA(host physical address) and HVA have same alignment within PUD_SIZE or PMD_SIZE when we use the HVA to request hugepage, so we don't need to consider PA alignment when verifing block mapping. But for device memory mapping, the PA and HVA may have different alignment. 2. For normal memory mapping, we are sure hugepage size properly fit into vma, so we don't check whether the mapping size exceeds the boundary of vma. But for device memory mapping, we should pay attention to this. This adds get_vma_page_shift() to get page shift for both normal memory and device MMIO region, and check these two points when selecting block mapping size for MMIO region. Signed-off-by: NKeqian Zhu <zhukeqian1@huawei.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Signed-off-by: NHeng Zhang <zhangheng191@h-partners.com> Link: https://lore.kernel.org/r/20210507110322.23348-3-zhukeqian1@huawei.comReviewed-by: NKeqian Zhu <zhukeqian1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Keqian Zhu 提交于
mainline inclusion from mainline-v5.14-rc1 commit fd6f17ba category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5R1MW CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fd6f17bade21 --------------------------------------------------------------------- The MMIO regions may be unmapped for many reasons and can be remapped by stage2 fault path. Map MMIO regions at creation time becomes a minor optimization and makes these two mapping path hard to sync. Remove the mapping code while keep the useful sanity check. Signed-off-by: NKeqian Zhu <zhukeqian1@huawei.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Signed-off-by: NHeng Zhang <zhangheng191@h-partners.com> Link: https://lore.kernel.org/r/20210507110322.23348-2-zhukeqian1@huawei.comReviewed-by: NKeqian Zhu <zhukeqian1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Baokun Li 提交于
hulk inclusion category: bugfix bugzilla: 187600, https://gitee.com/openeuler/kernel/issues/I5SV2U CVE: NA -------------------------------- If the starting position of our insert range happens to be in the hole between the two ext4_extent_idx, because the lblk of the ext4_extent in the previous ext4_extent_idx is always less than the start, which leads to the "extent" variable access across the boundary, the following UAF is triggered: ================================================================== BUG: KASAN: use-after-free in ext4_ext_shift_extents+0x257/0x790 Read of size 4 at addr ffff88819807a008 by task fallocate/8010 CPU: 3 PID: 8010 Comm: fallocate Tainted: G E 5.10.0+ #492 Call Trace: dump_stack+0x7d/0xa3 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x67/0x7f ext4_ext_shift_extents+0x257/0x790 ext4_insert_range+0x5b6/0x700 ext4_fallocate+0x39e/0x3d0 vfs_fallocate+0x26f/0x470 ksys_fallocate+0x3a/0x70 __x64_sys_fallocate+0x4f/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ================================================================== For right shifts, we can divide them into the following situations: 1. When the first ee_block of ext4_extent_idx is greater than or equal to start, make right shifts directly from the first ee_block. 1) If it is greater than start, we need to continue searching in the previous ext4_extent_idx. 2) If it is equal to start, we can exit the loop (iterator=NULL). 2. When the first ee_block of ext4_extent_idx is less than start, then traverse from the last extent to find the first extent whose ee_block is less than start. 1) If extent is still the last extent after traversal, it means that the last ee_block of ext4_extent_idx is less than start, that is, start is located in the hole between idx and (idx+1), so we can exit the loop directly (break) without right shifts. 2) Otherwise, make right shifts at the corresponding position of the found extent, and then exit the loop (iterator=NULL). Fixes: 331573fe ("ext4: Add support FALLOC_FL_INSERT_RANGE for fallocate") Cc: stable@vger.kernel.org Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com> Signed-off-by: NBaokun Li <libaokun1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zhen Lei 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5P8OD CVE: NA ------------------------------------------------------------------------- The value of 'end' for both for_each_mem_range() and __map_memblock() is 'start + size', not 'start + size - 1'. So if the end value of a memory block is 4G, then: if (eflags && (end >= SZ_4G)) { //end=SZ_4G if (start < SZ_4G) { ... ... start = SZ_4G; } } //Now, start=end=SZ_4G, all [start,...) will be mapped __map_memblock(pgdp, start, end, ..xxx..); Fixes: e26eee76 ("arm64: kdump: Don't force page-level mappings for memory above 4G") Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Like Xu 提交于
mainline inclusion from mainline-v5.18 commit 75189d1d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5RD6Y CVE: NA ------------- NMI-watchdog is one of the favorite features of kernel developers, but it does not work in AMD guest even with vPMU enabled and worse, the system misrepresents this capability via /proc. This is a PMC emulation error. KVM does not pass the latest valid value to perf_event in time when guest NMI-watchdog is running, thus the perf_event corresponding to the watchdog counter will enter the old state at some point after the first guest NMI injection, forcing the hardware register PMC0 to be constantly written to 0x800000000001. Meanwhile, the running counter should accurately reflect its new value based on the latest coordinated pmc->counter (from vPMC's point of view) rather than the value written directly by the guest. Fixes: 168d918f ("KVM: x86: Adjust counter sample period after a wrmsr") Reported-by: NDongli Cao <caodongli@kingsoft.com> Signed-off-by: NLike Xu <likexu@tencent.com> Reviewed-by: NYanan Wang <wangyanan55@huawei.com> Tested-by: NYanan Wang <wangyanan55@huawei.com> Reviewed-by: NJim Mattson <jmattson@google.com> Message-Id: <20220409015226.38619-1-likexu@tencent.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: Nyezengruan <yezengruan@huawei.com> Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Like Xu 提交于
mainline inclusion from mainline-v5.14 commit e79f49c3 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5RD6Y CVE: NA ------------- Based on our observations, after any vm-exit associated with vPMU, there are at least two or more perf interfaces to be called for guest counter emulation, such as perf_event_{pause, read_value, period}(), and each one will {lock, unlock} the same perf_event_ctx. The frequency of calls becomes more severe when guest use counters in a multiplexed manner. Holding a lock once and completing the KVM request operations in the perf context would introduce a set of impractical new interfaces. So we can further optimize the vPMU implementation by avoiding repeated calls to these interfaces in the KVM context for at least one pattern: After we call perf_event_pause() once, the event will be disabled and its internal count will be reset to 0. So there is no need to pause it again or read its value. Once the event is paused, event period will not be updated until the next time it's resumed or reprogrammed. And there is also no need to call perf_event_period twice for a non-running counter, considering the perf_event for a running counter is never paused. Based on this implementation, for the following common usage of sampling 4 events using perf on a 4u8g guest: echo 0 > /proc/sys/kernel/watchdog echo 25 > /proc/sys/kernel/perf_cpu_time_max_percent echo 10000 > /proc/sys/kernel/perf_event_max_sample_rate echo 0 > /proc/sys/kernel/perf_cpu_time_max_percent for i in `seq 1 1 10` do taskset -c 0 perf record \ -e cpu-cycles -e instructions -e branch-instructions -e cache-misses \ /root/br_instr a done the average latency of the guest NMI handler is reduced from 37646.7 ns to 32929.3 ns (~1.14x speed up) on the Intel ICX server. Also, in addition to collecting more samples, no loss of sampling accuracy was observed compared to before the optimization. Signed-off-by: NLike Xu <likexu@tencent.com> Message-Id: <20210728120705.6855-1-likexu@tencent.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Acked-by: NPeter Zijlstra <peterz@infradead.org> Signed-off-by: Nyezengruan <yezengruan@huawei.com> Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Stephen Rothwell 提交于
mainline inclusion from mainline-remotes/origin/next commit 366317ea category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5RP8T CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/commit/?id=366317eae983a0d96aeed78ad219b9c4ed2a719a -------------------------------------------------------------------------- drivers/hwtracing/ptt/hisi_ptt.c:13:10: fatal error: linux/dma-iommu.h: No such file or directory 13 | #include <linux/dma-iommu.h> | ^~~~~~~~~~~~~~~~~~~ Caused by: commit ff0de066 ("hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe Tune and Trace device") interacting with: commit f2042ed2 ("iommu/dma: Make header private") from the iommu tree. Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Acked-by: NRobin Murphy <robin.murphy@arm.com> Acked-by: NYicong Yang <yangyicong@hisilicon.com> [Fixed subject line and added changelog text] Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yicong Yang 提交于
mainline inclusion from mainline-remotes/origin/next commit 366317ea category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5RP8T CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/commit/?id=366317eae983a0d96aeed78ad219b9c4ed2a719a -------------------------------------------------------------------------- Add maintainer for driver and documentation of HiSilicon PTT device. Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20220816114414.4092-6-yangyicong@huawei.comSigned-off-by: NMathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yicong Yang 提交于
mainline inclusion from mainline-remotes/origin/next commit a7112b74 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5RP8T CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/commit/?id=a7112b747c324dda8937d4f47b14dc0af0b465d1 -------------------------------------------------------------------------- Document the introduction and usage of HiSilicon PTT device driver as well as the sysfs attributes description provided by the driver. Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NBagas Sanjaya <bagasdotme@gmail.com> [Fixed month and kernel version] Link: https://lore.kernel.org/r/20220816114414.4092-5-yangyicong@huawei.comSigned-off-by: NMathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yicong Yang 提交于
mainline inclusion from mainline-remotes/origin/next commit 5ca57b03 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5RP8T CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/commit/?id=5ca57b03d8c5de4c59234cc11fe9dd9f13d57f48 -------------------------------------------------------------------------- Add tune function for the HiSilicon Tune and Trace device. The interface of tune is exposed through sysfs attributes of PTT PMU device. Acked-by: NMathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NJohn Garry <john.garry@huawei.com> Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20220816114414.4092-4-yangyicong@huawei.comSigned-off-by: NMathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yicong Yang 提交于
mainline inclusion from mainline-remotes/origin/next commit ff0de066 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5RP8T CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/commit/?id=ff0de066b4632ccb2b2e50f90c0c5be7f4689de7 -------------------------------------------------------------------------- HiSilicon PCIe tune and trace device(PTT) is a PCIe Root Complex integrated Endpoint(RCiEP) device, providing the capability to dynamically monitor and tune the PCIe traffic and trace the TLP headers. Add the driver for the device to enable the trace function. Register PMU device of PTT trace, then users can use trace through perf command. The driver makes use of perf AUX trace function and support the following events to configure the trace: - filter: select Root port or Endpoint to trace - type: select the type of traced TLP headers - direction: select the direction of traced TLP headers - format: select the data format of the traced TLP headers This patch initially add basic trace support of PTT device. Acked-by: NMathieu Poirier <mathieu.poirier@linaro.org> Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: NJohn Garry <john.garry@huawei.com> Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/20220816114414.4092-3-yangyicong@huawei.comSigned-off-by: NMathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yicong Yang 提交于
mainline inclusion from mainline-remotes/origin/next commit 24b6c779 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5RP8T CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux.git/commit/?id=24b6c7798a0122012ca848ea0d25e973334266b0 -------------------------------------------------------------------------- The DMA operations of HiSilicon PTT device can only work properly with identical mappings. So add a quirk for the device to force the domain as passthrough. Acked-by: NWill Deacon <will@kernel.org> Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Reviewed-by: NJohn Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/20220816114414.4092-2-yangyicong@huawei.comSigned-off-by: NMathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NHanjun Guo <guohanjun@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yicong Yang 提交于
mainline inclusion from mainline-v5.12-rc1 commit 6d2386e3 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5QUS6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6d2386e36440 -------------------------------------------------------------------------- The address mode is either 3 or 4 for the controller, which is configured by the firmware and cannot be modified in the OS driver. Get the firmware configuration and add address mode check in the .supports_op() to block invalid operations. Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Acked-by: NJohn Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/1611740450-47975-3-git-send-email-yangyicong@hisilicon.comSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NYicong Yang <yangyicong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yicong Yang 提交于
mainline inclusion from mainline-v5.13-rc1 commit 4c84e42d category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5QUS6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4c84e42d29af -------------------------------------------------------------------------- We mask the irq when the command completion is timeout. This won't stop the already running irq handler. Use sychronize_irq() after we mask the irq, to make sure there is no running handler. Acked-by: NJohn Garry <john.garry@huawei.com> Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/1618228708-37949-2-git-send-email-yangyicong@hisilicon.comSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NYicong Yang <yangyicong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yicong Yang 提交于
mainline inclusion from mainline-v5.13-rc1 commit 4a46f886 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5QUS6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4a46f88681ca -------------------------------------------------------------------------- We use ACPI_PTR() and related ifendif protection for the id table. This is unnecessary as the struct acpi_device_id is defined in mod_devicetable.h and doesn't rely on ACPI. The driver doesn't use any ACPI apis, so it can be compiled in the ACPI=n case with no warnings. So remove the ACPI_PTR and related ifendif protection, also replace the header acpi.h with mod_devicetable.h. Acked-by: NJohn Garry <john.garry@huawei.com> Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Link: https://lore.kernel.org/r/1618228708-37949-3-git-send-email-yangyicong@hisilicon.comSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NYicong Yang <yangyicong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yicong Yang 提交于
mainline inclusion from mainline-v5.12-rc1 commit 566c6120 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5QUS6 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=566c6120f095 -------------------------------------------------------------------------- Currently we use concrete version to determine the max_cmd_dword. New entries should be added for compatible hardwares of new version or on new platform, otherwise the device will use 16 dwords instead of 64 even if it supports, which will degrade the performance. This will decrease the compatibility and the maintainability. Drop the switch-case statement of the version checking. Only version less than 0x351 supports maximum 16 command dwords. Signed-off-by: NYicong Yang <yangyicong@hisilicon.com> Acked-by: NJohn Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/1610526716-14882-1-git-send-email-yangyicong@hisilicon.comSigned-off-by: NMark Brown <broonie@kernel.org> Signed-off-by: NWangming Shao <shaowangming@h-partners.com> Reviewed-by: NYicong Yang <yangyicong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jann Horn 提交于
stable inclusion from stable-v5.10.142 commit 895428ee124ad70b9763259308354877b725c31d category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5PE9S CVE: CVE-2022-39188 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=895428ee124ad70b9763259308354877b725c31d -------------------------------- commit b67fbebd upstream. Some drivers rely on having all VMAs through which a PFN might be accessible listed in the rmap for correctness. However, on X86, it was possible for a VMA with stale TLB entries to not be listed in the rmap. This was fixed in mainline with commit b67fbebd ("mmu_gather: Force tlb-flush VM_PFNMAP vmas"), but that commit relies on preceding refactoring in commit 18ba064e ("mmu_gather: Let there be one tlb_{start,end}_vma() implementation") and commit 1e9fdf21 ("mmu_gather: Remove per arch tlb_{start,end}_vma()"). This patch provides equivalent protection without needing that refactoring, by forcing a TLB flush between removing PTEs in unmap_vmas() and the call to unlink_file_vma() in free_pgtables(). [This is a stable-specific rewrite of the upstream commit!] Signed-off-by: NJann Horn <jannh@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Nze zuo <zuoze1@huawei.com> Reviewed-by: NChen Wandun <chenwandun@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zheng Zengkai 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ CVE: NA --------------------------------------- In struct cfs_rq, the name of 'throttled_clock_pelt' and 'throttled_clock_pelt_time' changed causing kabi broken, use KABI_REPLACE to fix it. Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Signed-off-by: NWang Hai <wanghai38@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Chengming Zhou 提交于
stable inclusion from stable-v5.10.121 commit 147a376c1afea117eccda36451121ea781aa5028 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=147a376c1afea117eccda36451121ea781aa5028 -------------------------------- [ Upstream commit 64eaf507 ] Since commit 23127296 ("sched/fair: Update scale invariance of PELT") change to use rq_clock_pelt() instead of rq_clock_task(), we should also use rq_clock_pelt() for throttled_clock_task_time and throttled_clock_task accounting to get correct cfs_rq_clock_pelt() of throttled cfs_rq. And rename throttled_clock_task(_time) to be clock_pelt rather than clock_task. Fixes: 23127296 ("sched/fair: Update scale invariance of PELT") Signed-off-by: NChengming Zhou <zhouchengming@bytedance.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NBen Segall <bsegall@google.com> Reviewed-by: NVincent Guittot <vincent.guittot@linaro.org> Link: https://lore.kernel.org/r/20220408115309.81603-1-zhouchengming@bytedance.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Eric Biggers 提交于
stable inclusion from stable-v5.10.121 commit a67100f42665cf7a5ed7821376140f62def0d31e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a67100f42665cf7a5ed7821376140f62def0d31e -------------------------------- commit 5f41fdae upstream. Make the test_dummy_encryption mount option require that the encrypt feature flag be already enabled on the filesystem, rather than automatically enabling it. Practically, this means that "-O encrypt" will need to be included in MKFS_OPTIONS when running xfstests with the test_dummy_encryption mount option. (ext4/053 also needs an update.) Moreover, as long as the preconditions for test_dummy_encryption are being tightened anyway, take the opportunity to start rejecting it when !CONFIG_FS_ENCRYPTION rather than ignoring it. The motivation for requiring the encrypt feature flag is that: - Having the filesystem auto-enable feature flags is problematic, as it bypasses the usual sanity checks. The specific issue which came up recently is that in kernel versions where ext4 supports casefold but not encrypt+casefold (v5.1 through v5.10), the kernel will happily add the encrypt flag to a filesystem that has the casefold flag, making it unmountable -- but only for subsequent mounts, not the initial one. This confused the casefold support detection in xfstests, causing generic/556 to fail rather than be skipped. - The xfstests-bld test runners (kvm-xfstests et al.) already use the required mkfs flag, so they will not be affected by this change. Only users of test_dummy_encryption alone will be affected. But, this option has always been for testing only, so it should be fine to require that the few users of this option update their test scripts. - f2fs already requires it (for its equivalent feature flag). Signed-off-by: NEric Biggers <ebiggers@google.com> Reviewed-by: NGabriel Krisman Bertazi <krisman@collabora.com> Link: https://lore.kernel.org/r/20220519204437.61645-1-ebiggers@kernel.orgSigned-off-by: NTheodore Ts'o <tytso@mit.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Conflicts: fs/ext4/super.c Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Maciej W. Rozycki 提交于
stable inclusion from stable-v5.10.121 commit 96662c77466dfc2285519c87a2b955bb2d4f5278 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=96662c77466dfc2285519c87a2b955bb2d4f5278 -------------------------------- commit f44b3e74 upstream. Remove unsupported forcing of `cpu_has_fpu' to 1, which makes the `nofpu' kernel parameter non-functional, and also causes a link error: ld: arch/mips/kernel/traps.o: in function `trap_init': ./arch/mips/include/asm/msa.h:(.init.text+0x348): undefined reference to `handle_fpe' ld: ./arch/mips/include/asm/msa.h:(.init.text+0x354): undefined reference to `handle_fpe' ld: ./arch/mips/include/asm/msa.h:(.init.text+0x360): undefined reference to `handle_fpe' where the CONFIG_MIPS_FP_SUPPORT configuration option has been disabled. Signed-off-by: NMaciej W. Rozycki <macro@orcam.me.uk> Reported-by: NStephen Zhang <starzhangzsd@gmail.com> Fixes: 7505576d ("MIPS: add support for SGI Octane (IP30)") Cc: stable@vger.kernel.org # v5.5+ Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Maciej W. Rozycki 提交于
stable inclusion from stable-v5.10.121 commit 57e561573f2e51f9f53428caa17eae6a7090f0f5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=57e561573f2e51f9f53428caa17eae6a7090f0f5 -------------------------------- commit 424c3781 upstream. Remove unsupported forcing of `cpu_has_fpu' to 1, which makes the `nofpu' kernel parameter non-functional, and also causes a link error: ld: arch/mips/kernel/traps.o: in function `trap_init': ./arch/mips/include/asm/msa.h:(.init.text+0x348): undefined reference to `handle_fpe' ld: ./arch/mips/include/asm/msa.h:(.init.text+0x354): undefined reference to `handle_fpe' ld: ./arch/mips/include/asm/msa.h:(.init.text+0x360): undefined reference to `handle_fpe' where the CONFIG_MIPS_FP_SUPPORT configuration option has been disabled. Signed-off-by: NMaciej W. Rozycki <macro@orcam.me.uk> Reported-by: NStephen Zhang <starzhangzsd@gmail.com> Fixes: 0ebb2f41 ("MIPS: IP27: Update/restructure CPU overrides") Cc: stable@vger.kernel.org # v4.2+ Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Xiao Yang 提交于
stable inclusion from stable-v5.10.121 commit bb55ca1612923b06c4d86ab28b8dd8fdca55ced1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb55ca1612923b06c4d86ab28b8dd8fdca55ced1 -------------------------------- commit 2f917af7 upstream. Current rxe_requester() doesn't generate a completion when processing an unsupported/invalid opcode. If rxe driver doesn't support a new opcode (e.g. RDMA Atomic Write) and RDMA library supports it, an application using the new opcode can reproduce this issue. Fix the issue by calling "goto err;". Fixes: 8700e3e7 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20220410113513.27537-1-yangx.jy@fujitsu.comSigned-off-by: NXiao Yang <yangx.jy@fujitsu.com> Signed-off-by: NJason Gunthorpe <jgg@nvidia.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Jason A. Donenfeld 提交于
stable inclusion from stable-v5.10.121 commit 72268945b124cd61336f9b4cac538b0516399a2d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=72268945b124cd61336f9b4cac538b0516399a2d -------------------------------- This reverts upstream commit f5bda35f from stable. It's not essential and will take some time during 5.19 to work out properly. Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Jan Kara 提交于
stable inclusion from stable-v5.10.121 commit 6b03dc67dde3811b11125b089bec876f1a9806b7 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6b03dc67dde3811b11125b089bec876f1a9806b7 -------------------------------- commit 22b106e5 upstream. Commit d92c370a ("block: really clone the block cgroup in bio_clone_blkg_association") changed bio_clone_blkg_association() to just clone bio->bi_blkg reference from source to destination bio. This is however wrong if the source and destination bios are against different block devices because struct blkcg_gq is different for each bdev-blkcg pair. This will result in IOs being accounted (and throttled as a result) multiple times against the same device (src bdev) while throttling of the other device (dst bdev) is ignored. In case of BFQ the inconsistency can even result in crashes in bfq_bic_update_cgroup(). Fix the problem by looking up correct blkcg_gq for the cloned bio. Reported-by: NLogan Gunthorpe <logang@deltatee.com> Reported-and-tested-by: NDonald Buczek <buczek@molgen.mpg.de> Fixes: d92c370a ("block: really clone the block cgroup in bio_clone_blkg_association") CC: stable@vger.kernel.org Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NJan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220602081242.7731-1-jack@suse.czSigned-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Jan Kara 提交于
stable inclusion from stable-v5.10.121 commit 80b0a2b3dfea5de3224ba756830b9243709c6e9e category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=80b0a2b3dfea5de3224ba756830b9243709c6e9e -------------------------------- commit 5f550ede upstream. We call bfq_init_rq() from request merging functions where requests we get should have already gone through bfq_init_rq() during insert and anyway we want to do anything only if the request is already tracked by BFQ. So replace calls to bfq_init_rq() with RQ_BFQQ() instead to simply skip requests untracked by BFQ. We move bfq_init_rq() call in bfq_insert_request() a bit earlier to cover request merging and thus can transfer FIFO position in case of a merge. CC: stable@vger.kernel.org Tested-by: N"yukuai (C)" <yukuai3@huawei.com> Signed-off-by: NJan Kara <jack@suse.cz> Reviewed-by: NChristoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220401102752.8599-6-jack@suse.czSigned-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Conflicts: block/bfq-iosched.c Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Jan Kara 提交于
stable inclusion from stable-v5.10.121 commit 13599aac1b983341a1240199e461bf1a8ee55dfb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=13599aac1b983341a1240199e461bf1a8ee55dfb -------------------------------- commit fc84e1f9 upstream. In bfq_insert_request() we unlock bfqd->lock only to call trace_block_rq_insert() and then lock bfqd->lock again. This is really pointless since tracing is disabled if we really care about performance and even if the tracepoint is enabled, it is a quick call. CC: stable@vger.kernel.org Tested-by: N"yukuai (C)" <yukuai3@huawei.com> Signed-off-by: NJan Kara <jack@suse.cz> Reviewed-by: NChristoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220401102752.8599-5-jack@suse.czSigned-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Jan Kara 提交于
stable inclusion from stable-v5.10.121 commit 7d172b9dc913e161d8ff88770eea01701ff553de category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7d172b9dc913e161d8ff88770eea01701ff553de -------------------------------- commit c1cee4ab upstream. It can happen that the parent of a bfqq changes between the moment we decide two queues are worth to merge (and set bic->stable_merge_bfqq) and the moment bfq_setup_merge() is called. This can happen e.g. because the process submitted IO for a different cgroup and thus bfqq got reparented. It can even happen that the bfqq we are merging with has parent cgroup that is already offline and going to be destroyed in which case the merge can lead to use-after-free issues such as: BUG: KASAN: use-after-free in __bfq_deactivate_entity+0x9cb/0xa50 Read of size 8 at addr ffff88800693c0c0 by task runc:[2:INIT]/10544 CPU: 0 PID: 10544 Comm: runc:[2:INIT] Tainted: G E 5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (unreleased) f1f3b891c72369aebecd2e43e4641a6358867c70 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x46/0x5a print_address_description.constprop.0+0x1f/0x140 ? __bfq_deactivate_entity+0x9cb/0xa50 kasan_report.cold+0x7f/0x11b ? __bfq_deactivate_entity+0x9cb/0xa50 __bfq_deactivate_entity+0x9cb/0xa50 ? update_curr+0x32f/0x5d0 bfq_deactivate_entity+0xa0/0x1d0 bfq_del_bfqq_busy+0x28a/0x420 ? resched_curr+0x116/0x1d0 ? bfq_requeue_bfqq+0x70/0x70 ? check_preempt_wakeup+0x52b/0xbc0 __bfq_bfqq_expire+0x1a2/0x270 bfq_bfqq_expire+0xd16/0x2160 ? try_to_wake_up+0x4ee/0x1260 ? bfq_end_wr_async_queues+0xe0/0xe0 ? _raw_write_unlock_bh+0x60/0x60 ? _raw_spin_lock_irq+0x81/0xe0 bfq_idle_slice_timer+0x109/0x280 ? bfq_dispatch_request+0x4870/0x4870 __hrtimer_run_queues+0x37d/0x700 ? enqueue_hrtimer+0x1b0/0x1b0 ? kvm_clock_get_cycles+0xd/0x10 ? ktime_get_update_offsets_now+0x6f/0x280 hrtimer_interrupt+0x2c8/0x740 Fix the problem by checking that the parent of the two bfqqs we are merging in bfq_setup_merge() is the same. Link: https://lore.kernel.org/linux-block/20211125172809.GC19572@quack2.suse.cz/ CC: stable@vger.kernel.org Fixes: 430a67f9 ("block, bfq: merge bursts of newly-created queues") Tested-by: N"yukuai (C)" <yukuai3@huawei.com> Signed-off-by: NJan Kara <jack@suse.cz> Reviewed-by: NChristoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20220401102752.8599-2-jack@suse.czSigned-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Daniel Lezcano 提交于
stable inclusion from stable-v5.10.121 commit 54cdc10ac7184f2159a4f5658b497e90244d1516 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=54cdc10ac7184f2159a4f5658b497e90244d1516 -------------------------------- commit d44616c6 upstream. Fix the following error: smatch warnings: drivers/thermal/thermal_core.c:1020 __thermal_cooling_device_register() warn: possible memory leak of 'cdev' by freeing the cdev when exiting the function in the error path. Fixes: 58483761 ("thermal/drivers/core: Use a char pointer for the cooling device name") Reported-by: Nkernel test robot <lkp@intel.com> Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20210319202257.890848-1-daniel.lezcano@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Ziyang Xuan 提交于
stable inclusion from stable-v5.10.121 commit b132abaa6515e14e0db292389c25007d666e1925 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b132abaa6515e14e0db292389c25007d666e1925 -------------------------------- commit 0a5c2671 upstream. When device_register() return failed, program will goto out_kfree_type to release 'cdev->device' by put_device(). That will call thermal_release() to free 'cdev'. But the follow-up processes access 'cdev' continually. That trggers the UAF bug. Acked-by: NXie XiuQi <xiexiuqi@huawei.com> ==================================================================== BUG: KASAN: use-after-free in __thermal_cooling_device_register+0x75b/0xa90 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack_lvl+0xe2/0x152 print_address_description.constprop.0+0x21/0x140 ? __thermal_cooling_device_register+0x75b/0xa90 kasan_report.cold+0x7f/0x11b ? __thermal_cooling_device_register+0x75b/0xa90 __thermal_cooling_device_register+0x75b/0xa90 ? memset+0x20/0x40 ? __sanitizer_cov_trace_pc+0x1d/0x50 ? __devres_alloc_node+0x130/0x180 devm_thermal_of_cooling_device_register+0x67/0xf0 max6650_probe.cold+0x557/0x6aa ...... Freed by task 258: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x109/0x140 kfree+0x117/0x4c0 thermal_release+0xa0/0x110 device_release+0xa7/0x240 kobject_put+0x1ce/0x540 put_device+0x20/0x30 __thermal_cooling_device_register+0x731/0xa90 devm_thermal_of_cooling_device_register+0x67/0xf0 max6650_probe.cold+0x557/0x6aa [max6650] Do not use 'cdev' again after put_device() to fix the problem like doing in thermal_zone_device_register(). [dlezcano]: as requested by Rafael, change the affectation into two statements. Fixes: 58483761 ("thermal/drivers/core: Use a char pointer for the cooling device name") Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com> Reported-by: Nkernel test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20211015024504.947520-1-william.xuanziyang@huawei.comSigned-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Waiman Long 提交于
stable inclusion from stable-v5.10.121 commit ec1378f2fa36f6e4a5042cca5ad6f415038dcda1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ec1378f2fa36f6e4a5042cca5ad6f415038dcda1 -------------------------------- commit 213adc63 upstream. Commit 54de76c0 ("kselftest/cgroup: fix test_stress.sh to use OUTPUT dir") changes the test_core command path from . to $OUTPUT. However, variable OUTPUT may not be defined if the command is run interactively. Fix that by using ${OUTPUT:-.} to cover both cases. Signed-off-by: NWaiman Long <longman@redhat.com> Signed-off-by: NTejun Heo <tj@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-
由 Dave Chinner 提交于
stable inclusion from stable-v5.10.121 commit 82b2b60b6745418d34e5fd48948cac853449579f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5L6CQ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=82b2b60b6745418d34e5fd48948cac853449579f -------------------------------- commit 56486f30 upstream. xfs/538 on a 1kB block filesystem failed with this assert: XFS: Assertion failed: cur->bc_btnum != XFS_BTNUM_BMAP || cur->bc_ino.allocated == 0 || xfs_is_shutdown(cur->bc_mp), file: fs/xfs/libxfs/xfs_btree.c, line: 448 The problem was that an allocation failed unexpectedly in xfs_bmbt_alloc_block() after roughly 150,000 minlen allocation error injections, resulting in an EFSCORRUPTED error being returned to xfs_bmapi_write(). The error occurred on extent-to-btree format conversion allocating the new root block: RIP: 0010:xfs_bmbt_alloc_block+0x177/0x210 Call Trace: <TASK> xfs_btree_new_iroot+0xdf/0x520 xfs_btree_make_block_unfull+0x10d/0x1c0 xfs_btree_insrec+0x364/0x790 xfs_btree_insert+0xaa/0x210 xfs_bmap_add_extent_hole_real+0x1fe/0x9a0 xfs_bmapi_allocate+0x34c/0x420 xfs_bmapi_write+0x53c/0x9c0 xfs_alloc_file_space+0xee/0x320 xfs_file_fallocate+0x36b/0x450 vfs_fallocate+0x148/0x340 __x64_sys_fallocate+0x3c/0x70 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa Why the allocation failed at this point is unknown, but is likely that we ran the transaction out of reserved space and filesystem out of space with bmbt blocks because of all the minlen allocations being done causing worst case fragmentation of a large allocation. Regardless of the cause, we've then called xfs_bmapi_finish() which calls xfs_btree_del_cursor(cur, error) to tear down the cursor. So we have a failed operation, error != 0, cur->bc_ino.allocated > 0 and the filesystem is still up. The assert fails to take into account that allocation can fail with an error and the transaction teardown will shut the filesystem down if necessary. i.e. the assert needs to check "|| error != 0" as well, because at this point shutdown is pending because the current transaction is dirty.... Signed-off-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: NDarrick J. Wong <djwong@kernel.org> Reviewed-by: NChristoph Hellwig <hch@lst.de> Signed-off-by: NDave Chinner <david@fromorbit.com> Signed-off-by: NAmir Goldstein <amir73il@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
-