- 14 Feb, 2023 29 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
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 2 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:
-
