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

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: 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 > > wrote: > > > On Wed, 2018-05-16 at 22:05 +0900, Tetsuo Handa wrote: > > > > diff --git a/block/blk-core.c b/block/blk-c

Re: INFO: task hung in isig

syzbot wrote: > INFO: task kworker/u4:1:22 blocked for more than 120 seconds. > Not tainted 4.17.0-rc5+ #55 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kworker/u4:1D2119222 2 0x8000 > Workqueue: events_unbound flush_to_ldisc > Call Trace: >

Re: INFO: task hung in isig

syzbot wrote: > INFO: task kworker/u4:1:22 blocked for more than 120 seconds. > Not tainted 4.17.0-rc5+ #55 > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > kworker/u4:1D2119222 2 0x8000 > Workqueue: events_unbound flush_to_ldisc > Call Trace: >

Re: INFO: rcu detected stall in n_tty_receive_char_special

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master >From ada7279f7f034c5fd79fc04e1120069ea5f6cef2 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Thu, 17 May 2018 20:42:50 +0900 Subject: [PATCH] n_tty: Access echo_*

Re: INFO: rcu detected stall in n_tty_receive_char_special

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master >From ada7279f7f034c5fd79fc04e1120069ea5f6cef2 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Thu, 17 May 2018 20:42:50 +0900 Subject: [PATCH] n_tty: Access echo_* variables carefully. syzbot is report

Re: general protection fault in n_tty_flush_buffer

This will be essentially same with below one. ioctl(TIOCVHANGUP) versus ioctl(TCSETS) can race. #syz dup: KASAN: user-memory-access Write in n_tty_set_termios

Re: general protection fault in n_tty_flush_buffer

This will be essentially same with below one. ioctl(TIOCVHANGUP) versus ioctl(TCSETS) can race. #syz dup: KASAN: user-memory-access Write in n_tty_set_termios

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

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]

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] hfsplus: stop workqueue when fill_super() failed

>From ffd64dcf946502e7bb1d23c021ee9a4fc92f9312 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Tue, 15 May 2018 12:23:03 +0900 Subject: [PATCH] hfsplus: stop workqueue when fill_super() failed syzbot is reporting ODEBUG messages at hfsplus_fill_s

[PATCH] hfsplus: stop workqueue when fill_super() failed

>From ffd64dcf946502e7bb1d23c021ee9a4fc92f9312 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Tue, 15 May 2018 12:23:03 +0900 Subject: [PATCH] hfsplus: stop workqueue when fill_super() failed syzbot is reporting ODEBUG messages at hfsplus_fill_super() [1]. This is because hfsplus_fill_su

[PATCH] hfsplus: don't return 0 when fill_super() failed

>From f78a5fe168290cb9e009f4d907d04b5bfe277831 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Tue, 15 May 2018 11:38:38 +0900 Subject: [PATCH] hfsplus: don't return 0 when fill_super() failed syzbot is reporting NULL pointer dereference at moun

[PATCH] hfsplus: don't return 0 when fill_super() failed

>From f78a5fe168290cb9e009f4d907d04b5bfe277831 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Tue, 15 May 2018 11:38:38 +0900 Subject: [PATCH] hfsplus: don't return 0 when fill_super() failed syzbot is reporting NULL pointer dereference at mount_fs() [1]. This is because hfsplus_fill_su

Re: INFO: task hung in ext4_direct_IO

On 2018/05/14 23:36, syzbot wrote: > Call Trace: >  context_switch kernel/sched/core.c:2859 [inline] >  __schedule+0x801/0x1e30 kernel/sched/core.c:3501 >  schedule+0xef/0x430 kernel/sched/core.c:3545 >  __rwsem_down_read_failed_common kernel/locking/rwsem-xadd.c:269 [inline] >  

Re: INFO: task hung in ext4_direct_IO

