- 26 4月, 2023 6 次提交
-
-
由 Dave Chinner 提交于
mainline inclusion from mainline-v5.14-rc1 commit 9d110014 category: bugfix bugzilla: 187526,https://gitee.com/openeuler/kernel/issues/I6WKVJ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d110014205cb1129fa570d8de83d486fa199354 -------------------------------- From the department of "generic/482 keeps on giving", we bring you another tail update race condition: iclog: S1 C1 +-----------------------+-----------------------+ S2 EOIC Two checkpoints in a single iclog. One is complete, the other just contains the start record and overruns into a new iclog. Timeline: Before S1: Cache flush, log tail = X At S1: Metadata stable, write start record and checkpoint At C1: Write commit record, set NEED_FUA Single iclog checkpoint, so no need for NEED_FLUSH Log tail still = X, so no need for NEED_FLUSH After C1, Before S2: Cache flush, log tail = X At S2: Metadata stable, write start record and checkpoint After S2: Log tail moves to X+1 At EOIC: End of iclog, more journal data to write Releases iclog Not a commit iclog, so no need for NEED_FLUSH Writes log tail X+1 into iclog. At this point, the iclog has tail X+1 and NEED_FUA set. There has been no cache flush for the metadata between X and X+1, and the iclog writes the new tail permanently to the log. THis is sufficient to violate on disk metadata/journal ordering. We have two options here. The first is to detect this case in some manner and ensure that the partial checkpoint write sets NEED_FLUSH when the iclog is already marked NEED_FUA and the log tail changes. This seems somewhat fragile and quite complex to get right, and it doesn't actually make it obvious what underlying problem it is actually addressing from reading the code. The second option seems much cleaner to me, because it is derived directly from the requirements of the C1 commit record in the iclog. That is, when we write this commit record to the iclog, we've guaranteed that the metadata/data ordering is correct for tail update purposes. Hence if we only write the log tail into the iclog for the *first* commit record rather than the log tail at the last release, we guarantee that the log tail does not move past where the the first commit record in the log expects it to be. IOWs, taking the first option means that replay of C1 becomes dependent on future operations doing the right thing, not just the C1 checkpoint itself doing the right thing. This makes log recovery almost impossible to reason about because now we have to take into account what might or might not have happened in the future when looking at checkpoints in the log rather than just having to reconstruct the past... Signed-off-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com> Reviewed-by: NYang Erkun <yangerkun@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Dave Chinner 提交于
mainline inclusion from mainline-v5.14-rc1 commit b2ae3a9e category: bugfix bugzilla: 187526,https://gitee.com/openeuler/kernel/issues/I6WKVJ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2ae3a9ef91152931b99620c431cf3805daa1429 -------------------------------- Because I cannot tell if the NEED_FLUSH flag is being set correctly by the log force and CIL push machinery without it. Signed-off-by: NDave Chinner <dchinner@redhat.com> Reviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NDarrick J. Wong <djwong@kernel.org> Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com> Reviewed-by: NYang Erkun <yangerkun@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Jens Axboe 提交于
stable inclusion from stable-v5.10.172 commit da24142b1ef9fd5d36b76e36bab328a5b27523e8 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6V7V1 CVE: CVE-2023-1872 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=da24142b1ef9fd5d36b76e36bab328a5b27523e8 -------------------------------- We can't use 0 here, as io_init_req() is always invoked with the ctx uring_lock held. Newer kernels have IO_URING_F_UNLOCKED for this, but previously we used IO_URING_F_NONBLOCK to indicate this as well. Fixes: 08681391b84d ("io_uring: add missing lock in io_get_file_fixed") Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Bing-Jhong Billy Jheng 提交于
stable inclusion from stable-v5.10.171 commit 08681391b84da27133deefaaddefd0acfa90c2be category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6V7V1 CVE: CVE-2023-1872 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=08681391b84da27133deefaaddefd0acfa90c2be -------------------------------- io_get_file_fixed will access io_uring's context. Lock it if it is invoked unlocked (eg via io-wq) to avoid a race condition with fixed files getting unregistered. No single upstream patch exists for this issue, it was fixed as part of the file assignment changes that went into the 5.18 cycle. Signed-off-by: NJheng, Bing-Jhong Billy <billy@starlabs.sg> Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com> Reviewed-by: NZhang Yi <yi.zhang@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @xia-bing1 Resolve the following issues: 1.SATA devices on an expander may be removed and not be found again when I_T nexus reset and revalidation are processed simultaneously. 2.Currently the driver sets the port invalid if one phy in the port is not enabled, which may cause issues in expander situation. In directly attached situation, if phy up doesn't occur in time when refreshing port id, the port is incorrectly set to invalid which will also cause disk lost. 3.When the current status of the host controller is suspended, enabling a local PHY just after disabling all local PHYs in expander envirnment, a hung as follows occurs. 4.incorrect port id may be configured in hisi_sas_refresh_port_id().As a result, all the internal IOs fail and disk lost, 5.After a HUAWEI disk that supports DIF3 is converted to a common SAS disk in DIF format, an error message is displayed when the FIO command is executed. Link:https://gitee.com/openeuler/kernel/pulls/618 Reviewed-by: Yihang Li <liyihang9@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @svishen The PR incorporates the customization code framework to support hns3 customization requirements. The following functions are supported: 1.add support PF provides customized interfaces to detect port faults 2.add support detect port wire type 3.add support set mac state 4.add support set led 5.add extend interface support for read and write phy register issue: https://gitee.com/openeuler/kernel/issues/I6YE0O Link:https://gitee.com/openeuler/kernel/pulls/616 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 25 4月, 2023 4 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @haochengxie This PR fixes below build warnings: WARNING: modpost: EXPORT symbol "__SCT__perf_lopwr_cb" [vmlinux] version generation failed, symbol will not be versioned. WARNING: modpost: EXPORT symbol "__SCT__perf_lopwr_cb" [vmlinux] version generation failed, symbol will not be versioned. Link:https://gitee.com/openeuler/kernel/pulls/625 Reviewed-by: Wei Li <liwei391@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Xie Haocheng 提交于
amd inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6XNL2 CVE: NA ------------------------------------------------- Error report detail: *** ERROR - ABI BREAKAGE WAS DETECTED *** The following symbols have been changed (this will cause an ABI breakage): new kabi: 0x65d25289 __SCK__tp_func_xdp_exception vmlinux EXPORT_SYMBOL_GPL 0x5e9265ee __tracepoint_xdp_exception vmlinux EXPORT_SYMBOL_GPL old kabi: 0x5e0fbbff __SCK__tp_func_xdp_exception vmlinux EXPORT_SYMBOL_GPL 0x017cc464 __tracepoint_xdp_exception vmlinux EXPORT_SYMBOL_GPL Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>
-
由 Xie Haocheng 提交于
amd inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6XNL2 CVE: NA ------------------------------------------------- This reverts commit a9cbff64. This patch could introduce build warnings, should be reverted. The build warning messages: WARNING: modpost: EXPORT symbol "__SCT__perf_lopwr_cb" [vmlinux] version generation failed, symbol will not be versioned. WARNING: modpost: EXPORT symbol "__SCT__perf_lopwr_cb" [vmlinux] version generation failed, symbol will not be versioned. Signed-off-by: NXie Haocheng <haocheng.xie@amd.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @zhangjialin11 Pull new CVEs: CVE-2023-1829 CVE-2022-36280 CVE-2022-1015 CVE-2023-1989 CVE-2023-30456 CVE-2023-1990 xfs bugfixes from Long Li and yangerkun Link:https://gitee.com/openeuler/kernel/pulls/593 Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
-
- 24 4月, 2023 15 次提交
-
-
由 Jian Shen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6YE0O CVE: NA ---------------------------------------------------------------------- Add extend interface support for read and write phy register with page. Sofar it supports only Phy RTL8211 and YT8521. Signed-off-by: NJian Shen <shenjian15@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 shaojijie 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6YE0O CVE: NA ---------------------------------------------------------------------- The patch supports the configuration of the position indicator and error indicator modes. Signed-off-by: Nshaojijie <shaojijie@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 wangpeiyang 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6YE0O CVE: NA ---------------------------------------------------------------------- The patch provides a customized interface to modify the MAC mode. Signed-off-by: Nwangpeiyang <wangpeiyang1@huawei.com> Signed-off-by: Nshaojijie <shaojijie@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 shaojijie 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6YE0O CVE: NA ---------------------------------------------------------------------- This patch add support to get port wire type. Signed-off-by: Nshaojijie <shaojijie@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 Jie Wang 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6YE0O CVE: NA ---------------------------------------------------------------------- When the link status of the PF network port changes from up to down, the IMP can quickly report the link down fault cause based on the link status. If the hardware is faulty from the beginning and the link is not up, the IMP does not report the link down event because the status is not changed. Therefore, an interface is provided to detect port faults. Signed-off-by: NJie Wang <wangjie125@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @svishen The PR incorporates the customization code framework to support hns3 customization requirements. The following functions are supported: 1.add support modified tx timeout 2.add support query the presence of optical module 3.add supports configure optical module enable 4.add support config and query serdes lane status 5.add support disable nic clock 6.support set pfc pause trans time 7.disbable pfc en before the reset 8.add build check in hclge_get_vf_isolate_bitmap 9.notify specified VF for recovery operation issue: https://gitee.com/openeuler/kernel/issues/I6W94W Link:https://gitee.com/openeuler/kernel/pulls/611 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Xingui Yang 提交于
mainline inclusion from mainline-v6.3-rc1 commit 26a02d97 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6V6I1 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=26a02d972bad ---------------------------------------------------------------------- If a controller has DIX is enabled and an attached disk is formatted using a protection type supported by the controller, a block integrity profile is registered to enable protected transfers. If the disk is subsequently reformatted to disable PI, and the controller does not support DIX Type 0, this can lead to failures such as this: [142829.032340] hisi_sas_v3_hw 0000:b4:04.0: erroneous completion iptt=2375 task=00000000bea0970c dev id=5 direct-attached phy4 addr=51c20dbaf642a000 CQ hdr: 0x1023 0x50947 0x0 0x20000 Error info: 0x0 0x0 0x4 0x0 [142829.073883] sas: Enter sas_scsi_recover_host busy: 1 failed: 1 [142829.079783] sas: sas_scsi_find_task: aborting task 0x00000000bea0970c [142829.102342] sas: Internal abort: task to dev 51c20dbaf642a000 response: 0x0 status 0x5 [142829.110319] sas: sas_eh_handle_sas_errors: task 0x00000000bea0970c is done [142829.117275] sd 7:0:5:0: [sdc] tag#2375 UNKNOWN(0x2003) Result: hostbyte=0x05 driverbyte=DRIVER_OK cmd_age=0s [142829.127171] sd 7:0:5:0: [sdc] tag#2375 CDB: opcode=0x2a 2a 00 00 00 00 00 00 00 08 00 [142829.135059] I/O error, dev sdc, sector 0 op 0x1:(WRITE) flags 0x18800 phys_seg 1 prio class 2 This is because the block layer integrity profile is currently only set up the first time a disk is discovered. To address this, remove the first_scan check when configuring protection information during revalidate. Also unregister the block integrity profile if DIX is not supported with a given protection type. [mkp: commit description + printk dedup] Link: https://lore.kernel.org/r/20230221081026.24736-1-yangxingui@huawei.comSigned-off-by: NXingui Yang <yangxingui@huawei.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Nxiabing <xiabing12@h-partners.com>
-
由 Martin K. Petersen 提交于
mainline inclusion from mainline-v5.19-rc1 commit 1e029397 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6V6I1 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e029397d12f ---------------------------------------------------------------------- During device discovery we ended up calling revalidate twice and thus requested the same parameters multiple times. This was originally necessary due to the request_queue and gendisk needing to be instantiated to configure the block integrity profile. Since this dependency no longer exists, reorganize the integrity probing code so it can be run once at the end of discovery and drop the superfluous revalidate call. Postponing the registration step involves splitting sd_read_protection() into two functions, one to read the device protection type and one to configure the mode of operation. As part of this cleanup, make the printing code a bit less verbose. Link: https://lore.kernel.org/r/20220302053559.32147-14-martin.petersen@oracle.comReviewed-by: NChristoph Hellwig <hch@lst.de> Reviewed-by: NJohannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Nxiabing <xiabing12@h-partners.com>
-
由 Yihang Li 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6V6I1 CVE: NA ---------------------------------------------------------------------- For the controller reset operation, hisi_sas_phy_enable() is executed for each enabled local PHY, and refresh the port id of each device based on the latest hisi_sas_phy->port_id after 1 second sleep, hisi_sas_phy->port_id is configured in the interrupt processing function phy_up_v3_hw(). However, in directly attached scenario, for some SATA disks the amount of time for phyup more than 1s sometimes. In this case, incorrect port id may be configured in hisi_sas_refresh_port_id(). As a result, all the internal IOs fail and disk lost, such as follows: [10717.666565] hisi_sas_v3_hw 0000:74:02.0: phyup: phy1 link_rate=10(sata) [10718.826813] hisi_sas_v3_hw 0000:74:02.0: erroneous completion iptt=63 task=00000000c1ab1c2b dev id=200 addr=5000000000000501 CQ hdr: 0x8000007 0xc8003f 0x0 0x0 Error info: 0x0 0x0 0x0 0x0 [10718.843428] sas: TMF task open reject failed 5000000000000501 [10718.849242] hisi_sas_v3_hw 0000:74:02.0: erroneous completion iptt=64 task=00000000c1ab1c2b dev id=200 addr=5000000000000501 CQ hdr: 0x8000007 0xc80040 0x0 0x0 Error info: 0x0 0x0 0x0 0x0 [10718.865856] sas: TMF task open reject failed 5000000000000501 [10718.871670] hisi_sas_v3_hw 0000:74:02.0: erroneous completion iptt=65 task=00000000c1ab1c2b dev id=200 addr=5000000000000501 CQ hdr: 0x8000007 0xc80041 0x0 0x0 Error info: 0x0 0x0 0x0 0x0 [10718.888284] sas: TMF task open reject failed 5000000000000501 [10718.894093] sas: executing TMF for 5000000000000501 failed after 3 attempts! [10718.901114] hisi_sas_v3_hw 0000:74:02.0: ata disk 5000000000000501 reset failed [10718.908410] hisi_sas_v3_hw 0000:74:02.0: controller reset complete ..... [10773.298633] ata216.00: revalidation failed (errno=-19) [10773.303753] ata216.00: disable device So the time of waitting for PHYs up is 1s which may be not enough. To solve the issue, running hisi_sas_phy_enable() in parallel through async operations and use wait_for_completion_timeout() to wait for PHYs come up instead of directly sleep for 1 second. Signed-off-by: NYihang Li <liyihang9@huawei.com> Signed-off-by: NXiang Chen <chenxiang66@hisilicon.com> Signed-off-by: Nxiabing <xiabing12@h-partners.com>
-
由 Yihang Li 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6V6I1 CVE: NA ---------------------------------------------------------------------- When the current status of the host controller is suspended, enabling a local PHY just after disabling all local PHYs in expander envirnment, a hung as follows occurs. [ 486.854655] INFO: task kworker/u256:1:899 blocked for more than 120 seconds. [ 486.862207] Not tainted 6.1.0-rc4+ #1 [ 486.870545] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 486.878893] task:kworker/u256:1 state:D stack:0 pid:899 ppid:2 flags:0x00000008 [ 486.887745] Workqueue: 0000:74:02.0_disco_q sas_discover_domain [libsas] [ 486.894704] Call trace: [ 486.897400] __switch_to+0xf0/0x170 [ 486.901146] __schedule+0x3e4/0x1160 [ 486.904970] schedule+0x64/0x104 [ 486.908442] rpm_resume+0x158/0x6a0 [ 486.912163] __pm_runtime_resume+0x5c/0x84 [ 486.916489] smp_execute_task_sg+0x1f8/0x264 [libsas] [ 486.921773] sas_discover_expander.part.0+0xbc/0x720 [libsas] [ 486.927750] sas_discover_root_expander+0x90/0x154 [libsas] [ 486.933552] sas_discover_domain+0x444/0x6d0 [libsas] [ 486.938826] process_one_work+0x1e0/0x450 [ 486.943057] worker_thread+0x150/0x44c [ 486.947015] kthread+0x114/0x120 [ 486.950447] ret_from_fork+0x10/0x20 [ 486.954292] INFO: task kworker/u256:2:1780 blocked for more than 120 seconds. [ 486.961637] Not tainted 6.1.0-rc4+ #1 [ 486.966087] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 486.974356] task:kworker/u256:2 state:D stack:0 pid:1780 ppid:2 flags:0x00000208 [ 486.983141] Workqueue: 0000:74:02.0_event_q sas_port_event_worker [libsas] [ 486.990252] Call trace: [ 486.992930] __switch_to+0xf0/0x170 [ 486.996645] __schedule+0x3e4/0x1160 [ 487.000439] schedule+0x64/0x104 [ 487.003886] schedule_timeout+0x17c/0x1c0 [ 487.008102] wait_for_completion+0x7c/0x160 [ 487.012488] __flush_workqueue+0x104/0x3e0 [ 487.016782] sas_porte_bytes_dmaed+0x414/0x454 [libsas] [ 487.022203] sas_port_event_worker+0x38/0x60 [libsas] [ 487.027449] process_one_work+0x1e0/0x450 [ 487.031645] worker_thread+0x150/0x44c [ 487.035594] kthread+0x114/0x120 [ 487.039017] ret_from_fork+0x10/0x20 [ 487.042828] INFO: task bash:11488 blocked for more than 121 seconds. [ 487.049366] Not tainted 6.1.0-rc4+ #1 [ 487.053746] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 487.061953] task:bash state:D stack:0 pid:11488 ppid:10977 flags:0x00000204 [ 487.070698] Call trace: [ 487.073355] __switch_to+0xf0/0x170 [ 487.077050] __schedule+0x3e4/0x1160 [ 487.080833] schedule+0x64/0x104 [ 487.084270] schedule_timeout+0x17c/0x1c0 [ 487.088474] wait_for_completion+0x7c/0x160 [ 487.092851] __flush_workqueue+0x104/0x3e0 [ 487.097137] drain_workqueue+0xb8/0x160 [ 487.101159] __sas_drain_work+0x50/0x90 [libsas] [ 487.105963] sas_suspend_ha+0x64/0xd4 [libsas] [ 487.110590] suspend_v3_hw+0x198/0x1e8 [hisi_sas_v3_hw] [ 487.115989] pci_pm_runtime_suspend+0x5c/0x1d0 [ 487.120606] __rpm_callback+0x50/0x150 [ 487.124535] rpm_callback+0x74/0x80 [ 487.128204] rpm_suspend+0x110/0x640 [ 487.131955] rpm_idle+0x1f4/0x2d0 [ 487.135447] __pm_runtime_idle+0x58/0x94 [ 487.139538] queue_phy_enable+0xcc/0xf0 [libsas] [ 487.144330] store_sas_phy_enable+0x74/0x100 [ 487.148770] dev_attr_store+0x20/0x34 [ 487.152606] sysfs_kf_write+0x4c/0x5c [ 487.156437] kernfs_fop_write_iter+0x120/0x1b0 [ 487.161049] vfs_write+0x2d0/0x36c [ 487.164625] ksys_write+0x70/0x100 [ 487.168194] __arm64_sys_write+0x24/0x30 [ 487.172280] invoke_syscall+0x50/0x120 [ 487.176186] el0_svc_common.constprop.0+0x168/0x190 [ 487.181214] do_el0_svc+0x34/0xc0 [ 487.184680] el0_svc+0x2c/0xb4 [ 487.187879] el0t_64_sync_handler+0xb8/0xbc [ 487.192205] el0t_64_sync+0x19c/0x1a0 We find that when all local PHYs are disabled, all the devices will be removed, the ->runtime_suspend() callback suspend_v3_hw() directly execute since the controller usage count drop to 0. On the other side, the first local PHY is enabled through the sysfs interface, and ensures that function phy_up_v3_hw() is completed due to suspend_v3_hw()-> interrupt_disable_v3_hw(). In the expander scenario, sas_discover_root_expander() is executed in event work DISCE_DISCOVER_DOMAIN, which will increases the controller usage count and carry out a resume and sends SMPIO, it cannot be completed because the runtime PM status of the controller is RPM_SUSPENDING. At the same time, the ->runtime_suspend() callback suspend_v3_hw() also cannot complete the process because of drain libsas event queue in sas_suspend_ha(), so hung occurs. (thread 1) | (thread 2) ... | rpm_idle() | ... | __update_runtime_status(RPM_SUSPENDING)| ... | ... suspend_v3_hw() | smp_execute_task_sg() ... | ... interrupt_disable_v3_hw() | pm_runtime_get_sync() | ... ... | rpm_resume() //RPM_SUSPENDING | __sas_drain_work() | To fix it, check if the current runtime PM status of the controller allows to be suspended continue after interrupt_disable_v3_hw(), return immediately if not. Signed-off-by: NYihang Li <liyihang9@huawei.com> Signed-off-by: NXiang Chen <chenxiang66@hislicon.com> Signed-off-by: Nxiabing <xiabing12@h-partners.com>
-
由 Yihang Li 提交于
mainline inclusion from mainline-v6.2-rc4 commit f58c8970 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6V6I1 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f58c89700630 ---------------------------------------------------------------------- Currently the driver sets the port invalid if one phy in the port is not enabled, which may cause issues in expander situation. In directly attached situation, if phy up doesn't occur in time when refreshing port id, the port is incorrectly set to invalid which will also cause disk lost. Therefore set a port invalid only if there are no devices attached to the port. Signed-off-by: NYihang Li <liyihang9@huawei.com> Signed-off-by: NXiang Chen <chenxiang66@hisilicon.com> Link: https://lore.kernel.org/r/1672805000-141102-3-git-send-email-chenxiang66@hisilicon.comSigned-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Nxiabing <xiabing12@h-partners.com>
-
由 Jie Zhan 提交于
mainline inclusion from mainline-v6.2-rc1 commit 4d450cf2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6V6I1 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4d450cf2b00d ---------------------------------------------------------------------- sas_ata_wait_after_reset() does not need to be exported since it is no longer referenced outside libsas. Signed-off-by: NJie Zhan <zhanjie9@hisilicon.com> Link: https://lore.kernel.org/r/20221118083714.4034612-6-zhanjie9@hisilicon.comReviewed-by: NJohn Garry <john.garry@huawei.com> Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Nxiabing <xiabing12@h-partners.com>
-
由 Jie Zhan 提交于
mainline inclusion from mainline-v6.2-rc1 commit 3c2673a0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6V6I1 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c2673a09cf1 ---------------------------------------------------------------------- SATA devices on an expander may be removed and not be found again when I_T nexus reset and revalidation are processed simultaneously. The issue comes from: - Revalidation can remove SATA devices in link reset, e.g. in hisi_sas_clear_nexus_ha(). - However, hisi_sas_debug_I_T_nexus_reset() polls the state of a SATA device on an expander after sending link_reset, where it calls: hisi_sas_debug_I_T_nexus_reset sas_ata_wait_after_reset ata_wait_after_reset ata_wait_ready smp_ata_check_ready sas_ex_phy_discover sas_ex_phy_discover_helper sas_set_ex_phy The ex_phy's change count is updated in sas_set_ex_phy(), so SATA devices after a link reset may not be found later through revalidation. A similar issue was reported in: commit 0f3fce5c ("[SCSI] libsas: fix ata_eh clobbering ex_phys via smp_ata_check_ready") commit 87c8331f ("[SCSI] libsas: prevent domain rediscovery competing with ata error handling"). To address this issue, in hisi_sas_debug_I_T_nexus_reset(), we now call smp_ata_check_ready_type() that only polls the device type while not updating the ex_phy's data of libsas. Fixes: 71453bd9 ("scsi: hisi_sas: Use sas_ata_wait_after_reset() in IT nexus reset") Signed-off-by: NJie Zhan <zhanjie9@hisilicon.com> Link: https://lore.kernel.org/r/20221118083714.4034612-5-zhanjie9@hisilicon.comSigned-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Nxiabing <xiabing12@h-partners.com>
-
由 Jie Zhan 提交于
mainline inclusion from mainline-v6.2-rc1 commit 9181ce3c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6V6I1 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9181ce3cb5d9 ---------------------------------------------------------------------- Create function smp_ata_check_ready_type() for LLDDs to wait for SATA devices to come up after a link reset. Signed-off-by: NJie Zhan <zhanjie9@hisilicon.com> Link: https://lore.kernel.org/r/20221118083714.4034612-4-zhanjie9@hisilicon.comSigned-off-by: NMartin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Nxiabing <xiabing12@h-partners.com>
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @xia-bing1 SATA disks do not support multiple hosts at the same time. When the same disk is dually connected after power-on, the host that connects to the disk reports an I/O error, which triggers the disk PHY to be disabled. Solution: The open-source Hisisas rolls back these policies without disabling the hard disk PHY. Link:https://gitee.com/openeuler/kernel/pulls/503 Reviewed-by: Yihang Li <liyihang9@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
- 23 4月, 2023 11 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @lujunhuaHW PCI: Support BAR sizes up to 8TB: Current kernel reports that BARs larger than 128GB, e.g., this 4TB BAR, are disabled: pci 0000:01:00.0: disabling BAR 4: [mem 0x00000000-0x3ffffffffff 64bit pref] (bad alignment 0x40000000000) Increase the maximum BAR size from 128GB to 8TB for future expansion. Detailed Description: The 1813 EP device requires 4 TB BAR space to meet the address requirements on the card side. A certain amount of space is reserved for future expansion. The space is increased to 8 TB. Link:https://gitee.com/openeuler/kernel/pulls/600 Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Yihang Li 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6NX2M CVE: NA ---------------------------------------------------------------------- In that commit, if the softreset fails upon certain conditions, just disable the PHY associated with the disk. The user needs to restore the PHY. SATA disks do not support simultaneous connection of multiple hosts. Therefore, when multiple controllers are connected to a SATA disk at the same time, the controller which is connected later failed to issue an ATA softreset to the SATA disk. As a result, the PHY associated with the disk is disabled and cannot be automatically recovered. Now that, we will not focus on the execution result of softreset. No matter whether the execution is successful or not, we will directly carry out I_T_nexus_reset. Fixes: c723ada8 ("scsi: hisi_sas: Disable SATA disk phy for severe I_T nexus reset failure") Signed-off-by: NYihang Li <liyihang9@huawei.com> Signed-off-by: Nxiabing <xiabing12@h-partners.com>
-
由 Jie Wang 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W CVE: NA ---------------------------------------------------------------------- Currently hns3 driver supports vf fault detect feature. Several ras caused by VF resources don't need to do PF function reset for recovery. The driver only needs to notify specified VF to do reset. So this patch use VF reset notification API for recovery. Signed-off-by: NJie Wang <wangjie125@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 Jie Wang 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W CVE: NA ---------------------------------------------------------------------- This patch adds a build check to guarantee enum value and avoid future issues. Signed-off-by: NJie Wang <wangjie125@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 Jiantao Xiao 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W CVE: NA ---------------------------------------------------------------------- To prevent the system from abnormally sending PFC frames after an abnormal reset. If the reset type is not imp reset or global reset, the system notifies the firmware to disable pfc before the reset. Signed-off-by: Nshaojijie <shaojijie@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 Jiantao Xiao 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W CVE: NA ---------------------------------------------------------------------- The patch provides a customized interface to modify the pause trans time and retains the configured parameters. Signed-off-by: Nshaojijie <shaojijie@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 Tian Jiang 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W CVE: NA ---------------------------------------------------------------------- The patch disables the clocks of the PPP, PPU, IGU_EGU, ROCE, and TM modules by configuring the network subctrl register. Signed-off-by: NTian Jiang <jiangtian6@h-partners.com> Signed-off-by: Nshaojijie <shaojijie@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 Tian Jiang 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W CVE: NA ---------------------------------------------------------------------- The patch supports the function of disabling and status query of lane channels on a port. The patch traverses all covered lanes on the port and powers off the serdes ds power. Signed-off-by: NTian Jiang <jiangtian6@h-partners.com> Signed-off-by: Nshaojijie <shaojijie@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 Tian Jiang 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W CVE: NA ---------------------------------------------------------------------- The patch provides an interface for enabling or disabling the optical module. Signed-off-by: NTian Jiang <jiangtian6@h-partners.com> Signed-off-by: Nshaojijie <shaojijie@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 Tian Jiang 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W CVE: NA ---------------------------------------------------------------------- The patch provides an interface to check whether the optical module is inserted. Signed-off-by: NTian Jiang <jiangtian6@h-partners.com> Signed-off-by: Nshaojijie <shaojijie@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
由 Hao Chen 提交于
driver inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6W94W CVE: NA ---------------------------------------------------------------------- The patch provides a customized interface to modify the tx timeout. Signed-off-by: NHao Chen <chenhao418@huawei.com> Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>
-
- 21 4月, 2023 1 次提交
-
-
由 Dongdong Liu 提交于
mainline inclusion from mainline-v5.18-rc1 commit 3dc8a1f6 category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I6XOIU CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3dc8a1f6f64481a8a5a669633e880f26dae0d752 ---------------------------------------------------------------------- Current kernel reports that BARs larger than 128GB, e.g., this 4TB BAR, are disabled: pci 0000:01:00.0: disabling BAR 4: [mem 0x00000000-0x3ffffffffff 64bit pref] (bad alignment 0x40000000000) Increase the maximum BAR size from 128GB to 8TB for future expansion. [bhelgaas: commit log] Link: https://lore.kernel.org/r/20220118092117.10089-1-liudongdong3@huawei.comSigned-off-by: NDongdong Liu <liudongdong3@huawei.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Signed-off-by: Nhuangfangrun <huangfangrun1@h-partners.com>
-
- 19 4月, 2023 3 次提交
-
-
由 openeuler-ci-bot 提交于
Merge Pull Request from: @stinft Support SVE DWQE to increase the performance of SoC. #I6VLLM Link:https://gitee.com/openeuler/kernel/pulls/581 Reviewed-by: Chengchang Tang <tangchengchang@huawei.com> Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
-
由 Jamal Hadi Salim 提交于
stable inclusion from stable-v5.10.173 commit 18c3fa7a7fdbb4d21dafc8a7710ae2c1680930f6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6UYBU CVE: CVE-2023-1829 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=18c3fa7a7fdbb4d21dafc8a7710ae2c1680930f6 -------------------------------- commit 8c710f75 upstream. The tcindex classifier has served us well for about a quarter of a century but has not been getting much TLC due to lack of known users. Most recently it has become easy prey to syzkaller. For this reason, we are retiring it. Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com> Acked-by: NJiri Pirko <jiri@nvidia.com> Signed-off-by: NPaolo Abeni <pabeni@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Conflicts: net/sched/cls_tcindex.c Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com> Reviewed-by: NYue Haibing <yuehaibing@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-
由 Zack Rusin 提交于
stable inclusion from stable-v5.10.163 commit 439cbbc1519547f9a7b483f0de33b556ebfec901 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5QLC4 CVE:CVE-2022-36280 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=439cbbc1519547f9a7b483f0de33b556ebfec901 -------------------------------- commit 4cf949c7 upstream. Invalid userspace dma surface copies could potentially overflow the memcpy from the surface to the snooped image leading to crashes. To fix it the dimensions of the copybox have to be validated against the expected size of the snooped cursor. Signed-off-by: NZack Rusin <zackr@vmware.com> Fixes: 2ac86371 ("vmwgfx: Snoop DMA transfers with non-covering sizes") Cc: <stable@vger.kernel.org> # v3.2+ Reviewed-by: NMichael Banack <banackm@vmware.com> Reviewed-by: NMartin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026031936.1004280-1-zack@kde.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NYuyao Lin <linyuyao1@huawei.com> Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com> Reviewed-by: NWei Li <liwei391@huawei.com> Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
-