April 2019 - Linux-stable-mirror

[PATCH 06/18] bcache: fix a race between cache register and cacheset unregister

by Coly Li

From: Liang Chen <liangchen.linux(a)gmail.com> There is a race between cache device register and cache set unregister. For an already registered cache device, register_bcache will call bch_is_open to iterate through all cachesets and check every cache there. The race occurs if cache_set_free executes at the same time and clears the caches right before ca is dereferenced in bch_is_open_cache. To close the race, let's make sure the clean up work is protected by the bch_register_lock as well. This issue can be reproduced as follows, while true; do echo /dev/XXX> /sys/fs/bcache/register ; done& while true; do echo 1> /sys/block/XXX/bcache/set/unregister ; done & and results in the following oops, [ +0.000053] BUG: unable to handle kernel NULL pointer dereference at 0000000000000998 [ +0.000457] #PF error: [normal kernel read fault] [ +0.000464] PGD 800000003ca9d067 P4D 800000003ca9d067 PUD 3ca9c067 PMD 0 [ +0.000388] Oops: 0000 [#1] SMP PTI [ +0.000269] CPU: 1 PID: 3266 Comm: bash Not tainted 5.0.0+ #6 [ +0.000346] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28 04/01/2014 [ +0.000472] RIP: 0010:register_bcache+0x1829/0x1990 [bcache] [ +0.000344] Code: b0 48 83 e8 50 48 81 fa e0 e1 10 c0 0f 84 a9 00 00 00 48 89 c6 48 89 ca 0f b7 ba 54 04 00 00 4c 8b 82 60 0c 00 00 85 ff 74 2f <49> 3b a8 98 09 00 00 74 4e 44 8d 47 ff 31 ff 49 c1 e0 03 eb 0d [ +0.000839] RSP: 0018:ffff92ee804cbd88 EFLAGS: 00010202 [ +0.000328] RAX: ffffffffc010e190 RBX: ffff918b5c6b5000 RCX: ffff918b7d8e0000 [ +0.000399] RDX: ffff918b7d8e0000 RSI: ffffffffc010e190 RDI: 0000000000000001 [ +0.000398] RBP: ffff918b7d318340 R08: 0000000000000000 R09: ffffffffb9bd2d7a [ +0.000385] R10: ffff918b7eb253c0 R11: ffffb95980f51200 R12: ffffffffc010e1a0 [ +0.000411] R13: fffffffffffffff2 R14: 000000000000000b R15: ffff918b7e232620 [ +0.000384] FS: 00007f955bec2740(0000) GS:ffff918b7eb00000(0000) knlGS:0000000000000000 [ +0.000420] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000801] CR2: 0000000000000998 CR3: 000000003cad6000 CR4: 00000000001406e0 [ +0.000837] Call Trace: [ +0.000682] ? _cond_resched+0x10/0x20 [ +0.000691] ? __kmalloc+0x131/0x1b0 [ +0.000710] kernfs_fop_write+0xfa/0x170 [ +0.000733] __vfs_write+0x2e/0x190 [ +0.000688] ? inode_security+0x10/0x30 [ +0.000698] ? selinux_file_permission+0xd2/0x120 [ +0.000752] ? security_file_permission+0x2b/0x100 [ +0.000753] vfs_write+0xa8/0x1a0 [ +0.000676] ksys_write+0x4d/0xb0 [ +0.000699] do_syscall_64+0x3a/0xf0 [ +0.000692] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Liang Chen <liangchen.linux(a)gmail.com> Cc: stable(a)vger.kernel.org Signed-off-by: Coly Li <colyli(a)suse.de> --- drivers/md/bcache/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c index 6e618cb6126c..53c5e3e0ac22 100644 --- a/drivers/md/bcache/super.c +++ b/drivers/md/bcache/super.c @@ -1514,6 +1514,7 @@ static void cache_set_free(struct closure *cl) bch_btree_cache_free(c); bch_journal_free(c); + mutex_lock(&bch_register_lock); for_each_cache(ca, c, i) if (ca) { ca->set = NULL; @@ -1532,7 +1533,6 @@ static void cache_set_free(struct closure *cl) mempool_exit(&c->search); kfree(c->devices); - mutex_lock(&bch_register_lock); list_del(&c->list); mutex_unlock(&bch_register_lock); -- 2.16.4

5 years, 5 months

1
0
0 0

[RESEND PATCH stable only] nvmet: set loop queue's segment boundary mask as PAGE_SIZE - 1

by Ming Lei

