aboutsummaryrefslogtreecommitdiff
path: root/drivers/md
AgeCommit message (Collapse)AuthorFilesLines
2023-10-10md: use new apis to suspend array for ioctls involed array reconfigurationYu Kuai1-10/+20
'reconfig_mutex' will be grabbed before these ioctls, suspend array before holding the lock, so that io won't concurrent with array reconfiguration through ioctls. This is not hot path, so performance is not concerned. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10md: use new apis to suspend array for adding/removing rdev from state_store()Yu Kuai1-8/+11
User can write 'remove' and 're-add' to trigger array reconfiguration through sysfs, suspend array in this case so that io won't concurrent with array reconfiguration. And now that all the caller of add_bound_rdev() alread suspend the array, remove mddev_suspend/resume() from add_bound_rdev() as well. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10md: use new apis to suspend array for sysfs apisYu Kuai1-16/+8
Convert to use new apis in following sysfs apis: - level_store - suspend_lo_store - suspend_hi_store - serialize_policy_store These are not hot path, so performance is not concerned. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10md/raid5: use new apis to suspend arrayYu Kuai1-26/+12
Convert to use new apis, the old apis will be removed eventually. These are not hot path, so performance is not concerned. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10md/raid5-cache: use new apis to suspend arrayYu Kuai1-11/+8
Convert to use new apis, the old apis will be removed eventually. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10md/md-bitmap: use new apis to suspend array for location_store()Yu Kuai1-4/+2
Convert to use new apis, the old apis will be removed eventually. This is not hot path, so performance is not concerned. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10md/dm-raid: use new apis to suspend arrayYu Kuai1-8/+4
Convert to use new apis, the old apis will be removed eventually. These are not hot path, so performance is not concerned. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10md: add new helpers to suspend/resume and lock/unlock arrayYu Kuai1-0/+27
The new helpers suspend the array first and then lock the array, Prepare to refactor from: mddev_lock/lock_nointr mddev_suspend ... mddev_resuem mddev_lock With: mddev_suspend_and_lock/lock_nointr ... mddev_unlock_and_resume After all the use cases is refactored, mddev_suspend/resume() will be removed. And mddev_suspend_and_lock() will also replace mddev_lock() for the case that the array will be reconfigured, in order to synchronize with io to prevent problems in many corner cases. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10md: add new helpers to suspend/resume arrayYu Kuai2-2/+103
Advantages for new apis: - reconfig_mutex is not required; - the weird logical that suspend array hold 'reconfig_mutex' for mddev_check_recovery() to update superblock is not needed; - the specail handling, 'pers->prepare_suspend', for raid456 is not needed; - It's safe to be called at any time once mddev is allocated, and it's designed to be used from slow path where array configuration is changed; - the new helpers is designed to be called before mddev_lock(), hence it support to be interrupted by user as well. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10md: replace is_md_suspended() with 'mddev->suspended' in md_check_recovery()Yu Kuai1-1/+1
Prepare to cleanup pers->prepare_suspend(), which is used to fix a deadlock in raid456 by returning error for io that is waiting for reshape to make progress in mddev_suspend(). This change will allow reshape to make progress while waiting for io to be done in mddev_suspend() in following patches. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10md/raid5-cache: use READ_ONCE/WRITE_ONCE for 'conf->log'Yu Kuai1-22/+25
'conf->log' is set with 'reconfig_mutex' grabbed, however, readers are not procted, hence protect it with READ_ONCE/WRITE_ONCE to prevent reading abnormal values. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10md: use READ_ONCE/WRITE_ONCE for 'suspend_lo' and 'suspend_hi'Yu Kuai1-7/+9
Protect 'suspend_lo' and 'suspend_hi' with READ_ONCE/WRITE_ONCE to prevent reading abnormal values. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10Merge tag 'v6.6-p4' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "Fix a regression in dm-crypt" * tag 'v6.6-p4' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: dm crypt: Fix reqsize in crypt_iv_eboiv_gen
2023-10-09md/raid1: don't split discard io for write behindYu Kuai1-1/+2
Currently, discad io is treated the same as normal write io, and for write behind case, io size is limited to: BIO_MAX_VECS * (PAGE_SIZE >> 9) For 0.5KB sector size and 4KB PAGE_SIZE, this is just 1MB. For consequence, if 'WriteMostly' is set to one of the underlying disks, then diskcard io will be splited into 1MB and it will take a long time for the diskcard to finish. Fix this problem by disable write behind for discard io. Reported-by: Roman Mamedov <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Reported-and-tested-by: Kirill Kirilenko <[email protected]> Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-07Merge tag 'for-6.6/dm-fixes-2' of ↵Linus Torvalds1-8/+7
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fixes from Mike Snitzer: - Fix memory leak when freeing dm zoned target device - Update dm-devel mailing list address in MAINTAINERS * tag 'for-6.6/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: MAINTAINERS: update the dm-devel mailing list dm zoned: free dmz->ddev array in dmz_put_zoned_devices
2023-10-06dm: shortcut the calls to linear_map and stripe_mapMikulas Patocka4-4/+13
Shortcut the calls to linear_map and stripe_map, so that they don't suffer the overhead of retpolines used for indirect calls. Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2023-10-06Merge tag 'block-6.6-2023-10-06' of git://git.kernel.dk/linuxLinus Torvalds1-0/+7
Pull block fixes from Jens Axboe: "Just two minor fixes, for nbd and md" * tag 'block-6.6-2023-10-06' of git://git.kernel.dk/linux: nbd: don't call blk_mark_disk_dead nbd_clear_sock_ioctl md/raid5: release batch_last before waiting for another stripe_head
2023-10-06dm crypt: Fix reqsize in crypt_iv_eboiv_genHerbert Xu1-1/+2
A skcipher_request object is made up of struct skcipher_request followed by a variable-sized trailer. The allocation of the skcipher_request and IV in crypt_iv_eboiv_gen is missing the memory for struct skcipher_request. Fix it by adding it to reqsize. Fixes: e3023094dffb ("dm crypt: Avoid using MAX_CIPHER_BLOCKSIZE") Cc: <[email protected]> #6.5+ Reported-by: Tatu Heikkilä <[email protected]> Reviewed-by: Mike Snitzer <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2023-10-04mm: shrinker: convert shrinker_rwsem to mutexQi Zheng1-1/+1
Now there are no readers of shrinker_rwsem, so we can simply replace it with mutex lock. [[email protected]: update the fix to alloc_shrinker_info()] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Qi Zheng <[email protected]> Reviewed-by: Muchun Song <[email protected]> Cc: Abhinav Kumar <[email protected]> Cc: Alasdair Kergon <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Alyssa Rosenzweig <[email protected]> Cc: Andreas Dilger <[email protected]> Cc: Andreas Gruenbacher <[email protected]> Cc: Anna Schumaker <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Bob Peterson <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Carlos Llamas <[email protected]> Cc: Chandan Babu R <[email protected]> Cc: Chao Yu <[email protected]> Cc: Chris Mason <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Christian Koenig <[email protected]> Cc: Chuck Lever <[email protected]> Cc: Coly Li <[email protected]> Cc: Dai Ngo <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: "Darrick J. Wong" <[email protected]> Cc: Dave Chinner <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David Airlie <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: David Sterba <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Gao Xiang <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Huang Rui <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jaegeuk Kim <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Jan Kara <[email protected]> Cc: Jason Wang <[email protected]> Cc: Jeff Layton <[email protected]> Cc: Jeffle Xu <[email protected]> Cc: Joel Fernandes (Google) <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Josef Bacik <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Kent Overstreet <[email protected]> Cc: Kirill Tkhai <[email protected]> Cc: Marijn Suijten <[email protected]> Cc: "Michael S. Tsirkin" <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Nadav Amit <[email protected]> Cc: Neil Brown <[email protected]> Cc: Oleksandr Tyshchenko <[email protected]> Cc: Olga Kornievskaia <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Rob Clark <[email protected]> Cc: Rob Herring <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Sean Paul <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: Song Liu <[email protected]> Cc: Stefano Stabellini <[email protected]> Cc: Steven Price <[email protected]> Cc: "Theodore Ts'o" <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Tomeu Vizoso <[email protected]> Cc: Tom Talpey <[email protected]> Cc: Trond Myklebust <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Xuan Zhuo <[email protected]> Cc: Yue Hu <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-10-04bcache: dynamically allocate the md-bcache shrinkerQi Zheng3-13/+19
In preparation for implementing lockless slab shrink, use new APIs to dynamically allocate the md-bcache shrinker, so that it can be freed asynchronously via RCU. Then it doesn't need to wait for RCU read-side critical section when releasing the struct cache_set. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Qi Zheng <[email protected]> Acked-by: Muchun Song <[email protected]> Cc: Coly Li <[email protected]> Cc: Kent Overstreet <[email protected]> Cc: Abhinav Kumar <[email protected]> Cc: Alasdair Kergon <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Alyssa Rosenzweig <[email protected]> Cc: Andreas Dilger <[email protected]> Cc: Andreas Gruenbacher <[email protected]> Cc: Anna Schumaker <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Bob Peterson <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Carlos Llamas <[email protected]> Cc: Chandan Babu R <[email protected]> Cc: Chao Yu <[email protected]> Cc: Chris Mason <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Christian Koenig <[email protected]> Cc: Chuck Lever <[email protected]> Cc: Dai Ngo <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: "Darrick J. Wong" <[email protected]> Cc: Dave Chinner <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David Airlie <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: David Sterba <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Gao Xiang <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Huang Rui <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jaegeuk Kim <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Jan Kara <[email protected]> Cc: Jason Wang <[email protected]> Cc: Jeff Layton <[email protected]> Cc: Jeffle Xu <[email protected]> Cc: Joel Fernandes (Google) <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Josef Bacik <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Kirill Tkhai <[email protected]> Cc: Marijn Suijten <[email protected]> Cc: "Michael S. Tsirkin" <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Nadav Amit <[email protected]> Cc: Neil Brown <[email protected]> Cc: Oleksandr Tyshchenko <[email protected]> Cc: Olga Kornievskaia <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Rob Clark <[email protected]> Cc: Rob Herring <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Sean Paul <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: Song Liu <[email protected]> Cc: Stefano Stabellini <[email protected]> Cc: Steven Price <[email protected]> Cc: "Theodore Ts'o" <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Tomeu Vizoso <[email protected]> Cc: Tom Talpey <[email protected]> Cc: Trond Myklebust <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Xuan Zhuo <[email protected]> Cc: Yue Hu <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-10-04md/raid5: dynamically allocate the md-raid5 shrinkerQi Zheng2-12/+16
In preparation for implementing lockless slab shrink, use new APIs to dynamically allocate the md-raid5 shrinker, so that it can be freed asynchronously via RCU. Then it doesn't need to wait for RCU read-side critical section when releasing the struct r5conf. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Qi Zheng <[email protected]> Reviewed-by: Muchun Song <[email protected]> Reviewed-by: Song Liu <[email protected]> Cc: Abhinav Kumar <[email protected]> Cc: Alasdair Kergon <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Alyssa Rosenzweig <[email protected]> Cc: Andreas Dilger <[email protected]> Cc: Andreas Gruenbacher <[email protected]> Cc: Anna Schumaker <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Bob Peterson <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Carlos Llamas <[email protected]> Cc: Chandan Babu R <[email protected]> Cc: Chao Yu <[email protected]> Cc: Chris Mason <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Christian Koenig <[email protected]> Cc: Chuck Lever <[email protected]> Cc: Coly Li <[email protected]> Cc: Dai Ngo <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: "Darrick J. Wong" <[email protected]> Cc: Dave Chinner <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David Airlie <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: David Sterba <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Gao Xiang <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Huang Rui <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jaegeuk Kim <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Jan Kara <[email protected]> Cc: Jason Wang <[email protected]> Cc: Jeff Layton <[email protected]> Cc: Jeffle Xu <[email protected]> Cc: Joel Fernandes (Google) <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Josef Bacik <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Kent Overstreet <[email protected]> Cc: Kirill Tkhai <[email protected]> Cc: Marijn Suijten <[email protected]> Cc: "Michael S. Tsirkin" <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Muchun Song <[email protected]> Cc: Nadav Amit <[email protected]> Cc: Neil Brown <[email protected]> Cc: Oleksandr Tyshchenko <[email protected]> Cc: Olga Kornievskaia <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Rob Clark <[email protected]> Cc: Rob Herring <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Sean Paul <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: Stefano Stabellini <[email protected]> Cc: Steven Price <[email protected]> Cc: "Theodore Ts'o" <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Tomeu Vizoso <[email protected]> Cc: Tom Talpey <[email protected]> Cc: Trond Myklebust <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Xuan Zhuo <[email protected]> Cc: Yue Hu <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-10-04dm zoned: dynamically allocate the dm-zoned-meta shrinkerQi Zheng1-12/+16
In preparation for implementing lockless slab shrink, use new APIs to dynamically allocate the dm-zoned-meta shrinker, so that it can be freed asynchronously via RCU. Then it doesn't need to wait for RCU read-side critical section when releasing the struct dmz_metadata. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Qi Zheng <[email protected]> Reviewed-by: Muchun Song <[email protected]> Cc: Alasdair Kergon <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: Abhinav Kumar <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Alyssa Rosenzweig <[email protected]> Cc: Andreas Dilger <[email protected]> Cc: Andreas Gruenbacher <[email protected]> Cc: Anna Schumaker <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Bob Peterson <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Carlos Llamas <[email protected]> Cc: Chandan Babu R <[email protected]> Cc: Chao Yu <[email protected]> Cc: Chris Mason <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Christian Koenig <[email protected]> Cc: Chuck Lever <[email protected]> Cc: Coly Li <[email protected]> Cc: Dai Ngo <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: "Darrick J. Wong" <[email protected]> Cc: Dave Chinner <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David Airlie <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: David Sterba <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Gao Xiang <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Huang Rui <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jaegeuk Kim <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Jan Kara <[email protected]> Cc: Jason Wang <[email protected]> Cc: Jeff Layton <[email protected]> Cc: Jeffle Xu <[email protected]> Cc: Joel Fernandes (Google) <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Josef Bacik <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Kent Overstreet <[email protected]> Cc: Kirill Tkhai <[email protected]> Cc: Marijn Suijten <[email protected]> Cc: "Michael S. Tsirkin" <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Muchun Song <[email protected]> Cc: Nadav Amit <[email protected]> Cc: Neil Brown <[email protected]> Cc: Oleksandr Tyshchenko <[email protected]> Cc: Olga Kornievskaia <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Rob Clark <[email protected]> Cc: Rob Herring <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Sean Paul <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: Song Liu <[email protected]> Cc: Stefano Stabellini <[email protected]> Cc: Steven Price <[email protected]> Cc: "Theodore Ts'o" <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Tomeu Vizoso <[email protected]> Cc: Tom Talpey <[email protected]> Cc: Trond Myklebust <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Xuan Zhuo <[email protected]> Cc: Yue Hu <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-10-04dm: dynamically allocate the dm-bufio shrinkerQi Zheng1-11/+17
In preparation for implementing lockless slab shrink, use new APIs to dynamically allocate the dm-bufio shrinker, so that it can be freed asynchronously via RCU. Then it doesn't need to wait for RCU read-side critical section when releasing the struct dm_bufio_client. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Qi Zheng <[email protected]> Reviewed-by: Muchun Song <[email protected]> Cc: Alasdair Kergon <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: Abhinav Kumar <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Alyssa Rosenzweig <[email protected]> Cc: Andreas Dilger <[email protected]> Cc: Andreas Gruenbacher <[email protected]> Cc: Anna Schumaker <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Bob Peterson <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Carlos Llamas <[email protected]> Cc: Chandan Babu R <[email protected]> Cc: Chao Yu <[email protected]> Cc: Chris Mason <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Christian Koenig <[email protected]> Cc: Chuck Lever <[email protected]> Cc: Coly Li <[email protected]> Cc: Dai Ngo <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: "Darrick J. Wong" <[email protected]> Cc: Dave Chinner <[email protected]> Cc: Dave Hansen <[email protected]> Cc: David Airlie <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: David Sterba <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Gao Xiang <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Huang Rui <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jaegeuk Kim <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Jan Kara <[email protected]> Cc: Jason Wang <[email protected]> Cc: Jeff Layton <[email protected]> Cc: Jeffle Xu <[email protected]> Cc: Joel Fernandes (Google) <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Josef Bacik <[email protected]> Cc: Juergen Gross <[email protected]> Cc: Kent Overstreet <[email protected]> Cc: Kirill Tkhai <[email protected]> Cc: Marijn Suijten <[email protected]> Cc: "Michael S. Tsirkin" <[email protected]> Cc: Minchan Kim <[email protected]> Cc: Muchun Song <[email protected]> Cc: Nadav Amit <[email protected]> Cc: Neil Brown <[email protected]> Cc: Oleksandr Tyshchenko <[email protected]> Cc: Olga Kornievskaia <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Richard Weinberger <[email protected]> Cc: Rob Clark <[email protected]> Cc: Rob Herring <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: Sean Paul <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: Song Liu <[email protected]> Cc: Stefano Stabellini <[email protected]> Cc: Steven Price <[email protected]> Cc: "Theodore Ts'o" <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Tomeu Vizoso <[email protected]> Cc: Tom Talpey <[email protected]> Cc: Trond Myklebust <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Xuan Zhuo <[email protected]> Cc: Yue Hu <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-10-03md/raid5: release batch_last before waiting for another stripe_headDavid Jeffery1-0/+7
When raid5_get_active_stripe is called with a ctx containing a stripe_head in its batch_last pointer, it can cause a deadlock if the task sleeps waiting on another stripe_head to become available. The stripe_head held by batch_last can be blocking the advancement of other stripe_heads, leading to no stripe_heads being released so raid5_get_active_stripe waits forever. Like with the quiesce state handling earlier in the function, batch_last needs to be released by raid5_get_active_stripe before it waits for another stripe_head. Fixes: 3312e6c887fe ("md/raid5: Keep a reference to last stripe_head for batch") Cc: [email protected] # v6.0+ Signed-off-by: David Jeffery <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-02dm: Annotate struct dm_bio_prison with __counted_byKees Cook1-1/+1
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct dm_bio_prison. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Alasdair Kergon <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: [email protected] Reviewed-by: "Gustavo A. R. Silva" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]>
2023-10-02dm: Annotate struct dm_stat with __counted_byKees Cook1-1/+1
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct dm_stat. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Alasdair Kergon <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: [email protected] Reviewed-by: "Gustavo A. R. Silva" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]>
2023-10-02dm: Annotate struct stripe_c with __counted_byKees Cook1-1/+1
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct stripe_c. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Alasdair Kergon <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: [email protected] Reviewed-by: "Gustavo A. R. Silva" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]>
2023-10-02dm crypt: Annotate struct crypt_config with __counted_byKees Cook1-1/+1
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct crypt_config. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Alasdair Kergon <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: [email protected] Reviewed-by: "Gustavo A. R. Silva" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]>
2023-10-02dm raid: Annotate struct raid_set with __counted_byKees Cook1-1/+1
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct raid_set. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Alasdair Kergon <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: [email protected] Reviewed-by: "Gustavo A. R. Silva" <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]>
2023-09-28md: do not require mddev_lock() for all options in array_state_store()Mariusz Tkaczyk1-17/+20
We don't need to lock device to reject not supported request in array_state_store(). No functional changes intended. There are differences between ioctl and sysfs handling during stopping. With this change, it will be easier to add additional steps which needs to be completed before mddev_lock() is taken. Reviewed-by: Yu Kuai <[email protected]> Signed-off-by: Mariusz Tkaczyk <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-27md: simplify md_seq_opsYu Kuai1-78/+22
Before this patch, the implementation is hacky and hard to understand: 1) md_seq_start set pos to 1; 2) md_seq_show found pos is 1, then print Personalities; 3) md_seq_next found pos is 1, then it update pos to the first mddev; 4) md_seq_show found pos is not 1 or 2, show mddev; 5) md_seq_next found pos is not 1 or 2, update pos to next mddev; 6) loop 4-5 until the last mddev, then md_seq_next update pos to 2; 7) md_seq_show found pos is 2, then print unused devices; 8) md_seq_next found pos is 2, stop; This patch remove the magic value and use seq_list_start/next/stop() directly, and move printing "Personalities" to md_seq_start(), "unsed devices" to md_seq_stop(): 1) md_seq_start print Personalities, and then set pos to first mddev; 2) md_seq_show show mddev; 3) md_seq_next update pos to next mddev; 4) loop 2-3 until the last mddev; 5) md_seq_stop print unsed devices; Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-27md: factor out a helper from mddev_put()Yu Kuai1-12/+17
There are no functional changes, prepare to simplify md_seq_ops in next patch. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-25md: replace deprecated strncpy with memcpyJustin Stitt1-3/+3
`strncpy` is deprecated for use on NUL-terminated destination strings [1] and as such we should prefer more robust and less ambiguous string interfaces. There are three such strncpy uses that this patch addresses: The respective destination buffers are: 1) mddev->clevel 2) clevel 3) mddev->metadata_type We expect mddev->clevel to be NUL-terminated due to its use with format strings: | ret = sprintf(page, "%s\n", mddev->clevel); Furthermore, we can see that mddev->clevel is not expected to be NUL-padded as `md_clean()` merely set's its first byte to NULL -- not the entire buffer: | static void md_clean(struct mddev *mddev) | { | mddev->array_sectors = 0; | mddev->external_size = 0; | ... | mddev->level = LEVEL_NONE; | mddev->clevel[0] = 0; | ... A suitable replacement for this instance is `memcpy` as we know the number of bytes to copy and perform manual NUL-termination at a specified offset. This really decays to just a byte copy from one buffer to another. `strscpy` is also a considerable replacement but using `slen` as the length argument would result in truncation of the last byte unless something like `slen + 1` was provided which isn't the most idiomatic strscpy usage. For the next case, the destination buffer `clevel` is expected to be NUL-terminated based on its usage within kstrtol() which expects NUL-terminated strings. Note that, in context, this code removes a trailing newline which is seemingly not required as kstrtol() can handle trailing newlines implicitly. However, there exists further usage of clevel (or buf) that would also like to have the newline removed. All in all, with similar reasoning to the first case, let's just use memcpy as this is just a byte copy and NUL-termination is handled manually. The third and final case concerning `mddev->metadata_type` is more or less the same as the other two. We expect that it be NUL-terminated based on its usage with seq_printf: | seq_printf(seq, " super external:%s", | mddev->metadata_type); ... and we can surmise that NUL-padding isn't required either due to how it is handled in md_clean(): | static void md_clean(struct mddev *mddev) | { | ... | mddev->metadata_type[0] = 0; | ... So really, all these instances have precisely calculated lengths and purposeful NUL-termination so we can just use memcpy to remove ambiguity surrounding strncpy. Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] Link: https://github.com/KSPP/linux/issues/90 Cc: [email protected] Signed-off-by: Justin Stitt <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md/md-linear: Annotate struct linear_conf with __counted_byKees Cook2-14/+14
Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct linear_conf. Additionally, since the element count member must be set before accessing the annotated flexible array member, move its initialization earlier. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Song Liu <[email protected]> Cc: [email protected] Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md: don't check 'mddev->pers' and 'pers->quiesce' from suspend_lo_store()Yu Kuai1-7/+2
Now that mddev_suspend() doean't rely on 'mddev->pers' to be set, it's safe to remove such checking. This will also allow the array to be suspended even before the array is ran. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md: don't check 'mddev->pers' from suspend_hi_store()Yu Kuai1-6/+1
Now that mddev_suspend() doean't rely on 'mddev->pers' to be set, it's safe to remove such checking. This will also allow the array to be suspended even before the array is ran. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md-bitmap: suspend array earlier in location_store()Yu Kuai1-23/+20
Now that mddev_suspend() doean't rely on 'mddev->pers' to be set, it's safe to call mddev_suspend() earlier. This will also be helper to refactor mddev_suspend() later. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md-bitmap: remove the checking of 'pers->quiesce' from location_store()Yu Kuai1-4/+0
After commit 4d27e927344a ("md: don't quiesce in mddev_suspend()"), there is no need to check 'pers->quiesce' before calling mddev_suspend(). Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md: don't rely on 'mddev->pers' to be set in mddev_suspend()Yu Kuai1-1/+1
'active_io' used to be initialized while the array is running, and 'mddev->pers' is set while the array is running as well. Hence caller must hold 'reconfig_mutex' and guarantee 'mddev->pers' is set before calling mddev_suspend(). Now that 'active_io' is initialized when mddev is allocated, such restriction doesn't exist anymore. In the meantime, follow up patches will refactor mddev_suspend(), hence add checking for 'mddev->pers' to prevent null-ptr-deref. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md: initialize 'writes_pending' while allocating mddevYu Kuai5-26/+13
Currently 'writes_pending' is initialized in pers->run for raid1/5/10, and it's freed while deleing mddev, instead of pers->free. pers->run can be called multiple times before mddev is deleted, and a helper mddev_init_writes_pending() is used to prevent 'writes_pending' to be initialized multiple times, this usage is safe but a litter weird. On the other hand, 'writes_pending' is only initialized for raid1/5/10, however, it's used in common layer, for example: array_state_store set_in_sync if (!mddev->in_sync) -> in_sync is used for all levels // access writes_pending There might be some implicit dependency that I don't recognized to make sure 'writes_pending' can only be accessed for raid1/5/10, but there are no comments about that. By the way, it make sense to initialize 'writes_pending' in common layer because there are already three levels use it. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md: initialize 'active_io' while allocating mddevYu Kuai3-22/+41
'active_io' is used for mddev_suspend() and it's initialized in md_run(), this restrict that 'reconfig_mutex' must be held and "mddev->pers" must be set before calling mddev_suspend(). Initialize 'active_io' early so that mddev_suspend() is safe to call once mddev is allocated, this will be helpful to refactor mddev_suspend() in following patches. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md: delay remove_and_add_spares() for read only array to md_start_sync()Yu Kuai1-10/+51
Before this patch, for read-only array: md_check_recovery() check that 'MD_RECOVERY_NEEDED' is set, then it will call remove_and_add_spares() directly to try to remove and add rdevs from array. After this patch: 1) md_check_recovery() check that 'MD_RECOVERY_NEEDED' is set, and the worker 'sync_work' is not pending, and there are rdevs can be added or removed, then it will queue new work md_start_sync(); 2) md_start_sync() will call remove_and_add_spares() and exist; This change make sure that array reconfiguration is independent from daemon, and it'll be much easier to synchronize it with io, consier that io may rely on daemon thread to be done. Also fix a problem that 'pers->spars_active' is called after remove_and_add_spares(), which order is wrong, because spares must active first, and then remove_and_add_spares() can add spares to the array, like what read-write case does: 1) daemon set 'MD_RECOVERY_RUNNING', register new sync thread to do recovery; 2) recovery is done, md_do_sync() set 'MD_RECOVERY_DONE' before return; 3) daemon call 'pers->spars_active', and clear 'MD_RECOVERY_RUNNING'; 4) in the next round of daemon, call remove_and_add_spares() to add spares to the array. Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md: factor out a helper rdev_addable() from remove_and_add_spares()Yu Kuai1-12/+27
There are no functional changes, just to make the code simpler and prepare to delay remove_and_add_spares() to md_start_sync(). Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md: factor out a helper rdev_is_spare() from remove_and_add_spares()Yu Kuai1-5/+10
There are no functional changes, just to make the code simpler and prepare to delay remove_and_add_spares() to md_start_sync(). Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Xiao Ni <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md: factor out a helper rdev_removeable() from remove_and_add_spares()Yu Kuai1-6/+38
There are no functional changes, just to make the code simpler and prepare to delay remove_and_add_spares() to md_start_sync(). Signed-off-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md: delay choosing sync action to md_start_sync()Yu Kuai1-34/+39
Before this patch, for read-write array: 1) md_check_recover() found that something need to be done, and it'll try to grab 'reconfig_mutex'. The case that md_check_recover() need to do something: - array is not suspend; - super_block need to be updated; - 'MD_RECOVERY_NEEDED' or 'MD_RECOVERY_DONE' is set; - unusual case related to safemode; 2) if 'MD_RECOVERY_RUNNING' is not set, and 'MD_RECOVERY_NEEDED' is set, md_check_recover() will try to choose a sync action, and then queue a work md_start_sync(). 3) md_start_sync() register sync_thread; After this patch, 1) is the same; 2) if 'MD_RECOVERY_RUNNING' is not set, and 'MD_RECOVERY_NEEDED' is set, queue a work md_start_sync() directly; 3) md_start_sync() will try to choose a sync action, and then register sync_thread(); Because 'MD_RECOVERY_RUNNING' is cleared when sync_thread is done, 2) and 3) and md_do_sync() is always ran in serial and they can never concurrent, this change should not introduce any behavior change for now. Also fix a problem that md_start_sync() can clear 'MD_RECOVERY_RUNNING' without protection in error path, which might affect the logical in md_check_recovery(). The advantage to change this is that array reconfiguration is independent from daemon now, and it'll be much easier to synchronize it with io, consider that io may rely on daemon thread to be done. Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Xiao Ni <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md: factor out a helper to choose sync action from md_check_recovery()Yu Kuai1-25/+45
There are no functional changes, on the one hand make the code cleaner, on the other hand prevent following checkpatch error in the next patch to delay choosing sync action to md_start_sync(). ERROR: do not use assignment in if condition + } else if ((spares = remove_and_add_spares(mddev, NULL))) { Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Xiao Ni <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-22md: use separate work_struct for md_start_sync()Yu Kuai2-5/+10
It's a little weird to borrow 'del_work' for md_start_sync(), declare a new work_struct 'sync_work' for md_start_sync(). Signed-off-by: Yu Kuai <[email protected]> Reviewed-by: Xiao Ni <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-09-20dm zoned: free dmz->ddev array in dmz_put_zoned_devicesFedor Pchelkin1-8/+7
Commit 4dba12881f88 ("dm zoned: support arbitrary number of devices") made the pointers to additional zoned devices to be stored in a dynamically allocated dmz->ddev array. However, this array is not freed. Rename dmz_put_zoned_device to dmz_put_zoned_devices and fix it to free the dmz->ddev array when cleaning up zoned device information. Remove NULL assignment for all dmz->ddev elements and just free the dmz->ddev array instead. Found by Linux Verification Center (linuxtesting.org). Fixes: 4dba12881f88 ("dm zoned: support arbitrary number of devices") Cc: [email protected] Signed-off-by: Fedor Pchelkin <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2023-09-15Merge tag 'for-6.6/dm-fixes' of ↵Linus Torvalds4-30/+33
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm Pull device mapper fixes from Mike Snitzer: - Fix DM core retrieve_deps() UAF race due to missing locking of a DM table's list of devices that is managed using dm_{get,put}_device. - Revert DM core's half-baked RCU optimization if IO submitter has set REQ_NOWAIT. Can be revisited, and properly justified, after comprehensively auditing all of DM to also pass GFP_NOWAIT for any allocations if REQ_NOWAIT used. * tag 'for-6.6/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm: don't attempt to queue IO under RCU protection dm: fix a race condition in retrieve_deps