On 2018/05/14 23:36, syzbot wrote: > Call Trace: >  context_switch kernel/sched/core.c:2859 [inline] >  __schedule+0x801/0x1e30 kernel/sched/core.c:3501 >  schedule+0xef/0x430 kernel/sched/core.c:3545 >  __rwsem_down_read_failed_common kernel/locking/rwsem-xadd.c:269 [inline] >  

[tip:locking/core] locking/lockdep: Use for_each_process_thread() for debug_show_all_locks()

Commit-ID: 0f736a52e4be86476eec1d5adbcbd9c2809ac4b4 Gitweb: https://git.kernel.org/tip/0f736a52e4be86476eec1d5adbcbd9c2809ac4b4 Author: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> AuthorDate: Fri, 6 Apr 2018 19:41:18 +0900 Committer: Ingo Molnar <mi...@kernel.org> Com

[tip:locking/core] locking/lockdep: Use for_each_process_thread() for debug_show_all_locks()

Commit-ID: 0f736a52e4be86476eec1d5adbcbd9c2809ac4b4 Gitweb: https://git.kernel.org/tip/0f736a52e4be86476eec1d5adbcbd9c2809ac4b4 Author: Tetsuo Handa AuthorDate: Fri, 6 Apr 2018 19:41:18 +0900 Committer: Ingo Molnar CommitDate: Mon, 14 May 2018 09:15:02 +0200 locking/lockdep: Use

[tip:locking/core] locking/lockdep: Move sanity check to inside lockdep_print_held_locks()

Commit-ID: 8cc05c71ba5f793690bb72aeb404dce65b5d4b52 Gitweb: https://git.kernel.org/tip/8cc05c71ba5f793690bb72aeb404dce65b5d4b52 Author: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> AuthorDate: Fri, 6 Apr 2018 19:41:19 +0900 Committer: Ingo Molnar <mi...@kernel.org> Com

[tip:locking/core] locking/lockdep: Move sanity check to inside lockdep_print_held_locks()

Commit-ID: 8cc05c71ba5f793690bb72aeb404dce65b5d4b52 Gitweb: https://git.kernel.org/tip/8cc05c71ba5f793690bb72aeb404dce65b5d4b52 Author: Tetsuo Handa AuthorDate: Fri, 6 Apr 2018 19:41:19 +0900 Committer: Ingo Molnar CommitDate: Mon, 14 May 2018 09:15:02 +0200 locking/lockdep: Move

[tip:x86/urgent] x86/kexec: Avoid double free_page() upon do_kexec_load() failure

Commit-ID: a466ef76b815b86748d9870ef2a430af7b39c710 Gitweb: https://git.kernel.org/tip/a466ef76b815b86748d9870ef2a430af7b39c710 Author: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> AuthorDate: Wed, 9 May 2018 19:42:20 +0900 Committer: Thomas Gleixner <t...@linutronix.de>

[tip:x86/urgent] x86/kexec: Avoid double free_page() upon do_kexec_load() failure

Commit-ID: a466ef76b815b86748d9870ef2a430af7b39c710 Gitweb: https://git.kernel.org/tip/a466ef76b815b86748d9870ef2a430af7b39c710 Author: Tetsuo Handa AuthorDate: Wed, 9 May 2018 19:42:20 +0900 Committer: Thomas Gleixner CommitDate: Sun, 13 May 2018 19:50:06 +0200 x86/kexec: Avoid

Re: BUG: workqueue lockup (2)

Eric Biggers wrote: > Generally it's best to close syzbot bug reports once the original cause is > fixed, so that syzbot can continue to report other bugs with the same > signature. That's difficult to judge. Closing as soon as the original cause is fixed allows syzbot to try to report different

Re: BUG: workqueue lockup (2)

Eric Biggers wrote: > Generally it's best to close syzbot bug reports once the original cause is > fixed, so that syzbot can continue to report other bugs with the same > signature. That's difficult to judge. Closing as soon as the original cause is fixed allows syzbot to try to report different

Re: KASAN: use-after-free Read in corrupted