NVMe target only accepts single-page sg list, either file or block device backed target code follows this assumption. However, loop target is one exception, given the sg list is from the host queue directly. This patch sets loop queue's segment boundary mask as PAGE_SIZE - 1 for following NVMe target assumption. Multi-page bvec has been merged to v5.1-rc1, so commit 02db99548d36 ("nvmet: fix building bvec from sg list") can fix the current issue simply without needing to limit the segment size for nvme-loop. Reported-by: Yi Zhang <yi.zhang(a)redhat.com> Fixes: 3a85a5de29ea ("nvme-loop: add a NVMe loopback host driver") Cc: Yi Zhang <yi.zhang(a)redhat.com> Cc: Sagi Grimberg <sagi(a)grimberg.me> Cc: Chaitanya Kulkarni <chaitanya.kulkarni(a)wdc.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> --- drivers/nvme/target/loop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c index b9f623ab01f3..7194f86b9dac 100644 --- a/drivers/nvme/target/loop.c +++ b/drivers/nvme/target/loop.c @@ -549,6 +549,9 @@ static int nvme_loop_create_io_queues(struct nvme_loop_ctrl *ctrl) if (ret) goto out_cleanup_connect_q; + /* target only accepts single-page sg list */ + blk_queue_segment_boundary(ctrl->ctrl.connect_q, PAGE_SIZE - 1); + return 0; out_cleanup_connect_q: -- 2.9.5

5 years, 5 months

2
3
0 0

[STABLE PATCH 0/2] Fix in-memory metadata corruption at xfs_attr3_leaf_write_verify()

by Alex Lyakas

This is a partial backport of original Darrick's series "xfs: logging fixes" to kernel 4.14. It fixes the in-memory metadata corruption error, which happens when a partially initialized attribute buffer is attemped to be written to disk. This issue is reproducible with kernel 4.14, when adding a 1-sec sleep in xfs_attr_set(), between the call to xfs_attr_shortform_to_leaf() and the call to xfs_attr_leaf_addname(). Darrick J. Wong (2): xfs: add the ability to join a held buffer to a defer_ops xfs: hold xfs_buf locked between shortform->leaf conversion and the addition of an attribute fs/xfs/libxfs/xfs_attr.c | 20 +++++++++++++++----- fs/xfs/libxfs/xfs_attr_leaf.c | 9 ++++++--- fs/xfs/libxfs/xfs_attr_leaf.h | 3 ++- fs/xfs/libxfs/xfs_defer.c | 39 ++++++++++++++++++++++++++++++++++++--- fs/xfs/libxfs/xfs_defer.h | 5 ++++- 5 files changed, 63 insertions(+), 13 deletions(-) -- 1.9.1

5 years, 5 months

3
6
0 0

[PATCH 4.4 0/5] DHCP client support when receiving "delayed" replies

by Patryk Mungai

Dear All, When running dhcp tests using the 4.4.y (and 4.4.y-cip kernel as well), I encountered an issue where the dhcp client in the kernel could not get an IP address when multiple network devices were enabled. It seems that the current implementation of the dhcp client in the 4.4 kernel is send dhcp request via device 1 -> wait <1s for response from server on device 1 -> if no response, switch to device 2 -> repeat process on device 2 ...etc. When the dhcp server is slow to respond, this means it is impossible to get a dhcp address. This series backported from upstream fixes the issue, is it possible to apply this to 4.4.y and/or 4.4.y-cip? Thanks, Patryk Geert Uytterhoeven (1): net: ipconfig: Fix NULL pointer dereference on RARP/BOOTP/DHCP timeout Thierry Reding (1): net: ipconfig: Fix more use after free Uwe Kleine-König (3): net: ipconfig: Support using "delayed" DHCP replies net: ipconfig: drop inter-device timeout net: ipconfig: fix use after free net/ipv4/ipconfig.c | 61 ++++++++++++++++++++++++----------------------------- 1 file changed, 28 insertions(+), 33 deletions(-) -- 2.7.4

5 years, 5 months

5
9
0 0

5a9d929d6e13 ("iomap: report collisions between directio and buffered writes to userspace")

by Zubin Mithra

