Re: [PATCH 0/15 v2] loop: Fix oops and possible deadlocks

On 2018/10/10 19:04, Jan Kara wrote: > Hi, > > this patch series fixes oops and possible deadlocks as reported by syzbot [1] > [2]. The second patch in the series (from Tetsuo) fixes the oops, the > remaining > patches are cleaning up the locking in the loop driver so that we can in the > end

Re: [PATCH 4/4] block/loop: Fix circular locking dependency at blkdev_reread_part().

On 2018/09/27 20:27, Jan Kara wrote: > Hi, > > On Wed 26-09-18 00:26:49, Tetsuo Handa wrote: >> syzbot is reporting circular locking dependency between bdev->bd_mutex >> and lo->lo_ctl_mutex [1] which is caused by calling blkdev_reread_part() >> with lock held.

[PATCH 4/4] block/loop: Fix circular locking dependency at blkdev_reread_part().

8ece16bf557dbac427fdff1dad9d6 Signed-off-by: Tetsuo Handa Reported-by: syzbot --- drivers/block/loop.c | 187 --- 1 file changed, 101 insertions(+), 86 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 4b05a27..04389

[PATCH 3/4] block/loop: Reorganize loop_reread_partitions() callers.

p, this patch reorganizes loop_reread_partitions() callers. According to Ming Lei, calling loop_unprepare_queue() before loop_reread_partitions() (like we did until 3.19) is fine. Therefore, this patch will not cause user visible changes. Signed-off-by: Tetsuo Handa Cc: Ming Lei --- drivers/bloc

[PATCH 1/4] block/loop: Don't grab "struct file" for vfs_getattr() operation.

vfs_getattr() needs "struct path" rather than "struct file". Let's use path_get()/path_put() rather than get_file()/fput(). Signed-off-by: Tetsuo Handa Reviewed-by: Jan Kara --- drivers/block/loop.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff -

[PATCH 2/4] block/loop: Use global lock for ioctl() operation.

is caused by calling blkdev_reread_part() with lock held. This patch does not address it. [1] https://syzkaller.appspot.com/bug?id=f3cfe26e785d85f9ee259f385515291d21bd80a3 [2] https://syzkaller.appspot.com/bug?id=bf154052f0eea4bc7712499e4569505907d15889 Signed-off-by: Tetsuo Handa Reported-b

[PATCH] block/loop: Don't hold lock while rereading partition.

itions() in case loop_clr_fd() is called while blkdev_reread_part() from loop_set_fd() is in progress. [1] https://syzkaller.appspot.com/bug?id=bf154052f0eea4bc7712499e4569505907d15889 Signed-off-by: Tetsuo Handa Reported-by: syzbot --- drivers/block/loop.c | 20 ++-- 1 file chang

[PATCH v2] block/loop: Use global lock for ioctl() operation.

) request. Signed-off-by: Tetsuo Handa Reported-by: syzbot --- drivers/block/loop.c | 58 ++-- drivers/block/loop.h | 1 - 2 files changed, 29 insertions(+), 30 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index c2745e6

[PATCH] block/loop: Use global lock for ioctl() operation.

is caused by calling blkdev_reread_part() with lock held. This patch does not address it. [1] https://syzkaller.appspot.com/bug?id=f3cfe26e785d85f9ee259f385515291d21bd80a3 [2] https://syzkaller.appspot.com/bug?id=bf154052f0eea4bc7712499e4569505907d15889 Signed-off-by: Tetsuo Handa Reported-b

[PATCH] block/loop: Don't grab "struct file" for vfs_getattr() operation.

vfs_getattr() needs "struct path" rather than "struct file". Let's use path_get()/path_put() rather than get_file()/fput(). Signed-off-by: Tetsuo Handa --- drivers/block/loop.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/block/lo

Re: [PATCH v4] block/loop: Serialize ioctl operations.