Dmitry Vyukov wrote: > On Sun, May 13, 2018 at 12:20 PM, Tetsuo Handa > <penguin-ker...@i-love.sakura.ne.jp> wrote: > > Dmitry Vyukov wrote: > >> This looks very similar to "KASAN: use-after-free Read in > >> fuse_kill_sb_blk": > >> htt

Re: KASAN: use-after-free Read in corrupted

Dmitry Vyukov wrote: > On Sun, May 13, 2018 at 12:20 PM, Tetsuo Handa > wrote: > > Dmitry Vyukov wrote: > >> This looks very similar to "KASAN: use-after-free Read in > >> fuse_kill_sb_blk": > >> https://groups.google.com/d/msg/syzkaller-bugs/4

Re: KASAN: use-after-free Read in corrupted

Dmitry Vyukov wrote: > This looks very similar to "KASAN: use-after-free Read in fuse_kill_sb_blk": > https://groups.google.com/d/msg/syzkaller-bugs/4C4oiBX8vZ0/0NTQRcUYBgAJ > > which you fixed with "fuse: don't keep dead fuse_conn at fuse_fill_super().": >

Re: KASAN: use-after-free Read in corrupted

Dmitry Vyukov wrote: > This looks very similar to "KASAN: use-after-free Read in fuse_kill_sb_blk": > https://groups.google.com/d/msg/syzkaller-bugs/4C4oiBX8vZ0/0NTQRcUYBgAJ > > which you fixed with "fuse: don't keep dead fuse_conn at fuse_fill_super().": >

Re: general protection fault in kernfs_kill_sb (2)

On 2018/05/13 2:01, syzbot wrote: > Call Trace: >  __list_del_entry include/linux/list.h:117 [inline] >  list_del include/linux/list.h:125 [inline] >  kernfs_kill_sb+0xa0/0x350 fs/kernfs/mount.c:361 >  sysfs_kill_sb+0x22/0x40 fs/sysfs/mount.c:50 >  deactivate_locked_super+0x97/0x100 fs/super.c:316

Re: general protection fault in kernfs_kill_sb (2)

On 2018/05/13 2:01, syzbot wrote: > Call Trace: >  __list_del_entry include/linux/list.h:117 [inline] >  list_del include/linux/list.h:125 [inline] >  kernfs_kill_sb+0xa0/0x350 fs/kernfs/mount.c:361 >  sysfs_kill_sb+0x22/0x40 fs/sysfs/mount.c:50 >  deactivate_locked_super+0x97/0x100 fs/super.c:316

Re: BUG: workqueue lockup (2)

Eric Biggers wrote: > The bug that this reproducer reproduces was fixed a while ago by commit > 966031f340185e, so I'm marking this bug report fixed by it: > > #syz fix: n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD) Nope. Commit 966031f340185edd ("n_tty: fix EXTPROC vs

Re: BUG: workqueue lockup (2)

Eric Biggers wrote: > The bug that this reproducer reproduces was fixed a while ago by commit > 966031f340185e, so I'm marking this bug report fixed by it: > > #syz fix: n_tty: fix EXTPROC vs ICANON interaction with TIOCINQ (aka FIONREAD) Nope. Commit 966031f340185edd ("n_tty: fix EXTPROC vs

[PATCH] printk: inject caller information into the body of message

>From b7b0e56e06db1107f781b4cb5178fbdc99240901 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Fri, 11 May 2018 20:45:31 +0900 Subject: [PATCH] printk: inject caller information into the body of message Since syzbot frequently makes printk() floo

[PATCH] printk: inject caller information into the body of message