Hello, Syzkaller has triggered a kernel WARNING with the following stacktrace when fuzzing a 4.14 kernel. Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0xb7/0x107 lib/dump_stack.c:53 panic+0x1c9/0x3ae kernel/panic.c:181 __warn+0x160/0x1a8 kernel/panic.c:543 report_bug+0x123/0x18b lib/bug.c:186 fixup_bug+0x3e/0x77 arch/x86/kernel/traps.c:177 do_error_trap+0xdd/0x1e6 arch/x86/kernel/traps.c:295 invalid_op+0x1b/0x40 arch/x86/entry/entry_64.S:944 do_blockdev_direct_IO+0x1b08/0x1b95 fs/direct-io.c:1373 ext4_direct_IO_write fs/ext4/inode.c:3696 [inline] ext4_direct_IO+0x8de/0xdad fs/ext4/inode.c:3826 generic_file_direct_write+0x223/0x36b mm/filemap.c:2927 __generic_file_write_iter+0x12f/0x2f8 mm/filemap.c:3106 ext4_file_write_iter+0x97d/0xade fs/ext4/file.c:264 call_write_iter include/linux/fs.h:1782 [inline] do_iter_readv_writev+0x1e4/0x27c fs/read_write.c:678 do_iter_write+0x136/0x18f fs/read_write.c:957 vfs_iter_write+0x81/0x98 fs/read_write.c:970 iter_file_splice_write+0x4dc/0x7a6 fs/splice.c:749 do_splice_from fs/splice.c:851 [inline] direct_splice_actor+0x11e/0x129 fs/splice.c:1018 splice_direct_to_actor+0x342/0x5b0 fs/splice.c:973 do_splice_direct+0x180/0x1ff fs/splice.c:1061 do_sendfile+0x3e6/0x61c fs/read_write.c:1438 SYSC_sendfile64 fs/read_write.c:1499 [inline] SyS_sendfile64+0xe9/0x128 fs/read_write.c:1485 do_syscall_64+0x203/0x241 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x42/0xb7 Could the following patch be applied in order to v4.14.y(The patch is present in v4.19.y)? 5a9d929d6e13 ("iomap: report collisions between directio and buffered writes to userspace") Tests run: - Chrome OS tryjobs - Syzkaller reproducer Thanks, - Zubin

5 years, 5 months

4
3
0 0

[PATCH AUTOSEL 4.19 01/52] arm64: dts: rockchip: fix rk3328-roc-cc gmac2io tx/rx_delay

by Sasha Levin

From: "Leonidas P. Papadakos" <papadakospan(a)gmail.com> [ Upstream commit 924726888f660b2a86382a5dd051ec9ca1b18190 ] The rk3328-roc-cc board exhibits tx stability issues with large packets, as does the rock64 board, which was fixed with this patch https://patchwork.kernel.org/patch/10178969/ A similar patch was merged for the rk3328-roc-cc here https://patchwork.kernel.org/patch/10804863/ but it doesn't include the tx/rx_delay tweaks, and I find that they help with an issue where large transfers would bring the ethernet link down, causing a link reset regularly. Signed-off-by: Leonidas P. Papadakos <papadakospan(a)gmail.com> Signed-off-by: Heiko Stuebner <heiko(a)sntech.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts index 246c317f6a68..91061d9cf78b 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts +++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts @@ -94,8 +94,8 @@ snps,reset-gpio = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>; snps,reset-active-low; snps,reset-delays-us = <0 10000 50000>; - tx_delay = <0x25>; - rx_delay = <0x11>; + tx_delay = <0x24>; + rx_delay = <0x18>; status = "okay"; }; -- 2.19.1

5 years, 5 months

2
52
0 0

[PATCH V7 3/9] blk-mq: free hw queue's resource in hctx's release handler

by Ming Lei

