{"release":{"tag":{"name":"4.19.90-2205.4.0","path":"/openeuler/kernel/tags/4.19.90-2205.4.0","tree_path":"/openeuler/kernel/tree/4.19.90-2205.4.0","message":"4.19.90-2205.4.0","commit":{"id":"1bc9fed394dc8160191178e3250af71518ca073b","short_id":"1bc9fed","title":"scsi: hisi_sas: Change hisi_sas_control_phy() phyup timeout","title_markdown":"scsi: hisi_sas: Change hisi_sas_control_phy() phyup timeout","description":"\nmainline inclusion\nfrom mainline-5.17-rc1\ncommit 512623de5239\ncategory: bugfix\nbugzilla: https://gitee.com/openeuler/kernel/issues/I4UT5N\nCVE: NA\n\n-------------------------------------------\n\nThe time of phyup not only depends on the controller but also the type of\ndisk connected. As an example, from experience, for some SATA disks the\namount of time from reset/power-on to receive the D2H FIS for phyup can\ntake upto and more than 10s sometimes. According to the specification of\nsome SATA disks such as ST14000NM0018, the max time from power-on to ready\nis 30s.\n\nBased on this the current timeout of phyup at 2s which is not enough. So\nset the value as HISI_SAS_WAIT_PHYUP_TIMEOUT (30s) in\nhisi_sas_control_phy().\n\nFor v3 hw there is a pre-existing workaround for a HW bug, being that we\nissue a link reset when the OOB occurs but the phyup does not. The current\nphyup timeout is HISI_SAS_WAIT_PHYUP_TIMEOUT. So if this does occur from\nwhen issuing a phy enable or similar via hisi_sas_control_phy(), the\nsubsequent HW workaround linkreset processing calls hisi_sas_control_phy(),\nbut this will pend the original phy reset timing out, so it is safe.\n\nLink: https://lore.kernel.org/r/1645703489-87194-3-git-send-email-john.garry@huawei.com\nSigned-off-by: Xiang Chen \u003Cchenxiang66@hisilicon.com\u003E\nSigned-off-by: John Garry \u003Cjohn.garry@huawei.com\u003E\nSigned-off-by: Martin K. Petersen \u003Cmartin.petersen@oracle.com\u003E\nSigned-off-by: Xingui Yang \u003Cyangxingui@huawei.com\u003E\nconflict:\n\tdrivers/scsi/hisi_sas/hisi_sas.h\n\tdrivers/scsi/hisi_sas/hisi_sas_main.c\nReviewed-by: Xingui Yang \u003Cyangxingui@huawei.com\u003E\nReviewed-by: kang fenglong \u003Ckangfenglong@huawei.com\u003E\nSigned-off-by: Yongqiang Liu \u003Cliuyongqiang13@huawei.com\u003E","description_markdown":"mainline inclusion\nfrom mainline-5.17-rc1\ncommit 512623de5239\ncategory: bugfix\nbugzilla: \u003Ca title=\"Issue: 调整phyup超时时间\" class=\"gfm gfm-issue\" href=\"/open_euler/dashboard?issue_id=I4UT5N\"\u003E#I4UT5N\u003C/a\u003ECVE: NA\n-------------------------------------------\nThe time of phyup not only depends on the controller but also the type of\ndisk connected. As an example, from experience, for some SATA disks the\namount of time from reset/power-on to receive the D2H FIS for phyup can\ntake upto and more than 10s sometimes. According to the specification of\nsome SATA disks such as ST14000NM0018, the max time from power-on to ready\nis 30s.\nBased on this the current timeout of phyup at 2s which is not enough. So\nset the value as HISI_SAS_WAIT_PHYUP_TIMEOUT (30s) in\nhisi_sas_control_phy().\nFor v3 hw there is a pre-existing workaround for a HW bug, being that we\nissue a link reset when the OOB occurs but the phyup does not. The current\nphyup timeout is HISI_SAS_WAIT_PHYUP_TIMEOUT. So if this does occur from\nwhen issuing a phy enable or similar via hisi_sas_control_phy(), the\nsubsequent HW workaround linkreset processing calls hisi_sas_control_phy(),\nbut this will pend the original phy reset timing out, so it is safe.\nLink: \u003Ca href=\"https://gitee.com/link?target=https%3A%2F%2Flore.kernel.org%2Fr%2F1645703489-87194-3-git-send-email-john.garry%40huawei.com\"\u003Ehttps://lore.kernel.org/r/1645703489-87194-3-git-send-email-john.garry@huawei.com\u003C/a\u003E\nSigned-off-by: Xiang Chen \u003Ca href=\"mailto:chenxiang66@hisilicon.com\"\u003Echenxiang66@hisilicon.com\u003C/a\u003E\nSigned-off-by: John Garry \u003Ca href=\"mailto:john.garry@huawei.com\"\u003Ejohn.garry@huawei.com\u003C/a\u003E\nSigned-off-by: Martin K. Petersen \u003Ca href=\"mailto:martin.petersen@oracle.com\"\u003Emartin.petersen@oracle.com\u003C/a\u003E\nSigned-off-by: Xingui Yang \u003Ca href=\"mailto:yangxingui@huawei.com\"\u003Eyangxingui@huawei.com\u003C/a\u003E\nconflict:\ndrivers/scsi/hisi_sas/hisi_sas.h\ndrivers/scsi/hisi_sas/hisi_sas_main.c\nReviewed-by: Xingui Yang \u003Ca href=\"mailto:yangxingui@huawei.com\"\u003Eyangxingui@huawei.com\u003C/a\u003E\nReviewed-by: kang fenglong \u003Ca href=\"mailto:kangfenglong@huawei.com\"\u003Ekangfenglong@huawei.com\u003C/a\u003E\nSigned-off-by: Yongqiang Liu \u003Ca href=\"mailto:liuyongqiang13@huawei.com\"\u003Eliuyongqiang13@huawei.com\u003C/a\u003E","message":"scsi: hisi_sas: Change hisi_sas_control_phy() phyup timeout\n\nmainline inclusion\nfrom mainline-5.17-rc1\ncommit 512623de5239\ncategory: bugfix\nbugzilla: https://gitee.com/openeuler/kernel/issues/I4UT5N\nCVE: NA\n\n-------------------------------------------\n\nThe time of phyup not only depends on the controller but also the type of\ndisk connected. As an example, from experience, for some SATA disks the\namount of time from reset/power-on to receive the D2H FIS for phyup can\ntake upto and more than 10s sometimes. According to the specification of\nsome SATA disks such as ST14000NM0018, the max time from power-on to ready\nis 30s.\n\nBased on this the current timeout of phyup at 2s which is not enough. So\nset the value as HISI_SAS_WAIT_PHYUP_TIMEOUT (30s) in\nhisi_sas_control_phy().\n\nFor v3 hw there is a pre-existing workaround for a HW bug, being that we\nissue a link reset when the OOB occurs but the phyup does not. The current\nphyup timeout is HISI_SAS_WAIT_PHYUP_TIMEOUT. So if this does occur from\nwhen issuing a phy enable or similar via hisi_sas_control_phy(), the\nsubsequent HW workaround linkreset processing calls hisi_sas_control_phy(),\nbut this will pend the original phy reset timing out, so it is safe.\n\nLink: https://lore.kernel.org/r/1645703489-87194-3-git-send-email-john.garry@huawei.com\nSigned-off-by: Xiang Chen \u003Cchenxiang66@hisilicon.com\u003E\nSigned-off-by: John Garry \u003Cjohn.garry@huawei.com\u003E\nSigned-off-by: Martin K. Petersen \u003Cmartin.petersen@oracle.com\u003E\nSigned-off-by: Xingui Yang \u003Cyangxingui@huawei.com\u003E\nconflict:\n\tdrivers/scsi/hisi_sas/hisi_sas.h\n\tdrivers/scsi/hisi_sas/hisi_sas_main.c\nReviewed-by: Xingui Yang \u003Cyangxingui@huawei.com\u003E\nReviewed-by: kang fenglong \u003Ckangfenglong@huawei.com\u003E\nSigned-off-by: Yongqiang Liu \u003Cliuyongqiang13@huawei.com\u003E\n","message_markdown":"scsi: hisi_sas: Change hisi_sas_control_phy() phyup timeout\nmainline inclusion\nfrom mainline-5.17-rc1\ncommit 512623de5239\ncategory: bugfix\nbugzilla: \u003Ca title=\"Issue: 调整phyup超时时间\" class=\"gfm gfm-issue\" href=\"/open_euler/dashboard?issue_id=I4UT5N\"\u003E#I4UT5N\u003C/a\u003ECVE: NA\n-------------------------------------------\nThe time of phyup not only depends on the controller but also the type of\ndisk connected. As an example, from experience, for some SATA disks the\namount of time from reset/power-on to receive the D2H FIS for phyup can\ntake upto and more than 10s sometimes. According to the specification of\nsome SATA disks such as ST14000NM0018, the max time from power-on to ready\nis 30s.\nBased on this the current timeout of phyup at 2s which is not enough. So\nset the value as HISI_SAS_WAIT_PHYUP_TIMEOUT (30s) in\nhisi_sas_control_phy().\nFor v3 hw there is a pre-existing workaround for a HW bug, being that we\nissue a link reset when the OOB occurs but the phyup does not. The current\nphyup timeout is HISI_SAS_WAIT_PHYUP_TIMEOUT. So if this does occur from\nwhen issuing a phy enable or similar via hisi_sas_control_phy(), the\nsubsequent HW workaround linkreset processing calls hisi_sas_control_phy(),\nbut this will pend the original phy reset timing out, so it is safe.\nLink: \u003Ca href=\"https://gitee.com/link?target=https%3A%2F%2Flore.kernel.org%2Fr%2F1645703489-87194-3-git-send-email-john.garry%40huawei.com\"\u003Ehttps://lore.kernel.org/r/1645703489-87194-3-git-send-email-john.garry@huawei.com\u003C/a\u003E\nSigned-off-by: Xiang Chen \u003Ca href=\"mailto:chenxiang66@hisilicon.com\"\u003Echenxiang66@hisilicon.com\u003C/a\u003E\nSigned-off-by: John Garry \u003Ca href=\"mailto:john.garry@huawei.com\"\u003Ejohn.garry@huawei.com\u003C/a\u003E\nSigned-off-by: Martin K. Petersen \u003Ca href=\"mailto:martin.petersen@oracle.com\"\u003Emartin.petersen@oracle.com\u003C/a\u003E\nSigned-off-by: Xingui Yang \u003Ca href=\"mailto:yangxingui@huawei.com\"\u003Eyangxingui@huawei.com\u003C/a\u003E\nconflict:\ndrivers/scsi/hisi_sas/hisi_sas.h\ndrivers/scsi/hisi_sas/hisi_sas_main.c\nReviewed-by: Xingui Yang \u003Ca href=\"mailto:yangxingui@huawei.com\"\u003Eyangxingui@huawei.com\u003C/a\u003E\nReviewed-by: kang fenglong \u003Ca href=\"mailto:kangfenglong@huawei.com\"\u003Ekangfenglong@huawei.com\u003C/a\u003E\nSigned-off-by: Yongqiang Liu \u003Ca href=\"mailto:liuyongqiang13@huawei.com\"\u003Eliuyongqiang13@huawei.com\u003C/a\u003E","detail_path":"/openeuler/kernel/commit/1bc9fed394dc8160191178e3250af71518ca073b","commits_path":"/openeuler/kernel/commits/1bc9fed394dc8160191178e3250af71518ca073b","tree_path":"/openeuler/kernel/tree/1bc9fed394dc8160191178e3250af71518ca073b","author":{"name":"Xiang Chen","email":"chenxiang66@hisilicon.com","username":null,"user_path":null,"enterprise_user_path":null,"image_path":"no_portrait.png#Xiang Chen-","is_gitee_user":false,"is_enterprise_user":null,"widget_url":null},"committer":{"name":"刘勇强","email":"liuyongqiang13@huawei.com","username":"LiuYongQiang0816","user_path":"/LiuYongQiang0816","enterprise_user_path":null,"image_path":"no_portrait.png#刘勇强-LiuYongQiang0816","is_gitee_user":true,"is_enterprise_user":false,"widget_url":""},"authored_date":"2022-05-13T08:34:38+00:00","committed_date":"2022-05-13T16:20:01+08:00","signature":null,"build_state":null},"archive_path":"/openeuler/kernel/repository/archive/4.19.90-2205.4.0","signature":null},"operating":{"edit":false,"download":true,"destroy":false,"enterprise_forbid_zip":false},"release":{"title":"openEuler 20.03 update 4.19.90-2205.4.0","path":"/openeuler/kernel/releases/tag/4.19.90-2205.4.0","tag_path":"/openeuler/kernel/tree/4.19.90-2205.4.0","project_id":7696525,"created_at":"2022-05-17T14:14:48+08:00","is_prerelease":false,"description":"# 1TASK\r\n-------\r\n\r\n# 4.19.90-2205.3.0~1...4.19.90-2205.4.0\r\n-------\r\n| TASK | COMMIT |\r\n|:----:|:------:|\r\n|     bugzilla: https://gitee.com/openeuler/kernel/issues/I4UT5N | 1bc9fed394dc scsi: hisi_sas: Change hisi_sas_control_phy() phyup timeout\u003Cbr\u003E |\r\n|     bugzilla: https://gitee.com/openeuler/kernel/issues/I4ZO9V | 8fdd6417b411 scsi: hisi_sas: Fix SAS disk sense info print incorrectly sometimes\u003Cbr\u003E |\r\n|     bugzilla: https://gitee.com/openeuler/kernel/issues/I538BF | fec3e16daeba scsi: hisi_sas: Don't fail IT nexus reset for Open Reject timeout\u003Cbr\u003E |\r\n|     bugzilla: https://gitee.com/openeuler/kernel/issues/I578LV | da51b55eeff9 mm/share_pool: Support read-only memory allocation\u003Cbr\u003E |\r\n|     bugzilla: https://gitee.com/openeuler/kernel/issues/I558LD | 009c22bb86b3 mm: clear_freelist_page: Provide timeout mechanism for worker runtime\u003Cbr\u003E |\r\n|     bugzilla: 186670,https://gitee.com/src-openeuler/kernel/issues/I54H78 | a5aba8243f66 io_uring: fix race between timeout flush and removal\u003Cbr\u003E |\r\n|     bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5783H | a1cbc83674b1 ax25: fix UAF bug in ax25_send_control()\u003Cbr\u003E3b5be7185ac2 ax25: Fix refcount leaks caused by ax25_cb_del()\u003Cbr\u003E42688afbfc39 ax25: fix UAF bugs of net_device caused by rebinding operation\u003Cbr\u003E8726f0cd9687 ax25: fix reference count leaks of ax25_dev\u003Cbr\u003E5ba8a3eb026f ax25: add refcount in ax25_dev to avoid UAF bugs\u003Cbr\u003E |\r\n|     bugzilla: 186675, https://gitee.com/openeuler/kernel/issues/I55TUC | 84597fe1ff2d ext4: fix bug_on in start_this_handle during umount filesystem\u003Cbr\u003Ee2aee8682095 ext4: unregister sysfs path before destroying jbd2 journal\u003Cbr\u003E |\r\n|     bugzilla: 186477, https://gitee.com/openeuler/kernel/issues/I55UHT | 0ddc1e480f6d ext4: fix use-after-free in ext4_search_dir\u003Cbr\u003E |\r\n|     bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S | 1fbc8ee56564 mm: Update reliable flag in memory allocaion for reliable task only in task context\u003Cbr\u003E857d0cd57976 mm: refactor the reclaim thread of page cache from per-cpu to per-node\u003Cbr\u003E |\r\n\r\n# 2CVE\r\n-------\r\n\r\n| CVE | issue |\r\n|:---:|:-----:|\r\n| CVE-2022-1204 | #I5783H |\r\n| CVE-2022-29582 | #I54H78 |\r\n","author":{"name":"Qiuuuuu","username":"qiuuuuu","path":"/qiuuuuu","avatar_url":"no_portrait.png#Qiuuuuu-qiuuuuu"},"attach_files":[],"zip_download_url":"/openeuler/kernel/releases/tag/4.19.90-2205.4.0.zip","tar_download_url":"/openeuler/kernel/releases/tag/4.19.90-2205.4.0.tar.gz"}}}