>From b7b0e56e06db1107f781b4cb5178fbdc99240901 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Fri, 11 May 2018 20:45:31 +0900 Subject: [PATCH] printk: inject caller information into the body of message Since syzbot frequently makes printk() flooding (e.g. memory allocation fault inject

[PATCH] printk: fix possible reuse of va_list variable

>From 766cf72b5fdc00d1cf5a8ca2c6b23ebb75e2b4d4 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Fri, 11 May 2018 19:54:19 +0900 Subject: [PATCH] printk: fix possible reuse of va_list variable I noticed that there is a possibility that printk_safe_

[PATCH] printk: fix possible reuse of va_list variable

>From 766cf72b5fdc00d1cf5a8ca2c6b23ebb75e2b4d4 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Fri, 11 May 2018 19:54:19 +0900 Subject: [PATCH] printk: fix possible reuse of va_list variable I noticed that there is a possibility that printk_safe_log_store() causes kernel oops because &q

Re: printk feature for syzbot?

Sergey Senozhatsky wrote: > On (04/26/18 12:06), Petr Mladek wrote: > > > > > Petr, Steven, Fengguang, what do you think? Do you have any objections? > > > Ideas? > > > > I wonder if we could create some mechanism that would help to extend > > struct printk_log easier in the future. > > Hm,

Re: printk feature for syzbot?

Sergey Senozhatsky wrote: > On (04/26/18 12:06), Petr Mladek wrote: > > > > > Petr, Steven, Fengguang, what do you think? Do you have any objections? > > > Ideas? > > > > I wonder if we could create some mechanism that would help to extend > > struct printk_log easier in the future. > > Hm,

[PATCH v3] x86/kexec: avoid double free_page() upon do_kexec_load() failure.

>From ff82bedd3e12f0d3353282054ae48c3bd8c72012 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Wed, 9 May 2018 12:12:39 +0900 Subject: [PATCH v3] x86/kexec: avoid double free_page() upon do_kexec_load() failure. syzbot is reporting crashes aft

[PATCH v3] x86/kexec: avoid double free_page() upon do_kexec_load() failure.

>From ff82bedd3e12f0d3353282054ae48c3bd8c72012 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Wed, 9 May 2018 12:12:39 +0900 Subject: [PATCH v3] x86/kexec: avoid double free_page() upon do_kexec_load() failure. syzbot is reporting crashes after memory allocation failure inside do_kexec_l

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)

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 > >

[PATCH v2] x86/kexec: avoid double free_page() upon do_kexec_load() failure.

Baoquan He wrote: > On 05/01/18 at 07:10pm, Tetsuo Handa wrote: > > From d54b2acf63191eba3d5052bf34fe6d26e3580ac2 Mon Sep 17 00:00:00 2001 > > From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> > > Date: Tue, 1 May 2018 15:36:52 +0900 > > Subject: [PATCH]

[PATCH v2] x86/kexec: avoid double free_page() upon do_kexec_load() failure.

Baoquan He wrote: > On 05/01/18 at 07:10pm, Tetsuo Handa wrote: > > From d54b2acf63191eba3d5052bf34fe6d26e3580ac2 Mon Sep 17 00:00:00 2001 > > From: Tetsuo Handa > > Date: Tue, 1 May 2018 15:36:52 +0900 > > Subject: [PATCH] x86/kexec: avoid double free_page() upon d

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/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: WARNING in __mutex_unlock_slowpath

On 2018/05/08 2:19, Paolo Bonzini wrote: >> [ cut here ] >> DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current) >> WARNING: CPU: 0 PID: 4525 at kernel/locking/mutex.c:1032 >> __mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032 >> Kernel panic - not syncing:

Re: WARNING in __mutex_unlock_slowpath

On 2018/05/08 2:19, Paolo Bonzini wrote: >> [ cut here ] >> DEBUG_LOCKS_WARN_ON(__owner_task(owner) != current) >> WARNING: CPU: 0 PID: 4525 at kernel/locking/mutex.c:1032 >> __mutex_unlock_slowpath+0x62e/0x8a0 kernel/locking/mutex.c:1032 >> Kernel panic - not syncing:

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: 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: KASAN: null-ptr-deref Write in simple_write_to_buffer

>From 166fa14420aa17f9a693621ef76bd107e1cb5ce8 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Mon, 7 May 2018 13:12:20 +0900 Subject: [PATCH] PM / hibernate: Fix oops at snapshot_write(). syzbot is reporting NULL pointer dereference at snapshot_w