Once blk_cleanup_queue() returns, tags shouldn't be used any more, because blk_mq_free_tag_set() may be called. Commit 45a9c9d909b2 ("blk-mq: Fix a use-after-free") fixes this issue exactly. However, that commit introduces another issue. Before 45a9c9d909b2, we are allowed to run queue during cleaning up queue if the queue's kobj refcount is held. After that commit, queue can't be run during queue cleaning up, otherwise oops can be triggered easily because some fields of hctx are freed by blk_mq_free_queue() in blk_cleanup_queue(). We have invented ways for addressing this kind of issue before, such as: 8dc765d438f1 ("SCSI: fix queue cleanup race before queue initialization is done") c2856ae2f315 ("blk-mq: quiesce queue before freeing queue") But still can't cover all cases, recently James reports another such kind of issue: https://marc.info/?l=linux-scsi&m=155389088124782&w=2 This issue can be quite hard to address by previous way, given scsi_run_queue() may run requeues for other LUNs. Fixes the above issue by freeing hctx's resources in its release handler, and this way is safe becasue tags isn't needed for freeing such hctx resource. This approach follows typical design pattern wrt. kobject's release handler. Cc: Dongli Zhang <dongli.zhang(a)oracle.com> Cc: James Smart <james.smart(a)broadcom.com> Cc: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: linux-scsi(a)vger.kernel.org, Cc: Martin K . Petersen <martin.petersen(a)oracle.com>, Cc: Christoph Hellwig <hch(a)lst.de>, Cc: James E . J . Bottomley <jejb(a)linux.vnet.ibm.com>, Reported-by: James Smart <james.smart(a)broadcom.com> Fixes: 45a9c9d909b2 ("blk-mq: Fix a use-after-free") Cc: stable(a)vger.kernel.org Reviewed-by: Hannes Reinecke <hare(a)suse.com> Tested-by: James Smart <james.smart(a)broadcom.com> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> --- block/blk-core.c | 2 +- block/blk-mq-sysfs.c | 6 ++++++ block/blk-mq.c | 8 ++------ block/blk-mq.h | 2 +- 4 files changed, 10 insertions(+), 8 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index 93dc588fabe2..2dd94b3e9ece 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -374,7 +374,7 @@ void blk_cleanup_queue(struct request_queue *q) blk_exit_queue(q); if (queue_is_mq(q)) - blk_mq_free_queue(q); + blk_mq_exit_queue(q); percpu_ref_exit(&q->q_usage_counter); diff --git a/block/blk-mq-sysfs.c b/block/blk-mq-sysfs.c index 3f9c3f4ac44c..4040e62c3737 100644 --- a/block/blk-mq-sysfs.c +++ b/block/blk-mq-sysfs.c @@ -10,6 +10,7 @@ #include <linux/smp.h> #include <linux/blk-mq.h> +#include "blk.h" #include "blk-mq.h" #include "blk-mq-tag.h" @@ -33,6 +34,11 @@ static void blk_mq_hw_sysfs_release(struct kobject *kobj) { struct blk_mq_hw_ctx *hctx = container_of(kobj, struct blk_mq_hw_ctx, kobj); + + if (hctx->flags & BLK_MQ_F_BLOCKING) + cleanup_srcu_struct(hctx->srcu); + blk_free_flush_queue(hctx->fq); + sbitmap_free(&hctx->ctx_map); free_cpumask_var(hctx->cpumask); kfree(hctx->ctxs); kfree(hctx); diff --git a/block/blk-mq.c b/block/blk-mq.c index 3e321048b259..862eb41f24f8 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2273,12 +2273,7 @@ static void blk_mq_exit_hctx(struct request_queue *q, if (set->ops->exit_hctx) set->ops->exit_hctx(hctx, hctx_idx); - if (hctx->flags & BLK_MQ_F_BLOCKING) - cleanup_srcu_struct(hctx->srcu); - blk_mq_remove_cpuhp(hctx); - blk_free_flush_queue(hctx->fq); - sbitmap_free(&hctx->ctx_map); } static void blk_mq_exit_hw_queues(struct request_queue *q, @@ -2913,7 +2908,8 @@ struct request_queue *blk_mq_init_allocated_queue(struct blk_mq_tag_set *set, } EXPORT_SYMBOL(blk_mq_init_allocated_queue); -void blk_mq_free_queue(struct request_queue *q) +/* tags can _not_ be used after returning from blk_mq_exit_queue */ +void blk_mq_exit_queue(struct request_queue *q) { struct blk_mq_tag_set *set = q->tag_set; diff --git a/block/blk-mq.h b/block/blk-mq.h index 423ea88ab6fb..633a5a77ee8b 100644 --- a/block/blk-mq.h +++ b/block/blk-mq.h @@ -37,7 +37,7 @@ struct blk_mq_ctx { struct kobject kobj; } ____cacheline_aligned_in_smp; -void blk_mq_free_queue(struct request_queue *q); +void blk_mq_exit_queue(struct request_queue *q); int blk_mq_update_nr_requests(struct request_queue *q, unsigned int nr); void blk_mq_wake_waiters(struct request_queue *q); bool blk_mq_dispatch_rq_list(struct request_queue *, struct list_head *, bool); -- 2.9.5

5 years, 5 months

2
1
0 0

Re: Re: [PATCH v4] signal: trace_signal_deliver when signal_group_exit

by weizhenliang

