- 14 Feb, 2023 19 commits
-
-
Heinz Mauelshagen authored
Signed-off-by:
Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@kernel.org>
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
Signed-off-by:
-
Heinz Mauelshagen authored
'GPL-2.0-only' is used instead of 'GPL-2.0' because SPDX has deprecated its use. Suggested-by:
John Wiele <jwiele@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
Device mapper sends an uevent when the device is suspended, using the function set_capacity_and_notify. However, this causes a race condition with udev. Udev skips scanning dm devices that are suspended. If we send an uevent while we are suspended, udev will be racing with device mapper resume code. If the device mapper resume code wins the race, udev will process the uevent after the device is resumed and it will properly scan the device. However, if udev wins the race, it will receive the uevent, find out that the dm device is suspended and skip scanning the device. This causes bugs such as systemd unmounting the device - see https://bugzilla.redhat.com/show_bug.cgi?id=2158628 This commit fixes this race. We replace the function set_capacity_and_notify with set_capacity, so that the uevent is not sent at this point. In do_resume, we detect if the capacity has changed and we pass a boolean variable need_resize_uevent to dm_kobject_uevent. dm_kobject_uevent adds "RESIZE=1" to the uevent if need_resize_uevent is set. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Tested-by:
Peter Rajnoha <prajnoha@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
- 12 Feb, 2023 2 commits
-
-
Benjamin Marzinski authored
If a DM device's table references itself, it will crash the kernel with an infinite recursion. Check for a self-reference in dm_get_device(). This is a quick check, but it won't catch more complicated circular references. Signed-off-by:
Benjamin Marzinski <bmarzins@redhat.com> Signed-off-by:
-
Yu Zhe authored
Signed-off-by:
Yu Zhe <yuzhe@nfschina.com> Signed-off-by:
-
- 02 Feb, 2023 5 commits
-
-
Nathan Huckleberry authored
Setting WQ_UNBOUND increases scheduler latency on ARM64. This is likely due to the asymmetric architecture of ARM64 processors. I've been unable to reproduce the results that claim WQ_UNBOUND gives a performance boost on x86-64. This flag is causing performance issues for multiple subsystems within Android. Notably, the same slowdown exists for decompression with EROFS. | open-prebuilt-camera | WQ_UNBOUND | ~WQ_UNBOUND | |-----------------------|------------|---------------| | verity wait time (us) | 11746 | 119 (-98%) | | erofs wait time (us) | 357805 | 174205 (-51%) | | sha256 ramdisk random read | WQ_UNBOUND | ~WQ_UNBOUND | |----------------------------|-----------=---|-------------| | arm64 (accelerated) | bw=42.4MiB/s | bw=212MiB/s | | arm64 (generic) | bw=16.5MiB/s | bw=48MiB/s | | x86_64 (generic) | bw=233MiB/s | bw=230MiB/s | Using a alloc_workqueue() @max_active arg of num_online_cpus() only made sense with WQ_UNBOUND. Switch the @max_active arg to 0 (aka default, which is 256 per-cpu). Also, eliminate 'wq_flags' since it really doesn't serve a purpose. Cc: Sami Tolvanen <samitolvanen@google.com> Cc: Eric Biggers <ebiggers@kernel.org> Signed-off-by:
Nathan Huckleberry <nhuck@google.com> Reviewed-by:
-
Jiapeng Chong authored
drivers/md/dm-integrity.c:1738:13: warning: variable 'bi_sector' set but not used. Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3895Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by:
-
Christophe JAILLET authored
Use strchr() instead of strpbrk() when there is only 1 element in the set of characters to look for. This potentially saves a few cycles, but gcc does already account for optimizing this pattern thanks to it's fold_builtin_strpbrk(). Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Sergey Shtylyov authored
The expression 'indata[3] > ULONG_MAX' always evaluates to false since indata[] is declared as an array of *unsigned long* elements and #define ULONG_MAX represents the max value of that exact type... Note that gcc seems to be able to detect the dead code here and eliminate this check anyway... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Signed-off-by:
Sergey Shtylyov <s.shtylyov@omp.ru> Reviewed-by:
-
Mikulas Patocka authored
If "corrupt_bio_byte" is set to corrupt reads and corrupt_bio_flags is used, dm-flakey would erroneously return all writes as errors. Likewise, if "corrupt_bio_byte" is set to corrupt writes, dm-flakey would return errors for all reads. Fix the logic so that if fc->corrupt_bio_byte is non-zero, dm-flakey will not abort reads on writes with an error. Cc: stable@vger.kernel.org Signed-off-by:
Sweet Tea Dorminy <sweettea-kernel@dorminy.me> Signed-off-by:
-
- 01 Feb, 2023 2 commits
-
-
Mikulas Patocka authored
The function page_address does not work with 32-bit systems with high memory. Use bvec_kmap_local/kunmap_local instead. Cc: stable@vger.kernel.org Signed-off-by:
-
Mikulas Patocka authored
When we need to zero some range on a block device, the function __blkdev_issue_zero_pages submits a write bio with the bio vector pointing to the zero page. If we use dm-flakey with corrupt bio writes option, it will corrupt the content of the zero page which results in crashes of various userspace programs. Glibc assumes that memory returned by mmap is zeroed and it uses it for calloc implementation; if the newly mapped memory is not zeroed, calloc will return non-zeroed memory. Fix this bug by testing if the page is equal to ZERO_PAGE(0) and avoiding the corruption in this case. Cc: stable@vger.kernel.org Fixes: a00f5276 ("dm flakey: Properly corrupt multi-page bios.") Signed-off-by:
-
- 30 Jan, 2023 12 commits
-
-
Joe Thornber authored
Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
-
Joe Thornber authored
Otherwise the kernel can BUG with: [ 2245.426978] ============================================================================= [ 2245.435155] BUG bt_work (Tainted: G B W ): Objects remaining in bt_work on __kmem_cache_shutdown() [ 2245.445233] ----------------------------------------------------------------------------- [ 2245.445233] [ 2245.454879] Slab 0x00000000b0ce2b30 objects=64 used=2 fp=0x000000000a3c6a4e flags=0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff) [ 2245.467300] CPU: 7 PID: 10805 Comm: lvm Kdump: loaded Tainted: G B W 6.0.0-rc2 #19 [ 2245.476078] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.5.6 10/06/2021 [ 2245.483646] Call Trace: [ 2245.486100] <TASK> [ 2245.488206] dump_stack_lvl+0x34/0x48 [ 2245.491878] slab_err+0x95/0xcd [ 2245.495028] __kmem_cache_shutdown.cold+0x31/0x136 [ 2245.499821] kmem_cache_destroy+0x49/0x130 [ 2245.503928] btracker_destroy+0x12/0x20 [dm_cache] [ 2245.508728] smq_destroy+0x15/0x60 [dm_cache_smq] [ 2245.513435] dm_cache_policy_destroy+0x12/0x20 [dm_cache] [ 2245.518834] destroy+0xc0/0x110 [dm_cache] [ 2245.522933] dm_table_destroy+0x5c/0x120 [dm_mod] [ 2245.527649] __dm_destroy+0x10e/0x1c0 [dm_mod] [ 2245.532102] dev_remove+0x117/0x190 [dm_mod] [ 2245.536384] ctl_ioctl+0x1a2/0x290 [dm_mod] [ 2245.540579] dm_ctl_ioctl+0xa/0x20 [dm_mod] [ 2245.544773] __x64_sys_ioctl+0x8a/0xc0 [ 2245.548524] do_syscall_64+0x5c/0x90 [ 2245.552104] ? syscall_exit_to_user_mode+0x12/0x30 [ 2245.556897] ? do_syscall_64+0x69/0x90 [ 2245.560648] ? do_syscall_64+0x69/0x90 [ 2245.564394] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 2245.569447] RIP: 0033:0x7fe52583ec6b ... [ 2245.646771] ------------[ cut here ]------------ [ 2245.651395] kmem_cache_destroy bt_work: Slab cache still has objects when called from btracker_destroy+0x12/0x20 [dm_cache] [ 2245.651408] WARNING: CPU: 7 PID: 10805 at mm/slab_common.c:478 kmem_cache_destroy+0x128/0x130 Found using: lvm2-testsuite --only "cache-single-split.sh" Ben bisected and found that commit 0495e337 ("mm/slab_common: Deleting kobject in kmem_cache_destroy() without holding slab_mutex/cpu_hotplug_lock") first exposed dm-cache's incomplete cleanup of its background tracker work objects. Reported-by:
-
Mike Snitzer authored
Commit e33c267a ("mm: shrinkers: provide shrinkers with names") chose some fairly bad names for DM's shrinkers. Fixes: e33c267a ("mm: shrinkers: provide shrinkers with names") Signed-off-by : Mike Snitzer <snitzer@kernel.org>
-
Ulf Hansson authored
Assuming that both Kconfig options, BLK_CGROUP and IOSCHED_BFQ are set, we most likely want cgroup support for BFQ too (BFQ_GROUP_IOSCHED), so let's make it default y. Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20230130121240.159456-1-ulf.hansson@linaro.orgSigned-off-by:
Jens Axboe <axboe@kernel.dk>
-
Kemeng Shi authored
bfqd->bfq_wr_max_time is set to 0 in bfq_init_queue and is never changed. It is only used in bfq_wr_duration when bfq_wr_max_time > 0 which never meets, so bfqd->bfq_wr_max_time is not used actually. Just remove it. Signed-off-by:
Kemeng Shi <shikemeng@huaweicloud.com> Reviewed-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230116095153.3810101-9-shikemeng@huaweicloud.comSigned-off-by:
-
Kemeng Shi authored
We jump to tag only for returning current rq. Return directly to remove this tag. Reviewed-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by:
-
Kemeng Shi authored
We have already avoided a circular list in bfq_setup_merge (see comments in bfq_setup_merge() for details), so bfq_queue will not appear in it's new_bfqq list. Just remove this check. Signed-off-by:
-
Kemeng Shi authored
The async_bfqq is assigned with bfqq->bic->bfqq[0], use it directly. Signed-off-by:
-
Kemeng Shi authored
Use helper macro RQ_BFQQ to get bfqq of request. Signed-off-by:
-
Kemeng Shi authored
Inject limit is updated or reset when time_is_before_eq_jiffies( decrease_time_jif + several msecs) or think-time state changes. decrease_time_jif is initialized to 0 and will be set to current jiffies when inject limit is updated or reset. If the jiffies is slightly greater than LONG_MAX, time_is_after_eq_jiffies(0) will keep for a long time, so as time_is_after_eq_jiffies(decrease_time_jif + several msecs). If the think-time state never chages, then the injection will not work as expected for long time. To be more specific: Function bfq_update_inject_limit maybe triggered when jiffies pasts decrease_time_jif + msecs_to_jiffies(10) in bfq_add_request by setting bfqd->wait_dispatch to true. Function bfq_reset_inject_limit are called in two conditions: 1. jiffies pasts bfqq->decrease_time_jif + msecs_to_jiffies(1000) in function bfq_add_request. 2. jiffies pasts bfqq->decrease_time_jif + msecs_to_jiffies(100) or bfq think-time state change from short to long. Fix this by initializing bfqq->decrease_time_jif to current jiffies to trigger service injection soon when service injection conditions are met. Signed-off-by:
-
Kemeng Shi authored
Parameter reason is never used, just remove it. Signed-off-by:
-
Kemeng Shi authored
Function bfq_choose_bfqq_for_injection may temporarily raise inject limit to one request if current inject_limit is 0 before search of the source queue for injection. However the search below will reset inject limit to bfqd->in_service_queue which is zero for raised inject limit. Then the temporarily raised inject limit never works as expected. Assigment limit to bfqd->in_service_queue in search is needed as limit maybe overwriten to min_t(unsigned int, 1, limit) for condition that a large in-flight request is on non-rotational devices in found queue. So we need to reset limit to bfqd->in_service_queue for normal case. Actually, we have already make sure bfqd->rq_in_driver is < limit before search, then -Limit is >= 1 as bfqd->rq_in_driver is >= 0. Then min_t(unsigned int, 1, limit) is always 1. So we can simply check bfqd->rq_in_driver with 1 instead of result of min_t(unsigned int, 1, limit) for larget request in non-rotational device case to avoid overwritting limit and the bug is gone. -For normal case, we have already check bfqd->rq_in_driver is < limit, so we can return found bfqq unconditionally to remove unncessary check. Signed-off-by:
-