On 2018/09/25 3:47, Jan Kara wrote: >> +/* >> + * unlock_loop - Unlock loop_mutex as needed. >> + * >> + * Explicitly call this function before calling fput() or >> blkdev_reread_part() >> + * in order to avoid circular lock dependency. After this function is >> called, >> + * current thread is

Re: [PATCH v3] block/loop: Serialize ioctl operations.

Since syzbot restarted testing linux-next.git , it is a good chance to test this patch for unexpected regressions (until you come up with a good alternative). On 2018/06/26 23:34, Tetsuo Handa wrote: > Did you get any idea? > > On 2018/06/05 3:13, Jens Axboe wrote: >> On 6/4/18

Re: [PATCH] bdi: Fix another oops in wb_workfn()

On 2018/06/18 22:46, Jan Kara wrote: > syzbot is reporting NULL pointer dereference at wb_workfn() [1] due to [1] https://syzkaller.appspot.com/bug?id=e0818ccb7e46190b3f1038b0c794299208ed4206 line is missing. > wb->bdi->dev being NULL. And Dmitry confirmed that wb->state was > WB_shutting_down

Re: [PATCH -v2] loop: add recursion validation to LOOP_CHANGE_FD

I noticed that this patch is forgotten at ext4.git#loop-fix and therefore is not available at linux-next.git . Please be sure to include for 4.18 . On 2018/05/08 0:37, Theodore Ts'o wrote: > Refactor the validation code used in LOOP_SET_FD so it is also used in > LOOP_CHANGE_FD. Otherwise it is

Re: [PATCH] bdi: Fix another oops in wb_workfn()

Tejun Heo wrote: > On Sun, May 27, 2018 at 11:21:25AM +0900, Tetsuo Handa wrote: > > syzbot is still hitting NULL pointer dereference at wb_workfn() [1]. > > This might be because we overlooked that delayed_work_timer_fn() does not > > check WB_registered before calling

[PATCH] bdi: Fix another oops in wb_workfn()

>From 8a8222698163d1fe180258566e9a3ff43f54fcd9 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Sun, 27 May 2018 11:08:20 +0900 Subject: [PATCH] bdi: Fix another oops in wb_workfn() syzbot is still hitting NULL pointer dereference at wb_wo

Re: general protection fault in wb_workfn (2)

Forwarding http://lkml.kernel.org/r/201805251915.fgh64517.hvfjoolffmq...@i-love.sakura.ne.jp . Jan Kara wrote: > > void delayed_work_timer_fn(struct timer_list *t) > > { > > struct delayed_work *dwork = from_timer(dwork, t, timer); > > > > /* should have been called from irqsafe timer

[PATCH v3] block/loop: Serialize ioctl operations.

race bugs should no longer exist. Thus, it will be easy to test whether this patch broke something. [1] https://syzkaller.appspot.com/bug?id=f3cfe26e785d85f9ee259f385515291d21bd80a3 [2] https://syzkaller.appspot.com/bug?id=bf154052f0eea4bc7712499e4569505907d15889 Signed-off-by: Tetsuo Handa &

Re: [PATCH] bdi: Fix oops in wb_workfn()

Jan Kara wrote: > > void delayed_work_timer_fn(struct timer_list *t) > > { > > struct delayed_work *dwork = from_timer(dwork, t, timer); > > > > /* should have been called from irqsafe timer with irq already off */ > > __queue_work(dwork->cpu, dwork->wq, >work); > > } > > > > Then,

Re: INFO: task hung in blk_queue_enter

I checked counter values using debug printk() patch shown below, and found that q->q_usage_counter.count == 1 when this deadlock occurs. Since sum of percpu_count did not change after percpu_ref_kill(), this is not a race condition while folding percpu counter values into atomic counter value.

Re: INFO: task hung in blk_queue_enter

Bart Van Assche wrote: > On Wed, 2018-05-16 at 17:16 +0200, Dmitry Vyukov wrote: > > On Wed, May 16, 2018 at 4:56 PM, Bart Van Assche <bart.vanass...@wdc.com> > > wrote: > > > On Wed, 2018-05-16 at 22:05 +0900, Tetsuo Handa wrote: > > > > diff -

Re: [PATCH] bdi: Fix oops in wb_workfn()

Tetsuo Handa wrote: > Jan Kara wrote: > > Make wb_workfn() use wakeup_wb() for requeueing the work which takes all > > the necessary precautions against racing with bdi unregistration. > > Yes, this patch will solve NULL pointer dereference bug. But is it OK to leave &g

Re: INFO: task hung in blk_queue_enter

Tetsuo Handa wrote: > I couldn't check whether freeze_depth in blk_freeze_queue_start() was 1, > but presumably q->mq_freeze_depth > 0 because syz-executor7(PID=5010) is > stuck at wait_event() in blk_queue_enter(). > > Since flags == 0, preempt == false. Since stuck at

Re: INFO: task hung in blk_queue_enter