On 04/24, Oleg wrote: >On 04/24, Christian Brauner wrote: >> >> On Wed, Apr 24, 2019 at 08:52:38PM +0800, Zhenliang Wei wrote: >> >> > Reviewed-by: Oleg Nesterov <oleg(a)redhat.com> > >Yes, but ... > >> > Reported-by: kbuild test robot <lkp(a)intel.com> > >Hmm, really? Yes, the kbuild test robot says that if I fix the problem with the third parameter type, I should add this tag. What is wrong or missing? Wei.

5 years, 5 months

3
2
0 0

[PATCH AUTOSEL 3.18 01/10] HID: debug: fix race condition with between rdesc_show() and device removal

by Sasha Levin

From: "He, Bo" <bo.he(a)intel.com> [ Upstream commit cef0d4948cb0a02db37ebfdc320e127c77ab1637 ] There is a race condition that could happen if hid_debug_rdesc_show() is running while hdev is in the process of going away (device removal, system suspend, etc) which could result in NULL pointer dereference: BUG: unable to handle kernel paging request at 0000000783316040 CPU: 1 PID: 1512 Comm: getevent Tainted: G U O 4.19.20-quilt-2e5dc0ac-00029-gc455a447dd55 #1 RIP: 0010:hid_dump_device+0x9b/0x160 Call Trace: hid_debug_rdesc_show+0x72/0x1d0 seq_read+0xe0/0x410 full_proxy_read+0x5f/0x90 __vfs_read+0x3a/0x170 vfs_read+0xa0/0x150 ksys_read+0x58/0xc0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x55/0x110 entry_SYSCALL_64_after_hwframe+0x49/0xbe Grab driver_input_lock to make sure the input device exists throughout the whole process of dumping the rdesc. [jkosina(a)suse.cz: update changelog a bit] Signed-off-by: "he, bo" <bo.he(a)intel.com> Signed-off-by: "Zhang, Jun" <jun.zhang(a)intel.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hid/hid-debug.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c index e930627d0c76..71b069bd2a24 100644 --- a/drivers/hid/hid-debug.c +++ b/drivers/hid/hid-debug.c @@ -1057,10 +1057,15 @@ static int hid_debug_rdesc_show(struct seq_file *f, void *p) seq_printf(f, "\n\n"); /* dump parsed data and input mappings */ + if (down_interruptible(&hdev->driver_input_lock)) + return 0; + hid_dump_device(hdev, f); seq_printf(f, "\n"); hid_dump_input_mapping(hdev, f); + up(&hdev->driver_input_lock); + return 0; } -- 2.19.1

5 years, 5 months

1
9
0 0

[PATCH AUTOSEL 4.4 01/15] HID: debug: fix race condition with between rdesc_show() and device removal

by Sasha Levin

From: "He, Bo" <bo.he(a)intel.com> [ Upstream commit cef0d4948cb0a02db37ebfdc320e127c77ab1637 ] There is a race condition that could happen if hid_debug_rdesc_show() is running while hdev is in the process of going away (device removal, system suspend, etc) which could result in NULL pointer dereference: BUG: unable to handle kernel paging request at 0000000783316040 CPU: 1 PID: 1512 Comm: getevent Tainted: G U O 4.19.20-quilt-2e5dc0ac-00029-gc455a447dd55 #1 RIP: 0010:hid_dump_device+0x9b/0x160 Call Trace: hid_debug_rdesc_show+0x72/0x1d0 seq_read+0xe0/0x410 full_proxy_read+0x5f/0x90 __vfs_read+0x3a/0x170 vfs_read+0xa0/0x150 ksys_read+0x58/0xc0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x55/0x110 entry_SYSCALL_64_after_hwframe+0x49/0xbe Grab driver_input_lock to make sure the input device exists throughout the whole process of dumping the rdesc. [jkosina(a)suse.cz: update changelog a bit] Signed-off-by: "he, bo" <bo.he(a)intel.com> Signed-off-by: "Zhang, Jun" <jun.zhang(a)intel.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hid/hid-debug.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/hid/hid-debug.c b/drivers/hid/hid-debug.c index d7179dd3c9ef..3cafa1d28fed 100644 --- a/drivers/hid/hid-debug.c +++ b/drivers/hid/hid-debug.c @@ -1058,10 +1058,15 @@ static int hid_debug_rdesc_show(struct seq_file *f, void *p) seq_printf(f, "\n\n"); /* dump parsed data and input mappings */ + if (down_interruptible(&hdev->driver_input_lock)) + return 0; + hid_dump_device(hdev, f); seq_printf(f, "\n"); hid_dump_input_mapping(hdev, f); + up(&hdev->driver_input_lock); + return 0; } -- 2.19.1

5 years, 5 months

1
14
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2019