1. 08 6月, 2023 10 次提交
  2. 07 6月, 2023 30 次提交
    • Z
      ubi: Fix deadlock caused by recursively holding work_sem · 9d8256f3
      ZhaoLong Wang 提交于
      maillist inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I6K5OH
      CVE: NA
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f773f0a331d6c41733b17bebbc1b6cae12e016f5
      
      --------------------------------
      
      During the processing of the bgt, if the sync_erase() return -EBUSY
      or some other error code in __erase_worker(),schedule_erase() called
      again lead to the down_read(ubi->work_sem) hold twice and may get
      block by down_write(ubi->work_sem) in ubi_update_fastmap(),
      which cause deadlock.
      
                ubi bgt                        other task
       do_work
        down_read(&ubi->work_sem)          ubi_update_fastmap
        erase_worker                         # Blocked by down_read
         __erase_worker                      down_write(&ubi->work_sem)
          schedule_erase
           schedule_ubi_work
            down_read(&ubi->work_sem)
      
      Fix this by changing input parameter @nested of the schedule_erase() to
      'true' to avoid recursively acquiring the down_read(&ubi->work_sem).
      
      Also, fix the incorrect comment about @nested parameter of the
      schedule_erase() because when down_write(ubi->work_sem) is held,
      the @nested is also need be true.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=217093
      Fixes: 2e8f08de ("ubi: Fix races around ubi_refill_pools()")
      Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      9d8256f3
    • L
      mtd: ubi: wl: Fix a couple of kernel-doc issues · 9fea0e12
      Lee Jones 提交于
      mainline inclusion
      from mainline-v5.11-rc1
      commit ab4e4de9
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I6K5OH
      CVE: NA
      
      Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ab4e4de9fd8b469823a645f05f2c142e9270b012
      
      --------------------------------
      
      Fixes the following W=1 kernel build warning(s):
      
       drivers/mtd/ubi/wl.c:584: warning: Function parameter or member 'nested' not described in 'schedule_erase'
       drivers/mtd/ubi/wl.c:1075: warning: Excess function parameter 'shutdown' description in '__erase_worker'
      
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Miquel Raynal <miquel.raynal@bootlin.com>
      Cc: Vignesh Raghavendra <vigneshr@ti.com>
      Cc: linux-mtd@lists.infradead.org
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Link: https://lore.kernel.org/linux-mtd/20201109182206.3037326-13-lee.jones@linaro.orgSigned-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      9fea0e12
    • O
      !940 net: hns3: related bugfixes, refactoring, and cleanup · cbad7a99
      openeuler-ci-bot 提交于
      Merge Pull Request from: @svishen 
       
      This pull request for hns3 related bugfixes, refactoring, and cleanup
      
      (1)perf: pmu: fix set wrong filter mode for running events issue
      (2)net: hns3: fix GRE checksum offload issue
      (3)net: hns3: fix the imp capability bit cannot exceed 32 bits issue
      (4)net: hns3: add tm flush when setting tm
      (5)net: hns3: refactor hclge_update_desc_vfid for extension
      (6)net: hns3: fix strncpy() not using dest-buf length as length issue
      (7)net: hns3: restore user pause configure when disable autoneg
      
      issue:
      https://gitee.com/openeuler/kernel/issues/I7B8SA 
       
      Link:https://gitee.com/openeuler/kernel/pulls/940 
      
      Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
      cbad7a99
    • O
      !954 block: iocost bugfix · 6e15a541
      openeuler-ci-bot 提交于
      Merge Pull Request from: @ci-robot 
       
      PR sync from:  Li Nan <linan122@huawei.com>
       https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/VXKLPFKREQW36DJSNHXJEEDMYS5EJXSZ/ 
      This patch series fix iocost life cycle bug.
      
      Li Nan (2):
        block: fix null-pointer dereference in ioc_pd_init
        block: fix order error in blk_release_queue
      
      
      -- 
      2.39.2
       
       
      Link:https://gitee.com/openeuler/kernel/pulls/954 
      
      Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
      Reviewed-by: Hou Tao <houtao1@huawei.com> 
      Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
      6e15a541
    • O
      !946 icost bugfix · 9837ce51
      openeuler-ci-bot 提交于
      Merge Pull Request from: @ci-robot 
       
      PR sync from:  Li Nan <linan122@huawei.com>
       https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/EMFAV2GNNSOMDT4IALQKWD6C4CHZT436/ 
      This patch series fix iocost bug.
      
      Li Nan (1):
        blk-iocost: fix UAF in ioc_pd_free
      
      Yu Kuai (3):
        blk-iocost: track whether iocg is still online
        blk-iocost: don't throttle bio if iocg is offlined
        blk-iocost: dispatch all throttled bio in ioc_pd_offline
      
      
      -- 
      2.39.2
       
       
      Link:https://gitee.com/openeuler/kernel/pulls/946 
      
      Reviewed-by: Hou Tao <houtao1@huawei.com> 
      Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
      Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
      9837ce51
    • O
      !970 [sync] PR-903: backport block bugfix · 0e858041
      openeuler-ci-bot 提交于
      Merge Pull Request from: @openeuler-sync-bot 
       
      
      Origin pull request: 
      https://gitee.com/openeuler/kernel/pulls/903 
       
      This patch series fix block layer bug.
      3 patchs fix iocost bug. Other patchs fix raid10 and badblocks bug.
       
       
      Link:https://gitee.com/openeuler/kernel/pulls/970 
      
      Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
      Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
      0e858041
    • O
      !356 x86/boot/compressed: Register dummy NMI handler in EFI boot loader, to avoid kdump crashes · c52ded8c
      openeuler-ci-bot 提交于
      Merge Pull Request from: @henryze 
       
      The artificially test code causes the panic cpu to be under the mce context which cannot respond to interrupts(includes NMIs) for a long time. At this duration, watchdog timer could send NMI timeout interrupt to the cpu.
      
      Until the panic cpu runs into the EFI loader, because of the function of switching page tables newly added by the community, the `iret` instruction let cpu restore the ability to respond to nmi interrupts, but the loader does not register the nmi interrupt handler in idt, that results an abnormal restart of the hardware, and the kdump process has been interrupted so far.
      
      The repair patch registers the nmi handler for the EFI loader. After a page fault exits, even if nmi is raised, it can be processed correctly to ensure the smooth completion of the kdump process. 
       
      Link:https://gitee.com/openeuler/kernel/pulls/356 
      
      Reviewed-by: Wei Li <liwei391@huawei.com> 
      Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> 
      Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
      c52ded8c
    • O
      !967 Support dynamic_hugetlb on arm64 and fix some bug · 5ee27742
      openeuler-ci-bot 提交于
      Merge Pull Request from: @ci-robot 
       
      PR sync from:  Liu Shixin <liushixin2@huawei.com>
       https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/GMXFWIIVGDUCTVDK44XS2U2JPUIK4ZEN/ 
      Support dynamic_hugetlb on arm64 and fix some bug.
      
      Liu Shixin (6):
        mm/dynamic_hugetlb: fix kabi broken when enable CONFIG_DYNAMIC_HUGETLB
          on arm64
        mm/dynamic_hugetlb: support dynamic hugetlb on arm64
        mm/dynamic_hugetlb: isolate hugepage without dissolve
        mm/dynamic_hugetlb: replace spin_lock with mutex_lock and fix kabi
          broken
        mm/dynamic_hugetlb: set PagePool to bad page
        mm/dynamic_hugetlb: fix type error of pfn in
          __hpool_split_gigantic_page()
      
      
      -- 
      2.25.1
       
       
      Link:https://gitee.com/openeuler/kernel/pulls/967 
      
      Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
      Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
      5ee27742
    • W
      crypto: hisilicon/qm - alloc buffer to set and get xqc · f746895c
      Weili Qian 提交于
      driver inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7BJW9
      CVE: NA
      
      ----------------------------------------------------------------------
      
      If the temporarily applied memory is used to set or get the xqc
      information, the driver will release the memory after waiting for the
      mailbox times out. However, the hardware still performs the operation,
      the released memory may be written by hardware. Therefore, when load
      driver, memory is applied for xqc configuration.
      
      Fixes: 263c9959 ("crypto: hisilicon - add queue management driver for HiSilicon QM module")
      Signed-off-by: NWeili Qian <qianweili@huawei.com>
      Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>
      f746895c
    • W
      crypto: hisilicon/qm - fix the pf2vf timeout when device reset · 917b6be3
      Weili Qian 提交于
      driver inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7BJW9
      CVE: NA
      
      ----------------------------------------------------------------------
      
      When funcitons communicate with each other, if the mailbox operation fails,
      funciton cannot obtain the message from the communication source.
      If the vf does not receive the message from pf to stop function when reset,
      it will cause the vf to be unavailable.
      
      For the device reset scenario:
      1. Increase the QM_DEVICE_DOWN state. Before IO operation,
      check the state to avoid mailbox busy during communication.
      2. When vf obtains pf message, if the mailbox fails, it is
      considered to be a device reset, and stop function directly.
      When pf sends reset message to vf, if the mailbox fails, it
      still send interrupt event to vf.
      3. Increase the response time of PF waiting for vf.
      
      Fixes: 46fdbecf ("crypto: hisilicon/qm - enable PF and VFs communication")
      Signed-off-by: NWeili Qian <qianweili@huawei.com>
      Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>
      917b6be3
    • W
      vfio/migration: obtain the mailbox configuration at one time · 87484bc1
      Weili Qian 提交于
      driver inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7BJW9
      CVE: NA
      
      ----------------------------------------------------------------------
      
      The mailbox configuration(128 bits) needs to be obtained from
      the hardware at one time. If the mailbox configuration is
      obtained for multiple times, the read value may be incorrect.
      Use the instruction to read mailbox data instead of readl().
      
      Fixes: a0464f0b ("vfio/hisilicon: add acc live migration driver")
      Signed-off-by: NWeili Qian <qianweili@huawei.com>
      Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>
      87484bc1
    • W
      crypto: hisilicon/qm - obtain the mailbox configuration at one time · be56f84d
      Weili Qian 提交于
      driver inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I7BJW9
      CVE: NA
      
      ----------------------------------------------------------------------
      
      The mailbox configuration(128 bits) needs to be obtained from the
      hardware at one time. If the mailbox configuration is obtained for
      multiple times, the read value may be incorrect. Use the instruction
      to read mailbox data instead of readl().
      
      Fixes: 263c9959 ("crypto: hisilicon - add queue management driver for HiSilicon QM module")
      Signed-off-by: NWeili Qian <qianweili@huawei.com>
      Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>
      be56f84d
    • S
      SCSI: SSSRAID: fix the issue that HDD unexpected high latency occured · 220dfe07
      Steven Song 提交于
      3snic inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I77ADC
      CVE: NA
      
      ------------------------------------------
      
      [issue description]
      HDD will occur unexpected high latency when pressure, concurrent, time all big enough.
      [steps to reproduce the problem]
      1. 16 HDDs create 16 bare disks, each disk starts a thread, each thread
         is bound to a core, and the queue depth is 64
      2. Issue read & write mixed I/O to the drive letters corresponding to
         rawdrive
      3. After the long read and write IO period is completed, observe the
         maximum delay in the printout of the fio tool
      [Probability of occurrence]
      100%
      [Expected results]
      The maximum delay in the printout of the FIO tool does not exceed 10 seconds
      [Root cause]
      Muti-queue implementation will cause high concurrent in each different hardware
      dispatch queue is not suitable for HDD.
      [Solution]
      Introduce work_mode module parameter to fastened total I/O queue number
      equal to 1 and maximum concurrent I/O is 4k (according to RAID cured performance)
      Signed-off-by: NSteven Song <steven.song@3snic.com>
      Reviewed-by: liangry<liangry1@3snic.com>
      Reviewed-by: Jiang Yu<yujiang@3snic.com>
      220dfe07
    • O
      !968 Fix ORC unwinder on paravirt {save,restore}_fl · 7bfe5365
      openeuler-ci-bot 提交于
      Merge Pull Request from: @ci-robot 
       
      PR sync from:  Chen Zhongjin <chenzhongjin@huawei.com>
       https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/C2NOJBSCQVMEFEIEDAK3YKPNYQ67TO7J/ 
      ISSUE: gitee.com/openeuler/kernel/issues/I6DK3O
      
      Chen Zhongjin (2):
        x86/unwind: Fix orc entry for paravirt {save,restore}_fl
        x86/unwind: Fix check_paravirt() calls orc_find() before declaration
      
      
      -- 
      2.17.1
       
       
      Link:https://gitee.com/openeuler/kernel/pulls/968 
      
      Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
      Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
      7bfe5365
    • O
      !969 kobject: Fix slab-out-of-bounds in fill_kobj_path() · 3aa45993
      openeuler-ci-bot 提交于
      Merge Pull Request from: @ci-robot 
       
      PR sync from:  Xia Fukun <xiafukun@huawei.com>
       https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/BKNZ3SWVHTMMTKLWPREORX4R6EEUURB6/ 
       
       
      Link:https://gitee.com/openeuler/kernel/pulls/969 
      
      Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com> 
      Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
      Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
      3aa45993
    • L
      md/raid10: fix incorrect done of recovery · 5a94d9b9
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188535, https://gitee.com/openeuler/kernel/issues/I6O61Q
      CVE: NA
      
      --------------------------------
      
      Recovery will go to giveup and let chunks_skipped++ in raid10_sync_request
      if there are some bad_blocks, and it will return max_sector when
      chunks_skipped >= geo.raid_disks. Now, recovery fail and data is
      inconsistent but user think recovery is done, it is wrong.
      
      Fix it by set mirror's recovery_disabled and spare device shouln't be
      added to here.
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit b0ac58c9)
      5a94d9b9
    • L
      md/raid10: fix null-ptr-deref in raid10_sync_request · b9ebfe4f
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188378, https://gitee.com/openeuler/kernel/issues/I6GGV7
      CVE: NA
      
      --------------------------------
      
      init_resync() init mempool and set conf->have_replacemnt at the begaining
      of sync, close_sync() free the mempool when sync is completed.
      
      After commit 7e83ccbe ("md/raid10: Allow skipping recovery when clean
      arrays are assembled"), recovery might skipped and init_resync() is called
      but close_sync() is not. null-ptr-deref occurs as below:
        1) creat a array, wait for resync to complete, mddev->recovery_cp is set
           to MaxSector.
        2) recovery is woken and it is skipped. conf->have_replacement is set to
           0 in init_resync(). close_sync() not called.
        3) some io errors and rdev A is set to WantReplacement.
        4) a new device is added and set to A's replacement.
        5) recovery is woken, A have replacement, but conf->have_replacemnt is
           0. r10bio->dev[i].repl_bio will not be alloced and null-ptr-deref
           occurs.
      
      Fix it by not init_resync() if recovery skipped.
      
      Fixes: 7e83ccbe md/raid10: Allow skipping recovery when clean arrays are assembled")
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit 2de30b8f)
      b9ebfe4f
    • L
      block/badblocks: fix badblocks loss when badblocks combine · d3cb3f9d
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188569, https://gitee.com/openeuler/kernel/issues/I6ZG5B
      CVE: NA
      
      --------------------------------
      
      badblocks will loss if we set it as below:
      
        # echo 1 1 > bad_blocks
        # echo 3 1 > bad_blocks
        # echo 1 5 > bad_blocks
        # cat bad_blocks
          1 3
      
      we will combine badblocks if there is an intersection between p[lo] and
      p[hi] in badblocks_set(). The end of new badblocks is p[hi]'s end now. but
      p[lo] may cross p[hi] and new end should be the larger of p[lo] and p[hi].
        lo: |------------------------|
        hi:		|--------|
      
      Fixes: 9e0e252a ("badblocks: Add core badblock management code")
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit e35a7762)
      d3cb3f9d
    • L
      block/badblocks: fix the bug of reverse order · 1edc6389
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188569, https://gitee.com/openeuler/kernel/issues/I6ZG5B
      CVE: NA
      
      --------------------------------
      
      Order of badblocks will be reversed if we set a large area at once. 'hi'
      remains unchanged while adding continuous badblocks is wrong, the next
      setting is greater than 'hi', it should be added to the next position.
      Let 'hi' +1 each cycle.
      
        # echo 0 2048 > bad_blocks
        # cat bad_blocks
          1536 512
          1024 512
          512 512
          0 512
      
      Fixes: 9e0e252a ("badblocks: Add core badblock management code")
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit f9a3eea0)
      1edc6389
    • L
      md: fix unexpected changes of return value in rdev_set_badblocks · f0ad5694
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188569, https://gitee.com/openeuler/kernel/issues/I6XBZQ
      CVE: NA
      
      --------------------------------
      
      If we set any badblocks fail, we will remove this rdev(set it to Faulty
      or set recovery_disabled). Previous patch "md/raid10: fix io hung in
      md_wait_for_blocked_rdev()" check badblocks->changed instead of return
      value in rdev_set_badblocks(), but return value of this func also changed
      accordingly, which is not what we expected.
      
      Keep the return value consistent with before.
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NYu Kuai <yukuai3@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit bebf3d97)
      f0ad5694
    • L
      md/raid10: fix io hung in md_wait_for_blocked_rdev() · be2f0e0c
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188569, https://gitee.com/openeuler/kernel/issues/I6XBZQ
      CVE: NA
      
      --------------------------------
      
      If badblocks are merged but bb->count exceedded, badblocks_set() will
      return 1 and merged badblocks will become un-ack. rdev_set_badblocks()
      will not set sb_flags and wakeup mddev->thread, io wait in
      md_wait_for_blocked_rdev() will hung because BlockedBadBlocks may not be
      cleared.
      
      Fix it by checking badblocks->changed instead of return value. This flag
      is set when badblocks changes.
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NYu Kuai <yukuai3@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit c23e1cd1)
      be2f0e0c
    • L
      block: Only set bb->changed when badblocks changes · e49b2409
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188569, https://gitee.com/openeuler/kernel/issues/I6XBZQ
      CVE: NA
      
      --------------------------------
      
      bb->changed and unacked_exist is set and badblocks_update_acked() is
      involked even if no badblocks changes in badblocks_set(). Only update
      them when badblocks changes.
      
      Fixes: 9e0e252a ("badblocks: Add core badblock management code")
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NYu Kuai <yukuai3@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit 78cba163)
      e49b2409
    • L
      md/raid10: fix incorrect counting of rdev->nr_pending · e60d02db
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188605, https://gitee.com/openeuler/kernel/issues/I6ZJ3T
      CVE: NA
      
      --------------------------------
      
      We get rdev from mirrors.replacement twice in raid10_write_request().
      If replacement changes between two reads, it will increase A->nr_pending
      and decrease B->nr_pending.
      
        T1 (write)	   T2 (remove)	    T3 (add)
                         raid10_remove_disk
      
        raid10_write_request
         rrdev = conf->mirrors[d].replacement; ->rdev A
         A nr_pending++
      
                          p->rdev = p->replacement; ->rdev A
                          p->replacement = NULL;
      
      				    //A it set to WantReplacement
                                          raid10_add_disk
      				     p->replacement = rdev; ->rdev B
      
         if blocked_rdev
          rdev = conf->mirrors[d].replacement; ->rdev B
          B nr_pending--
      
      We will record rdev in r10bio, and get rdev from r10bio to fix it.
      
      Fixes: 475b0321 ("md/raid10: writes should get directed to replacement as well as original.")
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit 7b3b8187)
      e60d02db
    • L
      md/raid10: remove WANR_ON_ONCE in raid10_end_write_request · 08b0defd
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188605, https://gitee.com/openeuler/kernel/issues/I6GOYF
      CVE: NA
      
      --------------------------------
      
      It might read mirror.redev first and then mirror->replacement because of
      memory reordering in raid10_end_write_request(), WARN_ON occurs if we
      remove disk at the same time.
      
        T1 remove			T2 io end
        raid10_remove_disk		raid10_end_write_request
         p->rdev = NULL
      				 read rdev -> NULL
         smp_mb
         p->replacement = NULL
      				 read replacement -> NULL
      
      It is meaningless to compare rdev with mirror->rdev after we get it from
      r10_bio in raid10_end_write_request(). Remove this WANR_ON_ONCE.
      
      Fixes: 2ecf5e6ecbfd ("md/raid10: fix uaf if replacement replaces rdev")
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit a3ebeed7)
      08b0defd
    • L
      md/raid10: fix uaf if replacement replaces rdev · f82d78c6
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188377, https://gitee.com/openeuler/kernel/issues/I6GOYF
      CVE: NA
      
      --------------------------------
      
      After commit 4ca40c2c ("md/raid10: Allow replacement device to be
      replace old drive.") mirrors->replacement can replace rdev during
      replacement's io pending, and repl_bio will write rdev (see
      raid10_write_one_disk()). We will get wrong device by r10conf in
      raid10_end_write_request(). In which case, r10_bio->devs[slot].repl_bio
      will be put but not set to IO_MADE_GOOD, and it will be put again later in
      raid_end_bio_io(), uaf occurs.
      
      Fix it by using r10_bio to record rdev. Put the operations of io fail and
      no replacement together, so no need to change repl.
      
        ==================================================================
        BUG: KASAN: use-after-free in bio_flagged include/linux/bio.h:238 [inline]
        BUG: KASAN: use-after-free in bio_put+0x78/0x80 block/bio.c:650
        Read of size 2 at addr ffff888116524dd4 by task md0_raid10/2618
      
        CPU: 0 PID: 2618 Comm: md0_raid10 Not tainted 5.10.0+ #3
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
        sd 0:0:0:0: rejecting I/O to offline device
        Call Trace:
         __dump_stack lib/dump_stack.c:77 [inline]
         dump_stack+0x107/0x167 lib/dump_stack.c:118
         print_address_description.constprop.0+0x1c/0x270 mm/kasan/report.c:390
         __kasan_report mm/kasan/report.c:550 [inline]
         kasan_report.cold+0x22/0x3a mm/kasan/report.c:567
         bio_flagged include/linux/bio.h:238 [inline]
         bio_put+0x78/0x80 block/bio.c:650
         put_all_bios drivers/md/raid10.c:248 [inline]
         free_r10bio drivers/md/raid10.c:257 [inline]
         raid_end_bio_io+0x3b5/0x590 drivers/md/raid10.c:309
         handle_write_completed drivers/md/raid10.c:2699 [inline]
         raid10d+0x2f85/0x5af0 drivers/md/raid10.c:2759
         md_thread+0x444/0x4b0 drivers/md/md.c:7932
         kthread+0x38c/0x470 kernel/kthread.c:313
         ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:299
      
        Allocated by task 1400:
         kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
         kasan_set_track mm/kasan/common.c:56 [inline]
         set_alloc_info mm/kasan/common.c:498 [inline]
         __kasan_kmalloc.constprop.0+0xb5/0xe0 mm/kasan/common.c:530
         slab_post_alloc_hook mm/slab.h:512 [inline]
         slab_alloc_node mm/slub.c:2923 [inline]
         slab_alloc mm/slub.c:2931 [inline]
         kmem_cache_alloc+0x144/0x360 mm/slub.c:2936
         mempool_alloc+0x146/0x360 mm/mempool.c:391
         bio_alloc_bioset+0x375/0x610 block/bio.c:486
         bio_clone_fast+0x20/0x50 block/bio.c:711
         raid10_write_one_disk+0x166/0xd30 drivers/md/raid10.c:1240
         raid10_write_request+0x1600/0x2c90 drivers/md/raid10.c:1484
         __make_request drivers/md/raid10.c:1508 [inline]
         raid10_make_request+0x376/0x620 drivers/md/raid10.c:1537
         md_handle_request+0x699/0x970 drivers/md/md.c:451
         md_submit_bio+0x204/0x400 drivers/md/md.c:489
         __submit_bio block/blk-core.c:959 [inline]
         __submit_bio_noacct block/blk-core.c:1007 [inline]
         submit_bio_noacct+0x2e3/0xcf0 block/blk-core.c:1086
         submit_bio+0x1a0/0x3a0 block/blk-core.c:1146
         submit_bh_wbc+0x685/0x8e0 fs/buffer.c:3053
         ext4_commit_super+0x37e/0x6c0 fs/ext4/super.c:5696
         flush_stashed_error_work+0x28b/0x400 fs/ext4/super.c:791
         process_one_work+0x9a6/0x1590 kernel/workqueue.c:2280
         worker_thread+0x61d/0x1310 kernel/workqueue.c:2426
         kthread+0x38c/0x470 kernel/kthread.c:313
         ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:299
      
        Freed by task 2618:
         kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
         kasan_set_track+0x1c/0x30 mm/kasan/common.c:56
         kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:361
         __kasan_slab_free+0x151/0x180 mm/kasan/common.c:482
         slab_free_hook mm/slub.c:1569 [inline]
         slab_free_freelist_hook+0xa9/0x180 mm/slub.c:1608
         slab_free mm/slub.c:3179 [inline]
         kmem_cache_free+0xcd/0x3d0 mm/slub.c:3196
         mempool_free+0xe3/0x3b0 mm/mempool.c:500
         bio_free+0xe2/0x140 block/bio.c:266
         bio_put+0x58/0x80 block/bio.c:651
         raid10_end_write_request+0x885/0xb60 drivers/md/raid10.c:516
         bio_endio+0x376/0x6a0 block/bio.c:1465
         req_bio_endio block/blk-core.c:289 [inline]
         blk_update_request+0x5f5/0xf40 block/blk-core.c:1525
         blk_mq_end_request+0x4c/0x510 block/blk-mq.c:654
         blk_flush_complete_seq+0x835/0xd80 block/blk-flush.c:204
         flush_end_io+0x7b7/0xb90 block/blk-flush.c:261
         __blk_mq_end_request+0x282/0x4c0 block/blk-mq.c:645
         scsi_end_request+0x3a8/0x850 drivers/scsi/scsi_lib.c:607
         scsi_io_completion+0x3f5/0x1320 drivers/scsi/scsi_lib.c:970
         scsi_softirq_done+0x11b/0x490 drivers/scsi/scsi_lib.c:1448
         blk_mq_complete_request block/blk-mq.c:788 [inline]
         blk_mq_complete_request+0x84/0xb0 block/blk-mq.c:785
         scsi_mq_done+0x155/0x360 drivers/scsi/scsi_lib.c:1603
         virtscsi_vq_done drivers/scsi/virtio_scsi.c:184 [inline]
         virtscsi_req_done+0x14c/0x220 drivers/scsi/virtio_scsi.c:199
         vring_interrupt drivers/virtio/virtio_ring.c:2061 [inline]
         vring_interrupt+0x27a/0x300 drivers/virtio/virtio_ring.c:2047
         __handle_irq_event_percpu+0x2f8/0x830 kernel/irq/handle.c:156
         handle_irq_event_percpu kernel/irq/handle.c:196 [inline]
         handle_irq_event+0x105/0x280 kernel/irq/handle.c:213
         handle_edge_irq+0x258/0xd20 kernel/irq/chip.c:828
         asm_call_irq_on_stack+0xf/0x20
         __run_irq_on_irqstack arch/x86/include/asm/irq_stack.h:48 [inline]
         run_irq_on_irqstack_cond arch/x86/include/asm/irq_stack.h:101 [inline]
         handle_irq arch/x86/kernel/irq.c:230 [inline]
         __common_interrupt arch/x86/kernel/irq.c:249 [inline]
         common_interrupt+0xe2/0x190 arch/x86/kernel/irq.c:239
         asm_common_interrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:626
      
      Fixes: 4ca40c2c ("md/raid10: Allow replacement device to be replace old drive.")
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit af959500)
      f82d78c6
    • L
      md/raid10: fix null-ptr-deref of mreplace in raid10_sync_request · 662a20e2
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188527, https://gitee.com/openeuler/kernel/issues/I6O3HO
      CVE: NA
      
      --------------------------------
      
      need_replace will be set to 1 if no-Faulty mreplace exists, and mreplace
      will be deref later. However, the latter check of mreplace might set
      mreplace to NULL, null-ptr-deref occurs if need_replace is 1 at this time.
      
      Fix it by merging two checks into one.
      
      Fixes: ee37d731 ("md/raid10: Fix raid10 replace hang when new added disk faulty")
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NYu Kuai <yukuai3@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit 7718714e)
      662a20e2
    • L
      md/raid10: fix io loss while replacement replace rdev · dd97dc44
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188787, https://gitee.com/openeuler/kernel/issues/I78YIW
      CVE: NA
      
      --------------------------------
      
      When we remove a disk which has replacement, first set rdev to NULL
      and then set replacement to rdev, finally set replacement to NULL (see
      raid10_remove_disk()). If io is submitted during the same time, it might
      read both rdev and replacement as NULL, and io will not be submitted.
      
        rdev -> NULL
                              read rdev
        replacement -> NULL
                              read replacement
      
      Fix it by reading replacement first and rdev later, meanwhile, use smp_mb()
      to prevent memory reordering.
      
      Fixes: 475b0321 ("md/raid10: writes should get directed to replacement as well as original.")
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NYu Kuai <yukuai3@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit e8025850)
      dd97dc44
    • L
      md/raid10: prioritize adding disk to 'removed' mirror · 106e6562
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188804, https://gitee.com/openeuler/kernel/issues/I78YIS
      CVE: NA
      
      --------------------------------
      
      When add a new disk to raid10, it will traverse conf->mirror from start
      and find one of the following mirror:
        1. mirror->rdev is set to WantReplacement and it have no replacement,
           set new disk to mirror->replacement.
        2. no rdev, set new disk to mirror->rdev.
      
      There is a array as below (sda is set to WantReplacement):
      
          Number   Major   Minor   RaidDevice State
             0       8        0        0      active sync set-A   /dev/sda
             -       0        0        1      removed
             2       8       32        2      active sync set-A   /dev/sdc
             3       8       48        3      active sync set-B   /dev/sdd
      
      Use 'mdadm --add' to add a new disk to this array, the new disk will
      become sda's replacement instead of add to removed position, which is
      confusing for users. Meanwhile, after new disk recovery success, sda
      will be set to Faulty.
      
      Prioritize adding disk to 'removed' mirror is a better choice. In the
      above scenario, the behavior is the same as before, except sda will not
      be deleted. Before other disks are added, continued use sda is more
      reliable.
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NYu Kuai <yukuai3@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit 2e2e7ab6)
      106e6562
    • L
      md: fix io loss when remove rdev fail · a27028e5
      Li Nan 提交于
      hulk inclusion
      category: bugfix, https://gitee.com/openeuler/kernel/issues/I71EKW
      bugzilla: 188628
      CVE: NA
      
      --------------------------------
      
      We first set rdev to WantRemove, and check if there is any io
      pending, if so, we will clear flag and return busy in
      raid10_remove_disk(). io will loss as below:
      
        raid10_remove_disk
         set WantRemove
      			write rdev
      			 if WantRemove
      			  do not submit io
         if rdev->nr_pending
          clear WantRemove
          return BUSY
      					read rdev
      					 get error data
      
      Fix it by md_error the rdev which io pending while removing. When the code
      reaches this point, it means this rdev will be removed later, so setting
      it as faulty has little impact.
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NYu Kuai <yukuai3@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit 894f89fa)
      a27028e5
    • L
      md/raid10: fix a race between removing rdev and access conf->mirrors[i].rdev · b5e9c590
      Li Nan 提交于
      hulk inclusion
      category: bugfix
      bugzilla: 188533, https://gitee.com/openeuler/kernel/issues/I6O7YB
      CVE: NA
      
      --------------------------------
      
      commit ceff49d9 ("md/raid1: fix a race between removing rdev and
      access conf->mirrors[i].rdev") fix a null-ptr-deref about raid1. There
      is same bug in raid10 and fix it in the same way.
      
      There is no sync_thread running while removing rdev, no need to check
      the flag in raid10_sync_request().
      Signed-off-by: NLi Nan <linan122@huawei.com>
      Reviewed-by: NYu Kuai <yukuai3@huawei.com>
      Reviewed-by: NHou Tao <houtao1@huawei.com>
      (cherry picked from commit 4461a62e)
      b5e9c590