1. 09 6月, 2023 26 次提交
  2. 08 6月, 2023 14 次提交
    • H
      scripts: Fix issue of module signing with openssl 3.x · 978f3573
      Huaxin Lu 提交于
      openEuler inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7BZZ1
      CVE: NA
      
      --------------------------------------------------------
      
      The SM2 signature for module signing is only supported
      with openEuler openssl 1.1.1. Fix the compile option to
      avoid compilation failure with openssl 3.x.
      
      Fixes: c1ad2f07 ("sign-file: Support SM signature")
      Signed-off-by: NHuaxin Lu <luhuaxin1@huawei.com>
      (cherry picked from commit 78568d28)
      978f3573
    • D
      spi: dw: Add support for 32-bits max xfer size · 19eafebe
      Damien Le Moal 提交于
      mainline inclusion
      from mainline-v5.11-rc1
      commit a51acc24
      category: feature
      bugzilla: httpsL//gitee/com/openeuler/kernel/issues/I7BZ1B
      CVE: NA
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a51acc2400d47
      
      ----------------------------------------------------------------------
      
      The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward
      define a 32-bits maximum transfer size synthesis parameter
      (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration
      (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32,
      the layout of the ctrlr0 register changes, moving the data frame format
      field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size
      can be up to 32-bits.
      
      To support this new format, introduce the DW SPI capability flag
      DW_SPI_CAP_DFS32 to indicate that a controller is configured with
      SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis
      parameter not accessible through a register, the detection of this
      parameter value is done in spi_hw_init() by writing and reading the
      ctrlr0 register and testing the value of bits [3..0]. These bits are
      ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection.
      If a DFS32 capable SPI controller is detected, the new field dfs_offset
      in struct dw_spi is set to SPI_DFS32_OFFSET (16).
      
      dw_spi_update_config() is modified to set the data frame size field at
      the correct position is the CTRLR0 register, as indicated by the
      dfs_offset field of the dw_spi structure.
      
      The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave
      controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI
      capability flag set. However, for these ssi controllers, the dfs_offset
      field is set to 0 as before (as per specifications).
      
      Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag
      set, dw_spi_add_host() extends the value of bits_per_word_mask from
      16-bits to 32-bits. dw_reader() and dw_writer() are also modified to
      handle 32-bits iTX/RX FIFO words.
      Suggested-by: NSean Anderson <seanga2@gmail.com>
      Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Acked-by: NSerge Semin <fancer.lancer@gmail.com>
      Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.comSigned-off-by: NMark Brown <broonie@kernel.org>
      Signed-off-by: NZhou Juan <nnuzj07170227@163.com>
      19eafebe
    • J
      perf: hisi: delete global enable pmu from xxx_write_counter() · 8ee6f013
      Junhao He 提交于
      driver inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7C2U9
      CVE: NA
      
      ----------------------------------------------------------------------
      
      UC PMU global enable register be setup in pmu callback pmu::enable(),
      which also be will setup in pmu::start()->xxx_write_counter(). And it
      will start statistical information when callback pmu:start() return,
      not is pmu:enable() return. Therefore the driver counter counts more
      data than normal.
      
      Fixes: 5ed05cb2 ("drivers/perf: hisi: Add support for HiSilicon UC PMU driver")
      Signed-off-by: NJunhao He <hejunhao3@huawei.com>
      8ee6f013
    • L
      xfrm: Reinject transport-mode packets through workqueue · 12093737
      Liu Jian 提交于
      mainline inclusion
      from mainline-v6.1-rc1
      commit 4f492066
      category: bugfix
      bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5K0NK
      CVE: NA
      
      Reference:  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f4920669d21e1060b7243e5118dc3b71ced1276
      
      --------------------------------
      
      The following warning is displayed when the tcp6-multi-diffip11 stress
      test case of the LTP test suite is tested:
      
      watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ns-tcpserver:48198]
      CPU: 0 PID: 48198 Comm: ns-tcpserver Kdump: loaded Not tainted 6.0.0-rc6+ #39
      Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
      pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      pc : des3_ede_encrypt+0x27c/0x460 [libdes]
      lr : 0x3f
      sp : ffff80000ceaa1b0
      x29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280
      x26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003b
      x23: 0000000000802080 x22: 000000000000003d x21: 0000000000000038
      x20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033
      x17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248
      x14: ffff0000e51e4680 x13: ffff80004e2d1348 x12: ffff80004e2d1548
      x11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748
      x8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001b
      x5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 : 000000007f1dd0a3
      x2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872
      Call trace:
       des3_ede_encrypt+0x27c/0x460 [libdes]
       crypto_des3_ede_encrypt+0x1c/0x30 [des_generic]
       crypto_cbc_encrypt+0x148/0x190
       crypto_skcipher_encrypt+0x2c/0x40
       crypto_authenc_encrypt+0xc8/0xfc [authenc]
       crypto_aead_encrypt+0x2c/0x40
       echainiv_encrypt+0x144/0x1a0 [echainiv]
       crypto_aead_encrypt+0x2c/0x40
       esp6_output_tail+0x1c8/0x5d0 [esp6]
       esp6_output+0x120/0x278 [esp6]
       xfrm_output_one+0x458/0x4ec
       xfrm_output_resume+0x6c/0x1f0
       xfrm_output+0xac/0x4ac
       __xfrm6_output+0x130/0x270
       xfrm6_output+0x60/0xec
       ip6_xmit+0x2ec/0x5bc
       inet6_csk_xmit+0xbc/0x10c
       __tcp_transmit_skb+0x460/0x8c0
       tcp_write_xmit+0x348/0x890
       __tcp_push_pending_frames+0x44/0x110
       tcp_rcv_established+0x3c8/0x720
       tcp_v6_do_rcv+0xdc/0x4a0
       tcp_v6_rcv+0xc24/0xcb0
       ip6_protocol_deliver_rcu+0xf0/0x574
       ip6_input_finish+0x48/0x7c
       ip6_input+0x48/0xc0
       ip6_rcv_finish+0x80/0x9c
       xfrm_trans_reinject+0xb0/0xf4
       tasklet_action_common.constprop.0+0xf8/0x134
       tasklet_action+0x30/0x3c
       __do_softirq+0x128/0x368
       do_softirq+0xb4/0xc0
       __local_bh_enable_ip+0xb0/0xb4
       put_cpu_fpsimd_context+0x40/0x70
       kernel_neon_end+0x20/0x40
       sha1_base_do_update.constprop.0.isra.0+0x11c/0x140 [sha1_ce]
       sha1_ce_finup+0x94/0x110 [sha1_ce]
       crypto_shash_finup+0x34/0xc0
       hmac_finup+0x48/0xe0
       crypto_shash_finup+0x34/0xc0
       shash_digest_unaligned+0x74/0x90
       crypto_shash_digest+0x4c/0x9c
       shash_ahash_digest+0xc8/0xf0
       shash_async_digest+0x28/0x34
       crypto_ahash_digest+0x48/0xcc
       crypto_authenc_genicv+0x88/0xcc [authenc]
       crypto_authenc_encrypt+0xd8/0xfc [authenc]
       crypto_aead_encrypt+0x2c/0x40
       echainiv_encrypt+0x144/0x1a0 [echainiv]
       crypto_aead_encrypt+0x2c/0x40
       esp6_output_tail+0x1c8/0x5d0 [esp6]
       esp6_output+0x120/0x278 [esp6]
       xfrm_output_one+0x458/0x4ec
       xfrm_output_resume+0x6c/0x1f0
       xfrm_output+0xac/0x4ac
       __xfrm6_output+0x130/0x270
       xfrm6_output+0x60/0xec
       ip6_xmit+0x2ec/0x5bc
       inet6_csk_xmit+0xbc/0x10c
       __tcp_transmit_skb+0x460/0x8c0
       tcp_write_xmit+0x348/0x890
       __tcp_push_pending_frames+0x44/0x110
       tcp_push+0xb4/0x14c
       tcp_sendmsg_locked+0x71c/0xb64
       tcp_sendmsg+0x40/0x6c
       inet6_sendmsg+0x4c/0x80
       sock_sendmsg+0x5c/0x6c
       __sys_sendto+0x128/0x15c
       __arm64_sys_sendto+0x30/0x40
       invoke_syscall+0x50/0x120
       el0_svc_common.constprop.0+0x170/0x194
       do_el0_svc+0x38/0x4c
       el0_svc+0x28/0xe0
       el0t_64_sync_handler+0xbc/0x13c
       el0t_64_sync+0x180/0x184
      
      Get softirq info by bcc tool:
      ./softirqs -NT 10
      Tracing soft irq event time... Hit Ctrl-C to end.
      
      15:34:34
      SOFTIRQ          TOTAL_nsecs
      block                 158990
      timer               20030920
      sched               46577080
      net_rx             676746820
      tasklet           9906067650
      
      15:34:45
      SOFTIRQ          TOTAL_nsecs
      block                  86100
      sched               38849790
      net_rx             676532470
      timer             1163848790
      tasklet           9409019620
      
      15:34:55
      SOFTIRQ          TOTAL_nsecs
      sched               58078450
      net_rx             475156720
      timer              533832410
      tasklet           9431333300
      
      The tasklet software interrupt takes too much time. Therefore, the
      xfrm_trans_reinject executor is changed from tasklet to workqueue. Add add
      spin lock to protect the queue. This reduces the processing flow of the
      tcp_sendmsg function in this scenario.
      
      Fixes: acf568ee ("xfrm: Reinject transport-mode packets through tasklet")
      Signed-off-by: NLiu Jian <liujian56@huawei.com>
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      
      Conflicts:
      	net/xfrm/xfrm_input.c
      Signed-off-by: NLiu Jian <liujian56@huawei.com>
      12093737
    • Y
      scsi: hisi_sas: Check usage count only when the runtime PM status is RPM_SUSPENDING · 41674625
      Yihang Li 提交于
      driver inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7BNF8
      CVE: NA
      
      ----------------------------------------------------------------------
      
      Users can suspend the machine with 'echo disk > /sys/power/state', but the
      suspend will fail because the SAS controller cannot be suspended:
      
      [root@localhost ~]# echo freeze > /sys/power/state
      -bash: echo: write error: Device or resource busy
      [15104.142955] PM: suspend entry (s2idle)
      ...
      [15104.283465] hisi_sas_v3_hw 0000:32:04.0: entering suspend state
      [15104.283480] hisi_sas_v3_hw 0000:30:04.0: entering suspend state
      [15104.283500] hisi_sas_v3_hw 0000:32:04.0: PM suspend: host status cannot be suspended
      [15104.283508] hisi_sas_v3_hw 0000:30:04.0: PM suspend: host status cannot be suspended
      [15104.283516] hisi_sas_v3_hw 0000:32:04.0: PM: pci_pm_suspend(): suspend_v3_hw+0x0/0x210 [hisi_sas_v3_hw] returns -16
      [15104.283527] hisi_sas_v3_hw 0000:32:04.0: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x1c0 returns -16
      [15104.283524] hisi_sas_v3_hw 0000:30:04.0: PM: pci_pm_suspend(): suspend_v3_hw+0x0/0x210 [hisi_sas_v3_hw] returns -16
      [15104.283533] hisi_sas_v3_hw 0000:32:04.0: PM: failed to suspend async: error -16
      [15104.283536] hisi_sas_v3_hw 0000:30:04.0: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x1c0 returns -16
      [15104.283542] hisi_sas_v3_hw 0000:30:04.0: PM: failed to suspend async: error -16
      
      The problem is that when the ->runtime_suspend() callback suspend_v3_hw()
      is executing, the current runtime PM status is RPM_ACTIVE and the usage
      count of the controller is not 0, so return immediately.
      
      To fix it, Check the device usage count only when the runtime PM status is
      RPM_SUSPENDING.
      Signed-off-by: NYihang Li <liyihang9@huawei.com>
      Signed-off-by: Nxiabing <xiabing12@h-partners.com>
      41674625
    • A
      scsi: hisi_sas: Work around build failure in suspend function · c3500887
      Arnd Bergmann 提交于
      mainline inclusion
      from mainline-v6.4-rc1
      commit e01e2290
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7BNF8
      CVE: NA
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e01e2290f0948ea6d383a5b715738911308b4d2b
      
      ----------------------------------------------------------------------
      
      The suspend/resume functions in this driver seem to have multiple problems,
      the latest one just got introduced by a bugfix:
      
      drivers/scsi/hisi_sas/hisi_sas_v3_hw.c: In function '_suspend_v3_hw':
      drivers/scsi/hisi_sas/hisi_sas_v3_hw.c:5142:39: error: 'struct dev_pm_info' has no member named 'usage_count'
       5142 |         if (atomic_read(&device->power.usage_count)) {
      drivers/scsi/hisi_sas/hisi_sas_v3_hw.c: In function '_suspend_v3_hw':
      drivers/scsi/hisi_sas/hisi_sas_v3_hw.c:5142:39: error: 'struct dev_pm_info' has no member named 'usage_count'
       5142 |         if (atomic_read(&device->power.usage_count)) {
      
      As far as I can tell, the 'usage_count' is not meant to be accessed by
      device drivers at all, though I don't know what the driver is supposed to
      do instead.
      
      Another problem is the use of the deprecated UNIVERSAL_DEV_PM_OPS(), and
      marking functions as __maybe_unused to avoid warnings about unused
      functions.  This should probably be changed to using
      DEFINE_RUNTIME_DEV_PM_OPS().
      
      Both changes require actually understanding what the driver needs to do,
      and being able to test this, so instead here is the simplest patch to make
      it pass the randconfig builds instead.
      
      Fixes: e368d38c ("scsi: hisi_sas: Exit suspend state when usage count is greater than 0")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20230405083611.3376739-1-arnd@kernel.orgReviewed-by: NXiang Chen <chenxiang66@hisilicon.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: Nxiabing <xiabing12@h-partners.com>
      c3500887
    • Y
      scsi: hisi_sas: Block requests before take debugfs snapshot · fc7dbc50
      Yihang Li 提交于
      driver inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7BNF8
      CVE: NA
      
      ----------------------------------------------------------------------
      
      When the FIO is running and the dump is triggered continuously, some SATA
      I/Os fail to be returned to the upper layer due to the setting of
      HISI_SAS_REJECT_CMD_BIT. The SCSI layer invokes the error processing
      thread. However, sas_ata_hard_reset() also fails to be reset due to the
      setting of HISI_SAS_REJECT_CMD_BIT. As a result, the device is disabled.
      Call scsi_block_requests() and wait command complete before setting
      HISI_SAS_REJECT_CMD_BIT to avoid SATA I/O failures.
      Signed-off-by: NYihang Li <liyihang9@huawei.com>
      Signed-off-by: Nxiabing <xiabing12@h-partners.com>
      fc7dbc50
    • Q
      scsi: hisi_sas: Add slave_destroy interface for v3 hw · 63184f79
      Qi Liu 提交于
      driver inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7BNF8
      CVE: NA
      
      ----------------------------------------------------------------------
      
      A WARNING is triggered when executing link reset of remote PHY
      and rmmod SAS driver simultaneously. Following is the WARNING log:
      
      WARNING: CPU: 61 PID: 21818 at drivers/base/core.c:1347 __device_links_no_driver+0xb4/0xc0
       Call trace:
        __device_links_no_driver+0xb4/0xc0
        device_links_driver_cleanup+0xb0/0xfc
        __device_release_driver+0x198/0x23c
        device_release_driver+0x38/0x50
        bus_remove_device+0x130/0x140
        device_del+0x184/0x434
        __scsi_remove_device+0x118/0x150
        scsi_remove_target+0x1bc/0x240
        sas_rphy_remove+0x90/0x94
        sas_rphy_delete+0x24/0x3c
        sas_destruct_devices+0x64/0xa0 [libsas]
        sas_revalidate_domain+0xe4/0x150 [libsas]
        process_one_work+0x1e0/0x46c
        worker_thread+0x15c/0x464
        kthread+0x160/0x170
        ret_from_fork+0x10/0x20
       ---[ end trace 71e059eb58f85d4a ]---
      
      During SAS phy up, link->status is set to DL_STATE_AVAILABLE in
      device_links_driver_bound, then this setting influences
      __device_links_no_driver() before driver rmmod and caused WARNING.
      
      So we add the slave_destroy interface, to make sure link is removed
      after flush workque.
      
      Fixes: 16fd4a7c ("scsi: hisi_sas: Add device link between SCSI devices and hisi_hba")
      Signed-off-by: NQi Liu <liuqi115@huawei.com>
      Signed-off-by: NJohn Garry <john.garry@huawei.com>
      Signed-off-by: Nxiabing <xiabing12@h-partners.com>
      63184f79
    • O
      !996 [sync] PR-990: ubi: Fix deadlock caused by recursively holding work_sem · 5ab0cca4
      openeuler-ci-bot 提交于
      Merge Pull Request from: @openeuler-sync-bot 
       
      
      Origin pull request: 
      https://gitee.com/openeuler/kernel/pulls/990 
       
      PR sync from:  ZhaoLong Wang <wangzhaolong1@huawei.com>
       https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/3EWABXFSAAORW3LZWZCYAYWH3W3EEKZU/ 
      Fix deadlock caused by recursively holding work_sem
      
      Lee Jones (1):
        mtd: ubi: wl: Fix a couple of kernel-doc issues
      
      ZhaoLong Wang (1):
        ubi: Fix deadlock caused by recursively holding work_sem
      
      
      -- 
      2.39.2
       
       
      Link:https://gitee.com/openeuler/kernel/pulls/996 
      
      Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> 
      Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
      5ab0cca4
    • O
      !1001 [sync] PR-928: hikey9xx: Fixed incorrect use of kfree to free sreg · 58d4723f
      openeuler-ci-bot 提交于
      Merge Pull Request from: @openeuler-sync-bot 
       
      
      Origin pull request: 
      https://gitee.com/openeuler/kernel/pulls/928 
       
      PR sync from:  ZhaoLong Wang <wangzhaolong1@huawei.com>
       https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/TB3Q7BQ6ZAGBRI7WS6JPCAF77IWURUIW/ 
       
       
      Link:https://gitee.com/openeuler/kernel/pulls/1001 
      
      Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> 
      Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
      58d4723f
    • O
      !1018 [sync] PR-944: nbd: get config_lock before sock_shutdown · f384ae3d
      openeuler-ci-bot 提交于
      Merge Pull Request from: @openeuler-sync-bot 
       
      
      Origin pull request: 
      https://gitee.com/openeuler/kernel/pulls/944 
       
      PR sync from:  Zhong Jinghua <zhongjinghua@huawei.com>
       https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/SH7IMWAMZDZBA352XEQZ4WD6CFY3EGCW/ 
       
       
      Link:https://gitee.com/openeuler/kernel/pulls/1018 
      
      Reviewed-by: Hou Tao <houtao1@huawei.com> 
      Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
      f384ae3d
    • O
      !1033 perf: hns3: add event suppport for ROH and default use hardware event 0 as group leader event · d3394d89
      openeuler-ci-bot 提交于
      Merge Pull Request from: @svishen 
       
      This pull request add ROH event and default use hardware event 0 as group leader event
      
      (1)perf: hns3: add event suppport for ROH
      (2)perf: hns3: default use hardware event 0 as group leader event
      
      issue:
      https://gitee.com/openeuler/kernel/issues/I7BY7T 
       
      Link:https://gitee.com/openeuler/kernel/pulls/1033 
      
      Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
      d3394d89
    • L
      vfio/migration: bugfix lost interruption after live migration · c796499d
      Longfang Liu 提交于
      driver inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7BTMW
      CVE: NA
      
      ----------------------------------------------------------------------
      
      During repeated live migration. There may be a problem with missing
      interrupts. In this case, re-send the doorbell on the migration end.
      Let QM report an interrupt again, and migrate the interrupt to the
      destination together.
      Thereby preventing the problem of interrupt loss.
      
      fixec: a0464f0b ("vfio/hisilicon: add acc live migration driver")
      Signed-off-by: NLongfang Liu <liulongfang@huawei.com>
      Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>
      (cherry picked from commit a60b29d3)
      c796499d
    • L
      crypto: hisilicon/qm - fix EQ/AEQ interrupt issue · f325b4da
      Longfang Liu 提交于
      driver inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7BTMW
      CVE: NA
      
      ----------------------------------------------------------------------
      
      During a live migration operation. In order to prevent the problem
      of EQ/AEQ interrupt loss. Migration driver will trigger an EQ/AEQ
      doorbell at the end of the migration.
      This operation may cause a double interrupt of EQ/AEQ. In order
      to ensure that the interrupt processing is normal. The interrupt
      handling of EQ/AEQ needs to be updated to prevent interrupt
      duplication.
      
      fixec: a0464f0b ("vfio/hisilicon: add acc live migration driver")
      Signed-off-by: NLongfang Liu <liulongfang@huawei.com>
      Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>
      (cherry picked from commit 24a30ee7)
      f325b4da