Skip to content
Snippets Groups Projects
  1. Apr 01, 2021
  2. Mar 29, 2021
  3. Mar 22, 2021
    • 张明's avatar
      arm64/mpam: fix a memleak in add_schema · bbcaf68e
      张明 authored
      openEuler inclusion
      category: bugfix
      bugzilla: https://gitee.com/openeuler/kernel/issues/I3BPPX
      
      
      CVE: NA
      
      -----------------------------------------------------------
      The default branch in switch will not run at present, but there may
      be related extensions in the future, which may lead to memory leakage.
      
      Signed-off-by: default avatarZhang Ming <154842638@qq.com>
      Reported-by: default avatarWang ShaoBo <bobo.shaobowang@huawei.com>
      Suggested-by: default avatarJian Cheng <cj.chengjian@huawei.com>
      Reviewed-by: default avatarXie XiuQi <xiexiuqi@huawei.com>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarCheng Jian <cj.chengjian@huawei.com>
    • Jason Yan's avatar
      scsi: check the whole result for reading write protect flag · e9e58048
      Jason Yan authored
      hulk inclusion
      category: bugfix
      bugzilla: NA
      CVE: NA
      
      -----------------------------------------------
      
      When the scsi device status is offline, mode sense command will return a
      result with only DID_NO_CONNECT set. Then in sd_read_write_protect_flag(),
      only status byte of the result is checked, we still consider the command
      returned good, and read sdkp->write_prot from the buffer. And because of
      bug [1], garbage data is copied to the buffer, the disk sometimes
      be set readonly. When the scsi device is set running again, users cannot
      write data to the disk.
      
      Fix this by check the whole result returned by the driver.
      
      [1] https://patchwork.kernel.org/project/linux-block/patch/20210318122621.330010-1-yanaijie@huawei.com/
      
      
      
      Signed-off-by: default avatarJason Yan <yanaijie@huawei.com>
      Reviewed-by: default avatarYufen Yu <yuyufen@huawei.com>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarCheng Jian <cj.chengjian@huawei.com>
      e9e58048
    • Ye Bin's avatar
      ext4: Fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed · 309801d6
      Ye Bin authored
      
      hulk inclusion
      category: bugfix
      bugzilla: 50785
      CVE: NA
      
      -----------------------------------------------
      
      We got follow bug_on:
      [130747.323114] kernel BUG at fs/ext4/extents_status.c:762!
      [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP
      ......
      [130747.334329] Call trace:
      [130747.334553]  ext4_es_cache_extent+0x150/0x168 [ext4]
      [130747.334975]  ext4_cache_extents+0x64/0xe8 [ext4]
      [130747.335368]  ext4_find_extent+0x300/0x330 [ext4]
      [130747.335759]  ext4_ext_map_blocks+0x74/0x1178 [ext4]
      [130747.336179]  ext4_map_blocks+0x2f4/0x5f0 [ext4]
      [130747.336567]  ext4_mpage_readpages+0x4a8/0x7a8 [ext4]
      [130747.336995]  ext4_readpage+0x54/0x100 [ext4]
      [130747.337359]  generic_file_buffered_read+0x410/0xae8
      [130747.337767]  generic_file_read_iter+0x114/0x190
      [130747.338152]  ext4_file_read_iter+0x5c/0x140 [ext4]
      [130747.338556]  __vfs_read+0x11c/0x188
      [130747.338851]  vfs_read+0x94/0x150
      [130747.339110]  ksys_read+0x74/0xf0
      
      If call ext4_ext_insert_extent failed but new extent already inserted, we just
      update "ex->ee_len = orig_ex.ee_len", this will lead to extent overlap, then
      cause bug on when cache extent.
      
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Reviewed-by: default avatarzhangyi (F) <yi.zhang@huawei.com>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarCheng Jian <cj.chengjian@huawei.com>
      309801d6
    • Guoqing Jiang's avatar
      md: add checkings before flush md_misc_wq · 3f8de0dd
      Guoqing Jiang authored
      mainline inclusion
      from mainline-5.8-rc1
      commit 21e0958e
      category: bugfix
      bugzilla: 35792
      CVE: NA
      
      ---------------------------
      
      Coly reported possible circular locking dependencyi with LOCKDEP enabled,
      quote the below info from the detailed report [1].
      
      [ 1607.673903] Chain exists of:
      [ 1607.673903]   kn->count#256 --> (wq_completion)md_misc -->
      (work_completion)(&rdev->del_work)
      [ 1607.673903]
      [ 1607.827946]  Possible unsafe locking scenario:
      [ 1607.827946]
      [ 1607.898780]        CPU0                    CPU1
      [ 1607.952980]        ----                    ----
      [ 1608.007173]   lock((work_completion)(&rdev->del_work));
      [ 1608.069690]                                lock((wq_completion)md_misc);
      [ 1608.149887]                                lock((work_completion)(&rdev->del_work));
      [ 1608.242563]   lock(kn->count#256);
      [ 1608.283238]
      [ 1608.283238]  *** DEADLOCK ***
      [ 1608.283238]
      [ 1608.354078] 2 locks held by kworker/5:0/843:
      [ 1608.405152]  #0: ffff8889eecc9948 ((wq_completion)md_misc){+.+.}, at:
      process_one_work+0x42b/0xb30
      [ 1608.512399]  #1: ffff888a1d3b7e10
      ((work_completion)(&rdev->del_work)){+.+.}, at: process_one_work+0x42b/0xb30
      [ 1608.632130]
      
      Since works (rdev->del_work and mddev->del_work) are queued in md_misc_wq,
      then lockdep_map lock is held if either of them are running, then both of
      them try to hold kernfs lock by call kobject_del. Then if new_dev_store
      or array_state_store are triggered by write to the related sysfs node, so
      the write operation gets kernfs lock, but need the lockdep_map because all
      of them would trigger flush_workqueue(md_misc_wq) finally, then the same
      lockdep_map lock is needed.
      
      To suppress the lockdep warnning, we should flush the workqueue in case the
      related work is pending. And several works are attached to md_misc_wq, so
      we need to check which work should be checked:
      
      1. for __md_stop_writes, the purpose of call flush workqueue is ensure sync
      thread is started if it was starting, so check mddev->del_work is pending
      or not since md_start_sync is attached to mddev->del_work.
      
      2. __md_stop flushes md_misc_wq to ensure event_work is done, check the
      event_work is enough. Assume raid_{ctr,dtr} -> md_stop -> __md_stop doesn't
      need the kernfs lock.
      
      3. both new_dev_store (holds kernfs lock) and ADD_NEW_DISK ioctl (holds the
      bdev->bd_mutex) call flush_workqueue to ensure md_delayed_delete has
      completed, this case will be handled in next patch.
      
      4. md_open flushes workqueue to ensure the previous md is disappeared, but
      it holds bdev->bd_mutex then try to flush workqueue, so it is better to
      check mddev->del_work as well to avoid potential lock issue, this will be
      done in another patch.
      
      [1]: https://marc.info/?l=linux-raid&m=158518958031584&w=2
      
      
      
      Cc: Coly Li <colyli@suse.de>
      Reported-by: default avatarColy Li <colyli@suse.de>
      Signed-off-by: default avatarGuoqing Jiang <guoqing.jiang@cloud.ionos.com>
      Signed-off-by: default avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: default avatarZhihao Cheng <chengzhihao1@huawei.com>
      Reviewed-by: default avatarJason Yan <yanaijie@huawei.com>
      Signed-off-by: default avatarYang Yingliang <yangyingliang@huawei.com>
      Signed-off-by: default avatarCheng Jian <cj.chengjian@huawei.com>
      3f8de0dd