Re: KASAN: null-ptr-deref Write in simple_write_to_buffer

>From 166fa14420aa17f9a693621ef76bd107e1cb5ce8 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Mon, 7 May 2018 13:12:20 +0900 Subject: [PATCH] PM / hibernate: Fix oops at snapshot_write(). syzbot is reporting NULL pointer dereference at snapshot_write() [1]. This is because data->

Re: WARNING in add_uevent_var

0; } >From 3eba6541da0c7338e3d71ea83cbc69962923d65e Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Mon, 7 May 2018 15:58:37 +0900 Subject: [PATCH] net: rfkill: Add filename varidity test at rfkill_alloc(). syzbot is hitting WARN() at kobject_ue

Re: WARNING in add_uevent_var

0; } >From 3eba6541da0c7338e3d71ea83cbc69962923d65e Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Mon, 7 May 2018 15:58:37 +0900 Subject: [PATCH] net: rfkill: Add filename varidity test at rfkill_alloc(). syzbot is hitting WARN() at kobject_uevent_env() [1]. This is because the test

Re: WARNING in kernfs_add_one

vious fault injection messages... >From 7ddcaa3d4327d4f29d11053bd2011bf77ecf72af Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Mon, 7 May 2018 14:19:50 +0900 Subject: [PATCH] driver core: Don't ignore class_dir_create_and_add() failure. syzbot i

Re: WARNING in kernfs_add_one

vious fault injection messages... >From 7ddcaa3d4327d4f29d11053bd2011bf77ecf72af Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Mon, 7 May 2018 14:19:50 +0900 Subject: [PATCH] driver core: Don't ignore class_dir_create_and_add() failure. syzbot is hitting WARN() at kernfs_add_one() [1]. T

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

Theodore Y. Ts'o wrote: > On Sun, May 06, 2018 at 02:03:57PM +0900, Tetsuo Handa wrote: > > > > Since syzbot is hitting this error path inside mount() request, calling > > panic() when something went wrong inside mount() request might be > > overkill. We can re

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

Theodore Y. Ts'o wrote: > On Sun, May 06, 2018 at 02:03:57PM +0900, Tetsuo Handa wrote: > > > > Since syzbot is hitting this error path inside mount() request, calling > > panic() when something went wrong inside mount() request might be > > overkill. We can re

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

On 2018/05/06 11:24, Theodore Y. Ts'o wrote: > On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote: >> Hello, >> >> syzbot found the following crash on: >> >> EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm >> syz-executor909: root inode unallocated >> Kernel panic - not syncing:

Re: kernel panic: EXT4-fs (device loop0): panic forced after error

On 2018/05/06 11:24, Theodore Y. Ts'o wrote: > On Sat, May 05, 2018 at 05:57:02PM -0700, syzbot wrote: >> Hello, >> >> syzbot found the following crash on: >> >> EXT4-fs error (device loop0): ext4_iget:4756: inode #2: comm >> syz-executor909: root inode unallocated >> Kernel panic - not syncing:

Re: [PATCH] elf: don't hash userspace addresses

Alexey Dobriyan wrote: > On Sat, May 05, 2018 at 09:31:50AM +0900, Tetsuo Handa wrote: > > Alexey Dobriyan wrote: > > > Signed-off-by: Alexey Dobriyan <adobri...@gmail.com> > > > --- > > > > > > fs/binfmt_elf.c |4 ++--

Re: [PATCH] elf: don't hash userspace addresses

Alexey Dobriyan wrote: > On Sat, May 05, 2018 at 09:31:50AM +0900, Tetsuo Handa wrote: > > Alexey Dobriyan wrote: > > > Signed-off-by: Alexey Dobriyan > > > --- > > > > > > fs/binfmt_elf.c |4 ++-- > > > 1 file changed, 2 insertions

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: 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: 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: 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 Date: Sat, 5 May 2018

Re: [PATCH] elf: don't hash userspace addresses

Alexey Dobriyan wrote: > Signed-off-by: Alexey Dobriyan > --- > > fs/binfmt_elf.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > --- a/fs/binfmt_elf.c > +++ b/fs/binfmt_elf.c > @@ -379,8 +379,8 @@ static unsigned long elf_map(struct file *filep,

Re: [PATCH] elf: don't hash userspace addresses

Alexey Dobriyan wrote: > Signed-off-by: Alexey Dobriyan > --- > > fs/binfmt_elf.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > --- a/fs/binfmt_elf.c > +++ b/fs/binfmt_elf.c > @@ -379,8 +379,8 @@ static unsigned long elf_map(struct file *filep, unsigned > long addr, > >

Re: KASAN: use-after-free Read in fuse_kill_sb_anon

Miklos, please respond to a patch at http://lkml.kernel.org/r/37d2030a-124c-9927-aa48-bb769da79...@i-love.sakura.ne.jp . #syz dup: KASAN: use-after-free Read in fuse_kill_sb_blk

Re: KASAN: use-after-free Read in fuse_kill_sb_anon

Miklos, please respond to a patch at http://lkml.kernel.org/r/37d2030a-124c-9927-aa48-bb769da79...@i-love.sakura.ne.jp . #syz dup: KASAN: use-after-free Read in fuse_kill_sb_blk

[PATCH v2] x86/kexec: avoid double free_page() upon do_kexec_load() failure.

>From 91a78abed036e1662b11cb54ae6300864e17b709 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Fri, 4 May 2018 08:26:41 +0900 Subject: [PATCH v2] x86/kexec: avoid double free_page() upon do_kexec_load() failure. syzbot is reporting crashes aft

[PATCH v2] x86/kexec: avoid double free_page() upon do_kexec_load() failure.

>From 91a78abed036e1662b11cb54ae6300864e17b709 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Fri, 4 May 2018 08:26:41 +0900 Subject: [PATCH v2] x86/kexec: avoid double free_page() upon do_kexec_load() failure. syzbot is reporting crashes after memory allocation failure inside do_kexec_l

Re: INFO: rcu detected stall in __schedule

I'm not sure whether this is a PPP bug. As of uptime = 484, RCU says that it stalled for 125 seconds. -- [ 484.407032] INFO: rcu_sched self-detected stall on CPU [ 484.412488] 0-...!: (125000 ticks this GP) idle=f3e/1/4611686018427387906 softirq=112858/112858 fqs=0 [ 484.422300]

Re: INFO: rcu detected stall in __schedule

I'm not sure whether this is a PPP bug. As of uptime = 484, RCU says that it stalled for 125 seconds. -- [ 484.407032] INFO: rcu_sched self-detected stall on CPU [ 484.412488] 0-...!: (125000 ticks this GP) idle=f3e/1/4611686018427387906 softirq=112858/112858 fqs=0 [ 484.422300]

Re: WARNING in sysfs_remove_group

syzbot has hit this bug for nearly 6000 times. Why not to fix this trivial one? ;-) >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: remembe

Re: WARNING in sysfs_remove_group

syzbot has hit this bug for nearly 6000 times. Why not to fix this trivial one? ;-) >From 626d33de1b70b11ecaf95a9f83f7644998e54cbb Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Wed, 2 May 2018 23:03:48 +0900 Subject: [PATCH] loop: remember whether sysfs_create_group() succeeded syz

Re: general protection fault in kernfs_kill_sb

On 2018/04/20 11:44, Eric Biggers wrote: > Fix for the kernfs bug is now queued in vfs/for-linus: > > #syz fix: kernfs: deal with early sget() failures Well, the following patches rpc_pipefs: deal with early sget() failures kernfs: deal with early sget() failures procfs: deal with early

Re: general protection fault in kernfs_kill_sb

On 2018/04/20 11:44, Eric Biggers wrote: > Fix for the kernfs bug is now queued in vfs/for-linus: > > #syz fix: kernfs: deal with early sget() failures Well, the following patches rpc_pipefs: deal with early sget() failures kernfs: deal with early sget() failures procfs: deal with early

Re: possible deadlock in blkdev_reread_part

Dmitry Vyukov wrote: > > syzbot is reporting various bugs which involve /dev/loopX. > > Two of them > > > > INFO: rcu detected stall in lo_ioctl > > > > https://syzkaller.appspot.com/bug?id=7b49fb610af9cca78c24e9f796f2e8b0d5573997 > > > > general protection fault in lo_ioctl (2) > > > >

Re: possible deadlock in blkdev_reread_part

Dmitry Vyukov wrote: > > syzbot is reporting various bugs which involve /dev/loopX. > > Two of them > > > > INFO: rcu detected stall in lo_ioctl > > > > https://syzkaller.appspot.com/bug?id=7b49fb610af9cca78c24e9f796f2e8b0d5573997 > > > > general protection fault in lo_ioctl (2) > > > >

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)

>From 1b90d7f71d60e743c69cdff3ba41edd1f9f86f93 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa 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_shutting_down) in wb_shutdown() [1]. This se

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: 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: general protection fault in n_tty_set_termios

This will be essentially same with below one. ioctl(TIOCVHANGUP) versus ioctl(TCSETS) can race. #syz dup: KASAN: user-memory-access Write in n_tty_set_termios

Re: general protection fault in n_tty_set_termios

This will be essentially same with below one. ioctl(TIOCVHANGUP) versus ioctl(TCSETS) can race. #syz dup: KASAN: user-memory-access Write in n_tty_set_termios

Re: kernel BUG at include/linux/mm.h:LINE!

>From d54b2acf63191eba3d5052bf34fe6d26e3580ac2 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Tue, 1 May 2018 15:36:52 +0900 Subject: [PATCH] x86/kexec: avoid double free_page() upon do_kexec_load() failure. syzbot is reporting crashes aft

Re: kernel BUG at include/linux/mm.h:LINE!

>From d54b2acf63191eba3d5052bf34fe6d26e3580ac2 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Tue, 1 May 2018 15:36:52 +0900 Subject: [PATCH] x86/kexec: avoid double free_page() upon do_kexec_load() failure. syzbot is reporting crashes after memory allocation failure inside do_kexec_l

Re: KASAN: use-after-free Read in fuse_kill_sb_blk

>From 606d54cd24b5b00e7a7e3597aabbe89719defc56 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Tue, 1 May 2018 13:12:14 +0900 Subject: [PATCH] fuse: don't keep dead fuse_conn at fuse_fill_super(). syzbot is reporting use-after-free at fuse_kill_sb

Re: KASAN: use-after-free Read in fuse_kill_sb_blk

>From 606d54cd24b5b00e7a7e3597aabbe89719defc56 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Tue, 1 May 2018 13:12:14 +0900 Subject: [PATCH] fuse: don't keep dead fuse_conn at fuse_fill_super(). syzbot is reporting use-after-free at fuse_kill_sb_blk() [1]. Since sb->s_fs_info

Re: WARNING: kmalloc bug in bfs_fill_super

>From 247cae4da0490c2e285e0a99e630ef963fabb6d5 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp> Date: Tue, 1 May 2018 14:15:19 +0900 Subject: [PATCH] bfs: add sanity check at bfs_fill_super(). syzbot is reporting too large memory allocation at bfs_fill_s

Re: WARNING: kmalloc bug in bfs_fill_super

>From 247cae4da0490c2e285e0a99e630ef963fabb6d5 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Tue, 1 May 2018 14:15:19 +0900 Subject: [PATCH] bfs: add sanity check at bfs_fill_super(). syzbot is reporting too large memory allocation at bfs_fill_super() [1]. Since file system im

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: 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: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected

OK. Patch was sent to linux.git as 6c1e851c4edc13a4. #syz fix: random: fix possible sleeping allocation from irq context

Re: WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected

OK. Patch was sent to linux.git as 6c1e851c4edc13a4. #syz fix: random: fix possible sleeping allocation from irq context

<    7   8   9   10   11   12   13   14   15   16   >