- 23 12月, 2021 19 次提交
-
-
由 Xingang Wang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4L735 CVE: NA ------------------------------------------------- When group rmid changes, as introduced by 6bbf2791b ("mpam: Add support for group rmid modify") the sysfs monitor data file rmid needs to update as well. This add support for updating rmid for monitoring, and then resync the group configuration. When update failed, roll back to the previous rmid. Signed-off-by: NXingang Wang <wangxingang5@huawei.com> Reviewed-by: NWang ShaoBo <bobo.shaobowang@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xingang Wang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4L735 CVE: NA ------------------------------------------------- The mpam driver controls the allocation of rmid, however there are some ocassions that the partid and pmg of a group might come from elsewhere. This add support for group rmid modify. The sysfs rmid file is set to write accessible, and this add a write interface to accept rmid from user. When the rmid from user is different and valid, update the group with new rmid. When error occurs, rollback to old rmid. Signed-off-by: NXingang Wang <wangxingang5@huawei.com> Reviewed-by: NWang ShaoBo <bobo.shaobowang@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xingang Wang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4L735 CVE: NA ------------------------------------------------- The rdt_mon_capable should be enabled when the msmon_mbwu feature is supported, so that the mpam monitor function can be effective. Signed-off-by: NXingang Wang <wangxingang5@huawei.com> Reviewed-by: NWang ShaoBo <bobo.shaobowang@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xingang Wang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4L735 CVE: NA ------------------------------------------------- The user_mpam_en configuration is used to enable/disable whether SMMU mpam configuration will be used. If user_mpam_en is 1, the memory requests across SMMU will not carry the SMMU mpam configuration. Signed-off-by: NXingang Wang <wangxingang5@huawei.com> Reviewed-by: NZhen Lei <thunder.leizhen@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xingang Wang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4L735 CVE: NA ------------------------------------------------- Add interface to get mpam configuration of CD/STE context, use s1mpam to indicate whether partid and pmg from CD or STE. Signed-off-by: NXingang Wang <wangxingang5@huawei.com> Reviewed-by: NZhen Lei <thunder.leizhen@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xingang Wang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4L735 CVE: NA ------------------------------------------------- To support limiting qos of device, the partid and pmg need to be set into the SMMU STE/CD context. This introduce support of SMMU mpam feature and add interface to set mpam configuration in STE/CD. Signed-off-by: NXingang Wang <wangxingang5@huawei.com> Reviewed-by: NZhen Lei <thunder.leizhen@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Xingang Wang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4L735 CVE: NA ------------------------------------------------- This introduce support to set and get device configuration in iommu private driver. For example, when the smmu mpam configuration need to be set in the smmu driver, these interfaces will help. Signed-off-by: NXingang Wang <wangxingang5@huawei.com> Reviewed-by: NZhen Lei <thunder.leizhen@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Acked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Laibin Qiu 提交于
hulk inclusion category: bugfix bugzilla: 185857 https://gitee.com/openeuler/kernel/issues/I4MMUW CVE: NA -------------------------------- Now that we disable wbt by set WBT_STATE_OFF_DEFAULT in wbt_disable_default() when switch elevator to bfq. And when we remove scsi device, wbt will be enabled by wbt_enable_default. If it become false positive between wbt_wait() and wbt_track() when submit write request. The following is the scenario that triggered the problem. T1 T2 T3 elevator_switch_mq bfq_init_queue wbt_disable_default <= Set rwb->enable_state (OFF) Submit_bio blk_mq_make_request rq_qos_throttle <= rwb->enable_state (OFF) scsi_remove_device sd_remove del_gendisk blk_unregister_queue elv_unregister_queue wbt_enable_default <= Set rwb->enable_state (ON) q_qos_track <= rwb->enable_state (ON) ^^^^^^ this request will mark WBT_TRACKED without inflight add and will lead to drop rqw->inflight to -1 in wbt_done() which will trigger IO hung. Fix this by move wbt_enable_default() from elv_unregister to bfq_exit_queue(). Only re-enable wbt when bfq exit. Fixes: 76a80408 ("blk-wbt: make sure throttle is enabled properly") Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yufen Yu 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4JYYO?from=project-issue CVE: NA --------------------------- We get a NULL pointer dereference oops when test raid1 as follow: mdadm -CR /dev/md1 -l 1 -n 2 /dev/sd[ab] mdadm /dev/md1 -f /dev/sda mdadm /dev/md1 -r /dev/sda mdadm /dev/md1 -a /dev/sda sleep 5 mdadm /dev/md1 -f /dev/sdb mdadm /dev/md1 -r /dev/sdb mdadm /dev/md1 -a /dev/sdb After a disk(/dev/sda) has been removed, we add the disk to raid array again, which would trigger recovery action. Since the rdev current state is 'spare', read/write bio can be issued to the disk. Then we set the other disk (/dev/sdb) faulty. Since the raid array is now in degraded state and /dev/sdb is the only 'In_sync' disk, raid1_error() will return but without set faulty success. However, that can interrupt the recovery action and md_check_recovery will try to call remove_and_add_spares() to remove the spare disk. And the race condition between remove_and_add_spares() and raid1_write_request() in follow can cause NULL pointer dereference for conf->mirrors[i].rdev: raid1_write_request() md_check_recovery raid1_error() rcu_read_lock() rdev != NULL !test_bit(Faulty, &rdev->flags) conf->recovery_disabled= mddev->recovery_disabled; return busy remove_and_add_spares raid1_remove_disk rdev->nr_pending == 0 atomic_inc(&rdev->nr_pending); rcu_read_unlock() p->rdev=NULL conf->mirrors[i].rdev->data_offset NULL pointer deref!!! if (!test_bit(RemoveSynchronized, &rdev->flags)) synchronize_rcu(); p->rdev=rdev To fix the race condition, we add a new flag 'WantRemove' for rdev. Before access conf->mirrors[i].rdev, we need to ensure the rdev without 'WantRemove' bit. Link: https://marc.info/?l=linux-raid&m=156412052717709&w=2Reported-by: NZou Wei <zou_wei@huawei.com> Signed-off-by: NYufen Yu <yuyufen@huawei.com> Confilct: drivers/md/md.h Signed-off-by: NLaibin Qiu <qiulaibin@huawei.com> Reviewed-by: Nyuyufen <yuyufen@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lijun Fang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4M24Q CVE: NA ------------------------------------------------- Enable CONFIG_ASCEND_DVPP_MMAP by default y. Signed-off-by: NLijun Fang <fanglijun3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lijun Fang 提交于
ascend inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4M24Q CVE: NA ------------------------------------------------- The DvPP means Davinci Video Pre-Processor, add new config ASCEND_FEATURES and DVPP_MMAP to enable the DvPP features for Ascend platform. The DvPP could only use a limit range of virtual address, just like the Ascend310/910 could only use the 4 GB range of virtual address, so add a new mmap flag which is named MAP_DVPP to use the DvPP processor by mmap syscall, the new flag is only valid for Ascend platform. You should alloc the memory for dvpp like this: addr = mmap(NULL, length, PROT_READ, MAP_ANONYMOUS | MAP_DVPP, -1, 0); Signed-off-by: NLijun Fang <fanglijun3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zheng Zengkai 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4HDHZ CVE: NA ------------------------------------------------- For arm64 openeuler_defconfig: Change default page size from 64K to 4K, then enable CONFIG_ARM64_VA_BITS_48. Following configs are involved: CONFIG_ARM64_PAGE_SHIFT=12 CONFIG_ARM64_CONT_PTE_SHIFT=4 CONFIG_ARM64_CONT_PMD_SHIFT=4 CONFIG_ARCH_MMAP_RND_BITS_MIN=18 CONFIG_ARCH_MMAP_RND_BITS_MAX=33 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11 CONFIG_PGTABLE_LEVELS=4 CONFIG_ARM64_4K_PAGES=y CONFIG_ARM64_64K_PAGES=n CONFIG_ARM64_VA_BITS_48=y CONFIG_ARM64_VA_BITS_52=n CONFIG_ARM64_VA_BITS=48 CONFIG_ARM64_PA_BITS_48=y CONFIG_ARM64_PA_BITS_52=n CONFIG_ARM64_PA_BITS=48 CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_FORCE_MAX_ZONEORDER=11 CONFIG_ARCH_MMAP_RND_BITS=18 CONFIG_ARCH_MMAP_RND_COMPAT_BITS=11 Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zheng Zengkai 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4J6G3 CVE: NA ------------------------------------------------- As phytium 4-processor server may have 32 NUMA nodes, in order to support scalability in the future, adjust CONFIG_NODES_SHIFT to 7 to increase maximum number of NUMA Nodes available on the target system to 128 in advance for arm64 openeuler_defconfig. Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zheng Zengkai 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4J96Y CVE: NA ------------------------------------------------- Set CONFIG_NR_CPUS of openeuler_defconfig to 4096 to meet scalability requirement for arm64. Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Paul Moore 提交于
maillist inclusion category: bugfix bugzilla: 185906 https://gitee.com/openeuler/kernel/issues/I4N958?from=project-issue CVE: NA Reference: https://patchwork.kernel.org/project/linux-audit/patch/163949858723.23091.5301356986109432893.stgit@olly/ ------------------------------------------------------------------- Due to the audit control mutex necessary for serializing audit userspace messages we haven't been able to block/penalize userspace processes that attempt to send audit records while the system is under audit pressure. The result is that privileged userspace applications have a priority boost with respect to audit as they are not bound by the same audit queue throttling as the other tasks on the system. This patch attempts to restore some balance to the system when under audit pressure by blocking these privileged userspace tasks after they have finished their audit processing, and dropped the audit control mutex, but before they return to userspace. Reported-by: NGaosheng Cui <cuigaosheng1@huawei.com> Tested-by: NGaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by: NRichard Guy Briggs <rgb@redhat.com> Signed-off-by: NPaul Moore <paul@paul-moore.com> Signed-off-by: NCui GaoSheng <cuigaosheng1@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Paul Moore 提交于
maillist inclusion category: bugfix bugzilla: 185904 https://gitee.com/openeuler/kernel/issues/I4N958?from=project-issue CVE: NA Reference: https://patchwork.kernel.org/project/linux-audit/patch/163942029335.62691.7176083220772477830.stgit@olly/ ------------------------------------------------------------------- If the audit daemon were ever to get stuck in a stopped state the kernel's kauditd_thread() could get blocked attempting to send audit records to the userspace audit daemon. With the kernel thread blocked it is possible that the audit queue could grow unbounded as certain audit record generating events must be exempt from the queue limits else the system enter a deadlock state. This patch resolves this problem by lowering the kernel thread's socket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaks the kauditd_send_queue() function to better manage the various audit queues when connection problems occur between the kernel and the audit daemon. With this patch, the backlog may temporarily grow beyond the defined limits when the audit daemon is stopped and the system is under heavy audit pressure, but kauditd_thread() will continue to make progress and drain the queues as it would for other connection problems. For example, with the audit daemon put into a stopped state and the system configured to audit every syscall it was still possible to shutdown the system without a kernel panic, deadlock, etc.; granted, the system was slow to shutdown but that is to be expected given the extreme pressure of recording every syscall. The timeout value of HZ/10 was chosen primarily through experimentation and this developer's "gut feeling". There is likely no one perfect value, but as this scenario is limited in scope (root privileges would be needed to send SIGSTOP to the audit daemon), it is likely not worth exposing this as a tunable at present. This can always be done at a later date if it proves necessary. Cc: stable@vger.kernel.org Fixes: 5b52330b ("audit: fix auditd/kernel connection state tracking") Reported-by: NGaosheng Cui <cuigaosheng1@huawei.com> Tested-by: NGaosheng Cui <cuigaosheng1@huawei.com> Reviewed-by: NRichard Guy Briggs <rgb@redhat.com> Signed-off-by: NPaul Moore <paul@paul-moore.com> Signed-off-by: NCui GaoSheng <cuigaosheng1@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ye Bin 提交于
hulk inclusion category: bugfix bugzilla: 185870 https://gitee.com/openeuler/kernel/issues/I4M8IW?from=project-issue CVE: NA ----------------------------------------------------------- The maximum linear address is U32_MAX, when enabled kaslr, A small value should be taken between end_addr of initrd and U32_MAX when calculating the size of initrd. Fixes: c1a0cdb5 ("ARM: decompressor: add KASLR support") Signed-off-by: NYe Bin <yebin10@huawei.com> Signed-off-by: Nyangerkun <yangerkun@huawei.com> Signed-off-by: NCui GaoSheng <cuigaosheng1@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ma Hai 提交于
mainline inclusion from mainline-v5.12-rc2 commit a0d078d0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4M6CD?from=project-issue CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/hisilicon/hibmc?h=v5.12-rc2&id=a0d078d06e516184e2f575f3803935697b5e3ac6 ---------------------------------------------------------------------- Use drm_get_edid to get the resolution, if that fails, set it to a fixed resolution. Rewrite the desrtoy callback function to release resources. Signed-off-by: NMa Hai <mahai1@huawei.com> Signed-off-by: NTian Tao <tiantao6@hisilicon.com> Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de> Reviewed-by: NLi Dongming <lidongming5@huawei.com> Link: https://patchwork.freedesktop.org/patch/msgid/1600778670-60370-3-git-send-email-tiantao6@hisilicon.comAcked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ma Hai 提交于
mainline inclusion from mainline-v5.12-rc2 commit 4eb4d99d category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4M6CD?from=project-issue CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/hisilicon/hibmc?h=v5.12-rc2&id=4eb4d99dfe3018d86f4529112aa7082f43b6996a ---------------------------------------------------------------------- Adding driver implementation to support i2c driver algorithms for bit-shift adapters, so hibmc will using the interface provided by drm to read edid. Signed-off-by: NMa Hai <mahai1@huawei.com> Signed-off-by: NTian Tao <tiantao6@hisilicon.com> Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de> Reviewed-by: NLi Dongming <lidongming5@huawei.com> Link: https://patchwork.freedesktop.org/patch/msgid/1600778670-60370-2-git-send-email-tiantao6@hisilicon.comAcked-by: NXie XiuQi <xiexiuqi@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 10 12月, 2021 7 次提交
-
-
由 Lijun Fang 提交于
ascend inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR CVE: NA ------------------- If it enable COHERENT_DEVICE and config HBM for device, the tmpfs will statistics all memory including HBM, which couldn't be used by system. When the system runs out of memory, statistical residual memory but also left a lot, so this will cause many problems. Signed-off-by: NLijun Fang <fanglijun3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Trond Myklebust 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4IL3P CVE: NA -------------------------------- After we've looked up the transport module, we need to ensure it can't go away until we've finished running the transport setup code. Signed-off-by: NTrond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by: NLu Wei <luwei32@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Zheng Zucheng 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I4LH1X CVE: NA -------------------------------- When online tasks occupy cpu long time, offline task will not get cpu to run, the priority inversion issue may be triggered in this case. If the above case occurs, we will unthrottle offline tasks and let its get a chance to run. When online tasks occupy cpu over 5s(defaule value), we will unthrottle offline tasks and enter a msleep loop before exit to usermode util the cpu goto idle. Signed-off-by: NZhang Qiao <zhangqiao22@huawei.com> Signed-off-by: NZheng Zucheng <zhengzucheng@huawei.com> Reviewed-by: NChen Hui <judy.chenhui@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Fang Lijun 提交于
ascend inclusion category: Bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I4JMLR CVE: NA -------------- System cann't use the cdm nodes memory, but it can mmap all nodes huge pages, so it will cause Bus error when mmap succeed but the huge pages were not enough. When set the cdmmask, users will transfer the numa id by mmap flag to map the specific numa node hugepages, if there was not enough hugepages on this node, return -ENOMEM. Dvpp use flags MAP_CHECKNODE to enable check node hugetlb. The global variable numanode will cause the mmap not be reenterable, so use the flags BITS[26:31] directly. v2: fix a compiling error on platforms such as mips Signed-off-by: NFang Lijun <fanglijun3@huawei.com> Reviewed-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Keith Busch 提交于
mainline inclusion from mainline-v5.14-rc1 commit fb9b16e1 category: bugfix bugzilla: 185778 https://gitee.com/openeuler/kernel/issues/I4LM14 CVE: NA ----------------------------------------- The synchronous blk_execute_rq() had not provided a way for its callers to know if its request was successful or not. Return the blk_status_t result of the request. Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NMing Lei <ming.lei@redhat.com> Signed-off-by: NKeith Busch <kbusch@kernel.org> Reviewed-by: NChaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Link: https://lore.kernel.org/r/20210610214437.641245-4-kbusch@kernel.orgSigned-off-by: NJens Axboe <axboe@kernel.dk> conflict: 1. in blkdev.h and blk-exec, blk_execute_rq return value change; 2. input parameter in blk_execute_rq is not the same as mainline; Signed-off-by: Nzhangwensheng <zhangwensheng5@huawei.com> Reviewed-by: Nqiulaibin <qiulaibin@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jan Kara 提交于
mainline inclusion from mainline-v5.14-rc1 commit fd2ef39c category: bugfix bugzilla: 185777 https://gitee.com/openeuler/kernel/issues/I4LM14 CVE: NA ------------------------------ Lockdep complains about lock inversion between ioc->lock and bfqd->lock: bfqd -> ioc: put_io_context+0x33/0x90 -> ioc->lock grabbed blk_mq_free_request+0x51/0x140 blk_put_request+0xe/0x10 blk_attempt_req_merge+0x1d/0x30 elv_attempt_insert_merge+0x56/0xa0 blk_mq_sched_try_insert_merge+0x4b/0x60 bfq_insert_requests+0x9e/0x18c0 -> bfqd->lock grabbed blk_mq_sched_insert_requests+0xd6/0x2b0 blk_mq_flush_plug_list+0x154/0x280 blk_finish_plug+0x40/0x60 ext4_writepages+0x696/0x1320 do_writepages+0x1c/0x80 __filemap_fdatawrite_range+0xd7/0x120 sync_file_range+0xac/0xf0 ioc->bfqd: bfq_exit_icq+0xa3/0xe0 -> bfqd->lock grabbed put_io_context_active+0x78/0xb0 -> ioc->lock grabbed exit_io_context+0x48/0x50 do_exit+0x7e9/0xdd0 do_group_exit+0x54/0xc0 To avoid this inversion we change blk_mq_sched_try_insert_merge() to not free the merged request but rather leave that upto the caller similarly to blk_mq_sched_try_merge(). And in bfq_insert_requests() we make sure to free all the merged requests after dropping bfqd->lock. Fixes: aee69d78 ("block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler") Reviewed-by: NMing Lei <ming.lei@redhat.com> Acked-by: NPaolo Valente <paolo.valente@linaro.org> Signed-off-by: NJan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20210623093634.27879-3-jack@suse.czSigned-off-by: NJens Axboe <axboe@kernel.dk> Conflict: 1. mainline include/linux/elevator.h file change; 2. mainline block/mq-deadline-main.c file change, now change to block/mq-deadline.c; Signed-off-by: Nzhangwensheng <zhangwensheng5@huawei.com> Reviewed-by: Nqiulaibin <qiulaibin@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Jan Kara 提交于
mainline inclusion from mainline-v5.14-rc1 commit a921c655 category: bugfix bugzilla: 185777 https://gitee.com/openeuler/kernel/issues/I4LM14 CVE: NA --------------------------- Currently, bfq does very little in bfq_requests_merged() and handles all the request cleanup in bfq_finish_requeue_request() called from blk_mq_free_request(). That is currently safe only because blk_mq_free_request() is called shortly after bfq_requests_merged() while bfqd->lock is still held. However to fix a lock inversion between bfqd->lock and ioc->lock, we need to call blk_mq_free_request() after dropping bfqd->lock. That would mean that already merged request could be seen by other processes inside bfq queues and possibly dispatched to the device which is wrong. So move cleanup of the request from bfq_finish_requeue_request() to bfq_requests_merged(). Acked-by: NPaolo Valente <paolo.valente@linaro.org> Signed-off-by: NJan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20210623093634.27879-2-jack@suse.czSigned-off-by: NJens Axboe <axboe@kernel.dk> conflict: in bfq_finish_requeue_request, code in hulk have the line atomic_dec(&rq->mq_hctx->elevator_queued); that is conflicted; Signed-off-by: Nzhangwensheng <zhangwensheng5@huawei.com> Reviewed-by: Nqiulaibin <qiulaibin@huawei.com> Reviewed-by: NJason Yan <yanaijie@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
- 06 12月, 2021 14 次提交
-
-
由 Borislav Petkov 提交于
stable inclusion from stable-5.10.81 commit 0685efd9840f7d017ea7cef1f49aa746329fa73d bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0685efd9840f7d017ea7cef1f49aa746329fa73d -------------------------------- commit a72fdfd2 upstream. Commit in Fixes changed the iopl emulation to not #GP on CLI and STI because it would break some insane luserspace tools which would toggle interrupts. The corresponding selftest would rely on the fact that executing CLI/STI would trigger a #GP and thus detect it this way but since that #GP is not happening anymore, the detection is now wrong too. Extend the test to actually look at the IF flag and whether executing those insns had any effect on it. The STI detection needs to have the fact that interrupts were previously disabled, passed in so do that from the previous CLI test, i.e., STI test needs to follow a previous CLI one for it to make sense. Fixes: b968e84b ("x86/iopl: Fake iopl(3) CLI/STI usage") Suggested-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NBorislav Petkov <bp@suse.de> Acked-by: NThomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20211030083939.13073-1-bp@alien8.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
stable inclusion from stable-5.10.81 commit 6a315471cb6a07f651e1d3adc8962730f4fcccac bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6a315471cb6a07f651e1d3adc8962730f4fcccac -------------------------------- commit 96cfe050 upstream. of_parse_thermal_zones() parses the thermal-zones node and registers a thermal_zone device for each subnode. However, if a thermal zone is consuming a thermal sensor and that thermal sensor device hasn't probed yet, an attempt to set trip_point_*_temp for that thermal zone device can cause a NULL pointer dereference. Fix it. console:/sys/class/thermal/thermal_zone87 # echo 120000 > trip_point_0_temp ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... Call trace: of_thermal_set_trip_temp+0x40/0xc4 trip_point_temp_store+0xc0/0x1dc dev_attr_store+0x38/0x88 sysfs_kf_write+0x64/0xc0 kernfs_fop_write_iter+0x108/0x1d0 vfs_write+0x2f4/0x368 ksys_write+0x7c/0xec __arm64_sys_write+0x20/0x30 el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc do_el0_svc+0x28/0xa0 el0_svc+0x14/0x24 el0_sync_handler+0x88/0xec el0_sync+0x1c0/0x200 While at it, fix the possible NULL pointer dereference in other functions as well: of_thermal_get_temp(), of_thermal_set_emul_temp(), of_thermal_get_trend(). Suggested-by: NDavid Collins <quic_collinsd@quicinc.com> Signed-off-by: NSubbaraman Narayanamurthy <quic_subbaram@quicinc.com> Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Greg Thelen 提交于
stable inclusion from stable-5.10.81 commit bd40513d0bee24095948abfaa17d3ad8f444a85b bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bd40513d0bee24095948abfaa17d3ad8f444a85b -------------------------------- commit 4716023a upstream. PEBS PERF_SAMPLE_PHYS_ADDR events use perf_virt_to_phys() to convert PMU sampled virtual addresses to physical using get_user_page_fast_only() and page_to_phys(). Some get_user_page_fast_only() error cases return false, indicating no page reference, but still initialize the output page pointer with an unreferenced page. In these error cases perf_virt_to_phys() calls put_page(). This causes page reference count underflow, which can lead to unintentional page sharing. Fix perf_virt_to_phys() to only put_page() if get_user_page_fast_only() returns a referenced page. Fixes: fc7ce9c7 ("perf/core, x86: Add PERF_SAMPLE_PHYS_ADDR") Signed-off-by: NGreg Thelen <gthelen@google.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20211111021814.757086-1-gthelen@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Nathan Chancellor 提交于
stable inclusion from stable-5.10.81 commit df58fb431aa3b8371e11b27a94b20f8b765799c7 bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=df58fb431aa3b8371e11b27a94b20f8b765799c7 -------------------------------- This patch is for linux-5.10.y only. When scripts/lld-version.sh was initially written, it did not account for the LLD_VENDOR cmake flag, which changes the output of ld.lld's --version flag slightly. Without LLD_VENDOR: $ ld.lld --version LLD 14.0.0 (compatible with GNU linkers) With LLD_VENDOR: $ ld.lld --version Debian LLD 14.0.0 (compatible with GNU linkers) As a result, CONFIG_LLD_VERSION is messed up and configuration values that are dependent on it cannot be selected: scripts/lld-version.sh: 20: printf: LLD: expected numeric value scripts/lld-version.sh: 20: printf: LLD: expected numeric value scripts/lld-version.sh: 20: printf: LLD: expected numeric value init/Kconfig:52:warning: 'LLD_VERSION': number is invalid .config:11:warning: symbol value '00000' invalid for LLD_VERSION .config:8800:warning: override: CPU_BIG_ENDIAN changes choice state This was fixed upstream by commit 1f09af06 ("kbuild: Fix ld-version.sh script if LLD was built with LLD_VENDOR") in 5.12 but that was done to ld-version.sh after it was massively rewritten in commit 02aff859 ("kbuild: check the minimum linker version in Kconfig"). To avoid bringing in that change plus its prerequisites and fixes, just modify lld-version.sh to make it similar to the upstream ld-version.sh, which handles ld.lld with or without LLD_VENDOR and ld.bfd without any errors. Signed-off-by: NNathan Chancellor <nathan@kernel.org> Reviewed-by: NNick Desaulniers <ndesaulniers@google.com> Tested-by: NNick Desaulniers <ndesaulniers@google.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Gao Xiang 提交于
stable inclusion from stable-5.10.81 commit be3f6035831a667f5d316be180176a3a8d8460b5 bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=be3f6035831a667f5d316be180176a3a8d8460b5 -------------------------------- commit 86432a6d upstream. There are pclusters in runtime marked with Z_EROFS_PCLUSTER_TAIL before actual I/O submission. Thus, the decompression chain can be extended if the following pcluster chain hooks such tail pcluster. As the related comment mentioned, if some page is made of a hooked pcluster and another followed pcluster, it can be reused for in-place I/O (since I/O should be submitted anyway): _______________________________________________________________ | tail (partial) page | head (partial) page | |_____PRIMARY_HOOKED___|____________PRIMARY_FOLLOWED____________| However, it's by no means safe to reuse as pagevec since if such PRIMARY_HOOKED pclusters finally move into bypass chain without I/O submission. It's somewhat hard to reproduce with LZ4 and I just found it (general protection fault) by ro_fsstressing a LZMA image for long time. I'm going to actively clean up related code together with multi-page folio adaption in the next few months. Let's address it directly for easier backporting for now. Call trace for reference: z_erofs_decompress_pcluster+0x10a/0x8a0 [erofs] z_erofs_decompress_queue.isra.36+0x3c/0x60 [erofs] z_erofs_runqueue+0x5f3/0x840 [erofs] z_erofs_readahead+0x1e8/0x320 [erofs] read_pages+0x91/0x270 page_cache_ra_unbounded+0x18b/0x240 filemap_get_pages+0x10a/0x5f0 filemap_read+0xa9/0x330 new_sync_read+0x11b/0x1a0 vfs_read+0xf1/0x190 Link: https://lore.kernel.org/r/20211103182006.4040-1-xiang@kernel.org Fixes: 3883a79a ("staging: erofs: introduce VLE decompression support") Cc: <stable@vger.kernel.org> # 4.19+ Reviewed-by: NChao Yu <chao@kernel.org> Signed-off-by: NGao Xiang <hsiangkao@linux.alibaba.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yue Hu 提交于
stable inclusion from stable-5.10.81 commit 6c1ad56b2d78725034bfed17782dc1264149563d bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6c1ad56b2d78725034bfed17782dc1264149563d -------------------------------- commit 7dea3de7 upstream. No any behavior to variable occupied in z_erofs_attach_page() which is only caller to z_erofs_pagevec_enqueue(). Link: https://lore.kernel.org/r/20210419102623.2015-1-zbestahu@gmail.comSigned-off-by: NYue Hu <huyue2@yulong.com> Reviewed-by: NGao Xiang <xiang@kernel.org> Signed-off-by: NGao Xiang <xiang@kernel.org> Signed-off-by: NGao Xiang <hsiangkao@linux.alibaba.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Marc Zyngier 提交于
stable inclusion from stable-5.10.81 commit 5bf5f464831c26dca627bf32d4e51067dcd39d64 bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5bf5f464831c26dca627bf32d4e51067dcd39d64 -------------------------------- commit f21082fb upstream. The ION AHCI device pretends that MSI masking isn't a thing, while it actually implements it and needs MSIs to be unmasked to work. Add a quirk to that effect. Reported-by: NRui Salvaterra <rsalvaterra@gmail.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NRui Salvaterra <rsalvaterra@gmail.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Cc: Bjorn Helgaas <helgaas@kernel.org> Link: https://lore.kernel.org/r/CALjTZvbzYfBuLB+H=fj2J+9=DxjQ2Uqcy0if_PvmJ-nU-qEgkg@mail.gmail.com Link: https://lore.kernel.org/r/20211104180130.3825416-3-maz@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Conflicts: drivers/pci/quirks.c Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Marc Zyngier 提交于
stable inclusion from stable-5.10.81 commit f28c620e1ac1b7312519516217240556193c2618 bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f28c620e1ac1b7312519516217240556193c2618 -------------------------------- commit 2226667a upstream. It appears that some devices are lying about their mask capability, pretending that they don't have it, while they actually do. The net result is that now that we don't enable MSIs on such endpoint. Add a new per-device flag to deal with this. Further patches will make use of it, sadly. Signed-off-by: NMarc Zyngier <maz@kernel.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20211104180130.3825416-2-maz@kernel.org Cc: Bjorn Helgaas <helgaas@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Thomas Gleixner 提交于
stable inclusion from stable-5.10.81 commit 9b61500ee536adc38929852259d8c84ab6b908bc bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9b61500ee536adc38929852259d8c84ab6b908bc -------------------------------- commit 37354590 upstream. free_msi_irqs() frees the MSI entries before destroying the sysfs entries which are exposing them. Nothing prevents a concurrent free while a sysfs file is read and accesses the possibly freed entry. Move the sysfs release ahead of freeing the entries. Fixes: 1c51b50c ("PCI/MSI: Export MSI mode using attributes, not kobjects") Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Bjorn Helgaas <helgaas@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87sfw5305m.ffs@tglxSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sven Schnelle 提交于
stable inclusion from stable-5.10.81 commit c49bfdfe535c65fe14041cf11b7f36950f26f317 bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c49bfdfe535c65fe14041cf11b7f36950f26f317 -------------------------------- commit 3ec18fc7 upstream. commit 8779e05b ("parisc: Fix ptrace check on syscall return") fixed testing of TI_FLAGS. This uncovered a bug in the test mask. syscall_restore_rfi is only used when the kernel needs to exit to usespace with single or block stepping and the recovery counter enabled. The test however used _TIF_SYSCALL_TRACE_MASK, which includes a lot of bits that shouldn't be tested here. Fix this by using TIF_SINGLESTEP and TIF_BLOCKSTEP directly. I encountered this bug by enabling syscall tracepoints. Both in qemu and on real hardware. As soon as i enabled the tracepoint (sys_exit_read, but i guess it doesn't really matter which one), i got random page faults in userspace almost immediately. Signed-off-by: NSven Schnelle <svens@stackframe.org> Signed-off-by: NHelge Deller <deller@gmx.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Peter Zijlstra 提交于
stable inclusion from stable-5.10.81 commit b31bac061918936d6f6d647878bd45a2c81b446b bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b31bac061918936d6f6d647878bd45a2c81b446b -------------------------------- commit b968e84b upstream. Since commit c8137ace ("x86/iopl: Restrict iopl() permission scope") it's possible to emulate iopl(3) using ioperm(), except for the CLI/STI usage. Userspace CLI/STI usage is very dubious (read broken), since any exception taken during that window can lead to rescheduling anyway (or worse). The IOPL(2) manpage even states that usage of CLI/STI is highly discouraged and might even crash the system. Of course, that won't stop people and HP has the dubious honour of being the first vendor to be found using this in their hp-health package. In order to enable this 'software' to still 'work', have the #GP treat the CLI/STI instructions as NOPs when iopl(3). Warn the user that their program is doing dubious things. Fixes: a24ca997 ("x86/iopl: Remove legacy IOPL option") Reported-by: NOndrej Zary <linux@zary.sk> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Cc: stable@kernel.org # v5.5+ Link: https://lkml.kernel.org/r/20210918090641.GD5106@worktop.programming.kicks-ass.netSigned-off-by: NOndrej Zary <linux@zary.sk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Michael Riesch 提交于
stable inclusion from stable-5.10.81 commit a0958a5354f7bcade6557003eac23a77b7d26fb4 bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a0958a5354f7bcade6557003eac23a77b7d26fb4 -------------------------------- commit 2d26f6e3 upstream. This reverts commit 2c896fb0 "net: stmmac: dwmac-rk: add pd_gmac support for rk3399" and fixes unbalanced pm_runtime_enable warnings. In the commit to be reverted, support for power management was introduced to the Rockchip glue code. Later, power management support was introduced to the stmmac core code, resulting in multiple invocations of pm_runtime_{enable,disable,get_sync,put_sync}. The multiple invocations happen in rk_gmac_powerup and stmmac_{dvr_probe, resume} as well as in rk_gmac_powerdown and stmmac_{dvr_remove, suspend}, respectively, which are always called in conjunction. Fixes: 5ec55823 ("net: stmmac: add clocks management for gmac driver") Signed-off-by: NMichael Riesch <michael.riesch@wolfvision.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NMeng Li <Meng.Li@windriver.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Wong Vee Khee 提交于
stable inclusion from stable-5.10.81 commit 80407c6ad9da25f52f8091cdd8c7b80168d5c3d5 bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=80407c6ad9da25f52f8091cdd8c7b80168d5c3d5 -------------------------------- commit ab00f3e0 upstream. In the case of MDIO bus registration failure due to no external PHY devices is connected to the MAC, clk_disable_unprepare() is called in stmmac_bus_clk_config() and intel_eth_pci_probe() respectively. The second call in intel_eth_pci_probe() will caused the following:- [ 16.578605] intel-eth-pci 0000:00:1e.5: No PHY found [ 16.583778] intel-eth-pci 0000:00:1e.5: stmmac_dvr_probe: MDIO bus (id: 2) registration failed [ 16.680181] ------------[ cut here ]------------ [ 16.684861] stmmac-0000:00:1e.5 already disabled [ 16.689547] WARNING: CPU: 13 PID: 2053 at drivers/clk/clk.c:952 clk_core_disable+0x96/0x1b0 [ 16.697963] Modules linked in: dwc3 iTCO_wdt mei_hdcp iTCO_vendor_support udc_core x86_pkg_temp_thermal kvm_intel marvell10g kvm sch_fq_codel nfsd irqbypass dwmac_intel(+) stmmac uio ax88179_178a pcs_xpcs phylink uhid spi_pxa2xx_platform usbnet mei_me pcspkr tpm_crb mii i2c_i801 dw_dmac dwc3_pci thermal dw_dmac_core intel_rapl_msr libphy i2c_smbus mei tpm_tis intel_th_gth tpm_tis_core tpm intel_th_acpi intel_pmc_core intel_th i915 fuse configfs snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_pcm snd_timer snd soundcore [ 16.746785] CPU: 13 PID: 2053 Comm: systemd-udevd Tainted: G U 5.13.0-rc3-intel-lts #76 [ 16.756134] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-S ADP-S DRR4 CRB, BIOS ADLIFSI1.R00.1494.B00.2012031421 12/03/2020 [ 16.769465] RIP: 0010:clk_core_disable+0x96/0x1b0 [ 16.774222] Code: 00 8b 05 45 96 17 01 85 c0 7f 24 48 8b 5b 30 48 85 db 74 a5 8b 43 7c 85 c0 75 93 48 8b 33 48 c7 c7 6e 32 cc b7 e8 b2 5d 52 00 <0f> 0b 5b 5d c3 65 8b 05 76 31 18 49 89 c0 48 0f a3 05 bc 92 1a 01 [ 16.793016] RSP: 0018:ffffa44580523aa0 EFLAGS: 00010086 [ 16.798287] RAX: 0000000000000000 RBX: ffff8d7d0eb70a00 RCX: 0000000000000000 [ 16.805435] RDX: 0000000000000002 RSI: ffffffffb7c62d5f RDI: 00000000ffffffff [ 16.812610] RBP: 0000000000000287 R08: 0000000000000000 R09: ffffa445805238d0 [ 16.819759] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8d7d0eb70a00 [ 16.826904] R13: ffff8d7d027370c8 R14: 0000000000000006 R15: ffffa44580523ad0 [ 16.834047] FS: 00007f9882fa2600(0000) GS:ffff8d80a0940000(0000) knlGS:0000000000000000 [ 16.842177] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 16.847966] CR2: 00007f9882bea3d8 CR3: 000000010b126001 CR4: 0000000000370ee0 [ 16.855144] Call Trace: [ 16.857614] clk_core_disable_lock+0x1b/0x30 [ 16.861941] intel_eth_pci_probe.cold+0x11d/0x136 [dwmac_intel] [ 16.867913] pci_device_probe+0xcf/0x150 [ 16.871890] really_probe+0xf5/0x3e0 [ 16.875526] driver_probe_device+0x64/0x150 [ 16.879763] device_driver_attach+0x53/0x60 [ 16.883998] __driver_attach+0x9f/0x150 [ 16.887883] ? device_driver_attach+0x60/0x60 [ 16.892288] ? device_driver_attach+0x60/0x60 [ 16.896698] bus_for_each_dev+0x77/0xc0 [ 16.900583] bus_add_driver+0x184/0x1f0 [ 16.904469] driver_register+0x6c/0xc0 [ 16.908268] ? 0xffffffffc07ae000 [ 16.911598] do_one_initcall+0x4a/0x210 [ 16.915489] ? kmem_cache_alloc_trace+0x305/0x4e0 [ 16.920247] do_init_module+0x5c/0x230 [ 16.924057] load_module+0x2894/0x2b70 [ 16.927857] ? __do_sys_finit_module+0xb5/0x120 [ 16.932441] __do_sys_finit_module+0xb5/0x120 [ 16.936845] do_syscall_64+0x42/0x80 [ 16.940476] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 16.945586] RIP: 0033:0x7f98830e5ccd [ 16.949177] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 93 31 0c 00 f7 d8 64 89 01 48 [ 16.967970] RSP: 002b:00007ffc66b60168 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 16.975583] RAX: ffffffffffffffda RBX: 000055885de35ef0 RCX: 00007f98830e5ccd [ 16.982725] RDX: 0000000000000000 RSI: 00007f98832541e3 RDI: 0000000000000012 [ 16.989868] RBP: 0000000000020000 R08: 0000000000000000 R09: 0000000000000000 [ 16.997042] R10: 0000000000000012 R11: 0000000000000246 R12: 00007f98832541e3 [ 17.004222] R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffc66b60328 [ 17.011369] ---[ end trace df06a3dab26b988c ]--- [ 17.016062] ------------[ cut here ]------------ [ 17.020701] stmmac-0000:00:1e.5 already unprepared Removing the stmmac_bus_clks_config() call in stmmac_dvr_probe and let dwmac-intel to handle the unprepare and disable of the clk device. Fixes: 5ec55823 ("net: stmmac: add clocks management for gmac driver") Cc: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: NWong Vee Khee <vee.khee.wong@linux.intel.com> Reviewed-by: NJoakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NMeng Li <Meng.Li@windriver.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Joakim Zhang 提交于
stable inclusion from stable-5.10.81 commit ac4bb9951c2cb9e40d5cf9a010ac8dead6f46501 bugzilla: 185832 https://gitee.com/openeuler/kernel/issues/I4L9CF Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ac4bb9951c2cb9e40d5cf9a010ac8dead6f46501 -------------------------------- commit 4691ffb1 upstream. Fix system hang with below sequences: ~# ifconfig ethx down ~# ifconfig ethx hw ether xx:xx:xx:xx:xx:xx After ethx down, stmmac all clocks gated off and then register access causes system hang. Fixes: 5ec55823 ("net: stmmac: add clocks management for gmac driver") Signed-off-by: NJoakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NMeng Li <Meng.Li@windriver.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NChen Jun <chenjun102@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-