I managed to obtain SysRq-t when khungtaskd fires using debug printk() ( https://groups.google.com/forum/#!topic/syzkaller-bugs/OTuOsVebAiE ). Only 4 threads shown below seems to be relevant to this problem. [ 246.929688] taskPC stack pid father [ 249.888937]

[PATCH v2] block/loop: Serialize ioctl operations.

>From 86acfa7288c5e6ddab26f430e2bd2f42ad1407f0 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Wed, 9 May 2018 13:01:31 +0900 Subject: [PATCH v2] block/loop: Serialize ioctl operations. syzbot is reporting NULL pointer dereference [1] which is cause

Re: general protection fault in lo_ioctl (2)

Theodore Y. Ts'o wrote: > On Tue, May 08, 2018 at 08:05:12PM +0900, Tetsuo Handa wrote: > > > > So, it is time to think how to solve this race condition, as well as how to > > solve > > lockdep's deadlock warning (and I guess that syzbot is actually hitting > >

Re: general protection fault in lo_ioctl (2)

On 2018/05/08 5:56, Tetsuo Handa wrote: > On 2018/05/02 20:23, Dmitry Vyukov wrote: >> #syz dup: INFO: rcu detected stall in blkdev_ioctl > > The cause of stall turned out to be ioctl(loop_fd, LOOP_CHANGE_FD, loop_fd). > > But we haven't explained the cause of NULL pointer

Re: general protection fault in lo_ioctl (2)

On 2018/05/02 20:23, Dmitry Vyukov wrote: > #syz dup: INFO: rcu detected stall in blkdev_ioctl The cause of stall turned out to be ioctl(loop_fd, LOOP_CHANGE_FD, loop_fd). But we haven't explained the cause of NULL pointer dereference which can occur when raced with ioctl(LOOP_CLR_FD).

Re: [PATCH] loop: add recursion validation to LOOP_CHANGE_FD

Theodore Y. Ts'o wrote: > On Mon, May 07, 2018 at 10:21:04PM +0900, Tetsuo Handa wrote: > > > I don't understand your concern; where are we going to out_putf when > > > error == 0? > > Ah, now I see it, thanks. I'll send a revised patch. > > > By the way,

Re: [PATCH] loop: add recursion validation to LOOP_CHANGE_FD

Theodore Y. Ts'o wrote: > On Mon, May 07, 2018 at 08:16:58PM +0900, Tetsuo Handa wrote: > > Oh, your message did not arrive at news.gmane.org and I didn't notice that > > you > > already wrote this patch. But please update yours or review mine shown > > below. &g

Re: [PATCH] loop: add recursion validation to LOOP_CHANGE_FD

o out_putf" is wrong. >From eed54c6ae475860a9c63b37b58f34735e792eef7 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Sat, 5 May 2018 12:59:12 +0900 Subject: [PATCH] block/loop: Add recursion check for LOOP_CHANGE_FD request. syzbot is reportin

Re: INFO: rcu detected stall in blkdev_ioctl

If various stall reports regarding loop_set_fd() are hitting below sequence, a patch was proposed at https://groups.google.com/d/msg/syzkaller-bugs/5pzXJ8yQFR0/vWeRytaQBAAJ . -- #include #include #include #include #include int main(int argc, char *argv[]) { const int fd =

Re: [PATCH] loop: remember whether sysfs_create_group() succeeded

Milan Broz wrote: > On 05/04/2018 04:40 PM, Tetsuo Handa wrote: > > The loop module ignores sysfs_create_group() failure and pretends that > > LOOP_SET_FD request succeeded. I guess that the author of commit > > ee86273062cbb310 ("loop: add some basic read-only sysf

Re: INFO: task hung in blk_freeze_queue

A patch for this specific report is ready. I don't know whether other "dup" reports will be solved by this patch. Thus, I "undup" this report. #syz undup >From eed54c6ae475860a9c63b37b58f34735e792eef7 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.

Re: [PATCH v2] loop: remember whether sysfs_create_group() succeeded

Jens Axboe wrote: > On 5/4/18 10:14 AM, Tetsuo Handa wrote: > >>>> If that's not easily done, then my next suggestion would be to > >>>> use a loop flag for it, LO_FLAGS_SYSFS_SETUP or something like that. > >>> > >>> Yes, that would be p

[PATCH v2] loop: remember whether sysfs_create_group() succeeded

_flags for recording whether sysfs entry exists might be strange... Anyway, updated patch is shown below. >From c9897b6387b13b533c32dcc624e12a93f23224d0 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Sat, 5 May 2018 00:52:59 +0900 Subject: [PATCH v2] loo

Re: [PATCH] loop: remember whether sysfs_create_group() succeeded

Jens Axboe wrote: > On 5/4/18 8:27 AM, Tetsuo Handa wrote: > > Jens Axboe wrote: > >> On 5/4/18 5:47 AM, Tetsuo Handa wrote: > >>> >From 626d33de1b70b11ecaf95a9f83f7644998e54cbb Mon Sep 17 00:00:00 2001 > >>> From: Tetsuo Handa <penguin-ker...@i-love

Re: [PATCH] loop: remember whether sysfs_create_group() succeeded

Jens Axboe wrote: > On 5/4/18 5:47 AM, Tetsuo Handa wrote: > >>From 626d33de1b70b11ecaf95a9f83f7644998e54cbb Mon Sep 17 00:00:00 2001 > > From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> > > Date: Wed, 2 May 2018 23:03:48 +0900 > > Subject: [PATCH] loop:

[PATCH] loop: remember whether sysfs_create_group() succeeded

>From 626d33de1b70b11ecaf95a9f83f7644998e54cbb Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Wed, 2 May 2018 23:03:48 +0900 Subject: [PATCH] loop: remember whether sysfs_create_group() succeeded syzbot is hitting WARN() triggered by memory allocat

Re: [PATCH] bdi: Fix oops in wb_workfn()

Jan Kara wrote: > Make wb_workfn() use wakeup_wb() for requeueing the work which takes all > the necessary precautions against racing with bdi unregistration. Yes, this patch will solve NULL pointer dereference bug. But is it OK to leave list_empty(>work_list) == false situation? Who takes over

Re: INFO: task hung in wb_shutdown (2)

>From 1b90d7f71d60e743c69cdff3ba41edd1f9f86f93 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Wed, 2 May 2018 07:07:55 +0900 Subject: [PATCH v2] bdi: wake up concurrent wb_shutdown() callers. syzbot is reporting hung tasks at wait_on_bit(WB_shut

Re: INFO: task hung in wb_shutdown (2)

Tejun, Jan, Jens, Can you review this patch? syzbot has hit this bug for nearly 4000 times but is still unable to find a reproducer. Therefore, the only way to test would be to apply this patch upstream and test whether the problem is solved. On 2018/04/24 21:19, Tetsuo Handa wrote: >&g

Re: INFO: rcu detected stall in blkdev_ioctl

Like I noted in a patch at https://groups.google.com/d/msg/syzkaller-bugs/2Rw8-OM6IbM/PzdobV8kAgAJ loop module is not thread safe. Can we use more global lock?

Re: write call hangs in kernel space after virtio hot-remove

Tejun Heo wrote: > (cc'ing Tetuso and quoting whole message) > > Tetuso, could this be the same problem as the hang in wb_shutdown() > syszbot reported? Excuse me, but I'm too unfamiliar to judge it. ;-) Anyway, since Fabiano has a reproducer, I appreciate trying a patch at

Re: general protection fault in wb_workfn

On 2018/04/23 19:09, Tetsuo Handa wrote: > By the way, I got a newbie question regarding commit 5318ce7d46866e1d ("bdi: > Shutdown writeback on all cgwbs in cgwb_bdi_destroy()"). It uses clear_bit() > to clear WB_shutting_down bit so that threads waiting at wait_on_b

Re: general protection fault in wb_workfn

On 2018/04/20 1:05, syzbot wrote: > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: [#1] SMP KASAN > Dumping ftrace buffer: >    (ftrace buffer empty) > Modules linked in: > CPU: 0 PID: 28 Comm: kworker/u4:2

Re: WARNING: lock held when returning to user space!

The patch was sent to linux.git as commit bdac616db9bbadb9. #syz fix: loop: fix LOOP_GET_STATUS lock imbalance

Re: [PATCH] loop: fix LOOP_GET_STATUS lock imbalance

Omar Sandoval wrote: > From: Omar Sandoval > > Commit 2d1d4c1e591f made loop_get_status() drop lo_ctx_mutex before > returning, but the loop_get_status_old(), loop_get_status64(), and > loop_get_status_compat() wrappers don't call loop_get_status() if the > passed argument is

Re: Hangs in balance_dirty_pages with arm-32 LPAE + highmem

Laura Abbott wrote: > On 02/26/2018 06:28 AM, Michal Hocko wrote: > > On Fri 23-02-18 11:51:41, Laura Abbott wrote: > >> Hi, > >> > >> The Fedora arm-32 build VMs have a somewhat long standing problem > >> of hanging when running mkfs.ext4 with a bunch of processes stuck > >> in D state. This has

block: mempool allocation hangs under OOM. (Re: A pitfall of mempool?)

Hello. I noticed a hang up where kswapd was unable to get memory for bio from mempool at bio_alloc_bioset(GFP_NOFS) request at http://lkml.kernel.org/r/201704252022.dfb26076.fmoqvfotjos...@i-love.sakura.ne.jp . Since there is no mean to check whether kswapd was making progress, I tried below

[4.11-rc1 block]: Boot failure due to memory corruption.

Hello. I noticed that 4.11-rc1 crashes upon boot. [5.358848] Fusion MPT base driver 3.04.20 [5.360468] Copyright (c) 1999-2008 LSI Corporation [5.377993] e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI [5.380697] e1000: