1. 11 6月, 2023 4 次提交
  2. 09 6月, 2023 30 次提交
  3. 08 6月, 2023 6 次提交
    • 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