On 2018/06/11 20:16, Dmitry Vyukov wrote:
>> timeout = 60 and period = 1 would allow hung task to be reported as soon
>> as it remained uninterruptible for 60 seconds. That makes me easier to
>> narrow down relevant kernel messages and syzbot program.
>>
>> Well, showing exact slept time, along wit
khugepaged is trying to hold mm->mmap_sem for write, which is held
for read by a thread which is stuck at __sb_start_write(). Therefore,
#syz dup: INFO: task hung in __sb_start_write
I haven't succeeded reproducing this bug using original C reproducer.
Instead, I'm observing XFS warning using modified reproducer shown below.
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
#incl
Hello.
Commits
401c636a0eeb0d51 "kernel/hung_task.c: show all hung tasks before panic"
8cc05c71ba5f7936 "locking/lockdep: Move sanity check to inside
lockdep_print_held_locks()"
arrived at linux.git and syzbot started giving us more hints.
Quoting from
https://syzkaller.appspot.com/text?t
On 2018/06/09 6:58, Andrew Morton wrote:
> On Fri, 8 Jun 2018 15:30:43 +0200 Dmitry Vyukov wrote:
>
>> Currently task hung checking period is equal to timeout,
>> as the result hung is detected anywhere between timeout and 2*timeout.
>> This is fine for most interactive environments, but this hu
On 2018/01/22 22:32, Dmitry Vyukov wrote:
> On Tue, Jan 16, 2018 at 6:34 PM, Greg Kroah-Hartman
> wrote:
>>> The problem is testing linux-next and then using get-maintainer.pl to
>>> report the problem.
>>>
>>> If you are resource limited I would start by testing Linus's tree to
>>> find the exist
On 2018/06/07 20:00, Petr Mladek wrote:
>> ---
>>
>> drivers/tty/tty_buffer.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>> index c996b6859c5e..71958ef6a831 100644
>> --- a/drivers/tty/tty_buffer.c
>> +++ b/driv
ing to be submitted "properly" so that I can
> queue it up? :)
>
> thanks,
>
> greg k-h
>
On 2018/05/26 9:53, Tetsuo Handa wrote:
> syzbot is reporting stalls at n_tty_receive_char_special() [1]. This is
> because comparison is not working as expected
On 2018/06/02 20:58, yuzhoujian wrote:
> -void mem_cgroup_print_oom_info(struct mem_cgroup *memcg, struct task_struct
> *p)
> +void mem_cgroup_print_oom_context(struct mem_cgroup *memcg, struct
> task_struct *p,
> + enum oom_constraint constraint, nodemask_t *nodemask)
> {
>
>From 8a8222698163d1fe180258566e9a3ff43f54fcd9 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
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_workfn() [1].
This might be because we overlooked t
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 w
ing global lock, 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-b
9f27fd
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Pavel Machek
---
kernel/power/user.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/power/user.c b/kernel/power/user.c
index 75c959d..abd2255 100644
--- a/kernel/power/user.c
+++ b/kernel
r.appspot.com/bug?id=3d7481a346958d9469bebbeb0537d5f056bdd6e8
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Fixes: bc5a5e3f45d04784 ("n_tty: Don't wrap input buffer indices at buffer
size")
Cc: Peter Hurley
---
drivers/tty/n_tty.c | 13 -
1 file changed, 8 inserti
e" loop.
[1]
https://syzkaller.appspot.com/bug?id=17f23b094cd80df750e5b0f8982c521ee6bcbf40
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Cc: Peter Hurley
---
drivers/tty/n_tty.c | 42 --
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/t
David Rientjes wrote:
> The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> it cannot reap an mm. This can happen for a variety of reasons,
> including:
>
> - the inability to grab mm->mmap_sem in a sufficient amount of time,
>
> - when the mm has blockable mmu notifier
Sergey Senozhatsky wrote:
> On (05/17/18 20:21), Sergey Senozhatsky wrote:
> > Dunno...
> > For instance, can we store context tracking info as a extended record
> > data? We have that dict/dict_len thing. So may we can store tracking
> > info there? Extended records will appear on the serial conso
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. Tha
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
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:
>
#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
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
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 stuc
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] jbd2/sda
>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
>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_fi
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]
> rwsem_down_read_fai
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
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
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
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
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
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().":
> https://groups.google.com/d/msg/syzkalle
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
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 ICAN
>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
>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
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, inte
>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
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
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
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 poi
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: panic
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). Therefore,
>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->han
sg(fd, &msg, 0);
return 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 k
t previous 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_on
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 r
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: EX
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
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 = o
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
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,
>
>
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
>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
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] (
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
syzbot
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 sg
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)
> >
> > h
>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 seems
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
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
>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
>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 f
>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 image
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?
OK. Patch was sent to linux.git as 6c1e851c4edc13a4.
#syz fix: random: fix possible sleeping allocation from irq context
>From 9f41081f8bd6762a6f629e5e23e6d07a62bba69c Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sat, 28 Apr 2018 11:24:09 +0900
Subject: [PATCH] fuse: don't keep inode-less dentry at fuse_ctl_add_dentry().
syzbot is reporting NULL pointer dereference at fuse_ctl_remove_conn() [1].
Oh, pull request was already sent. Should be merged shortly.
https://marc.info/?l=linux-kernel&m=152472466201090&w=2
Ingo Molnar wrote:
> What\'s the resolution here? It\'s still triggering upstream as well, as of
> 69bfd470f462:
>
> [8.881634] dracut: Switching root
>
> [8.994899]
> [8.999338] WARNING: inconsistent lock state
> [9.003760] 4.17.0-rc2-00151-g43ae
>From 3606b60f60f5a2053290e7160a6fd3ee40f38a51 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 25 Apr 2018 15:26:10 +0900
Subject: [PATCH] tty: Use __GFP_NOFAIL for tty_ldisc_get()
syzbot is reporting crashes triggered by memory allocation fault injection
at tty_ldisc_get() [1]. As
OK. Patch is in tty.git#tty-linus as 598c2d41ff44889d.
#syz fix: tty: Avoid possible error pointer dereference at tty_ldisc_restore().
OK. Patch is in vfs.git#for-next as 4fb48871409e2fcd.
#syz fix: restore cond_resched() in shrink_dcache_parent()
OK. Patch is in tty.git#tty-linus as 903f9db10f18f735.
#syz fix: tty: Don't call panic() at tty_ldisc_init()
OK. Patch was sent to linux.git as 1f5781725dcbb026.
#syz fix: commoncap: Handle memory allocation failure.
Theodore Y. Ts'o wrote:
> On Wed, Apr 25, 2018 at 09:46:42AM +0900, Tetsuo Handa wrote:
> > Theodore Ts'o wrote:
> > > We can do a sleeping allocation from an irq context when CONFIG_NUMA
> > > is enabled. Fix this by initializing the NUMA crng instances in a
Kees Cook wrote:
> On Tue, Apr 24, 2018 at 12:58 PM, Serge E. Hallyn wrote:
> > Quoting Tycho Andersen (ty...@tycho.ws):
> >> On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote:
> >> > Tycho Andersen wrote:
> >> > > > >
Theodore Ts\'o wrote:
> We can do a sleeping allocation from an irq context when CONFIG_NUMA
> is enabled. Fix this by initializing the NUMA crng instances in a
> workqueue.
Offloading to workqueue context itself would be OK,
but this patch makes linux.git unbootable because
if (crng ==
David Rientjes wrote:
> On Tue, 24 Apr 2018, Tetsuo Handa wrote:
>
> > > > We can call __oom_reap_task_mm() from exit_mmap() (or __mmput()) before
> > > > exit_mmap() holds mmap_sem for write. Then, at least memory which could
> > > > have been reclaime
Tycho Andersen wrote:
> > > + if (unlikely(crypto_aead_ivsize(big_key_aead) != GCM_AES_IV_SIZE)) {
> > > + WARN(1, "big key algorithm changed?");
Please avoid using WARN() WARN_ON() etc.
syzbot would catch it and panic() due to panic_on_warn == 1.
On 2018/04/24 1:01, Tetsuo Handa wrote:
> Bisection reached to commit e052c6d15c61cc4c ("tty: Use unbound workqueue
> for all input workers") added in 4.4-rc1.
>
> Reverting that commit on top of 4.4 solved the lockup. But unfortunately,
> reverting that commit o
>From 39ed6be8a2c12dfe54feaa5abbc2ec46103022bf Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 24 Apr 2018 11:59:08 +0900
Subject: [PATCH] bdi: wake up concurrent wb_shutdown() callers.
syzbot is reporting hung tasks at wait_on_bit(WB_shutting_down) in
wb_shutdown() [1]. This might
> On Sun, 22 Apr 2018, Tetsuo Handa wrote:
>
> > > I'm wondering why you do not see oom killing of many processes if the
> > > victim is a very large process that takes a long time to free memory in
> > > exit_mmap() as I do because the oom reaper gives up
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_bit()
On 2018/04/22 0:34, Tetsuo Handa wrote:
> Dmitry Vyukov wrote:
>> This looks somewhat similar to "INFO: rcu detected stall in
>> __process_echoes":
>> https://syzkaller.appspot.com/bug?id=17f23b094cd80df750e5b0f8982c521ee6bcbf40
>> But I am not sure becaus
This is a side effect of doing GFP_KERNEL | __GFP_NOFAIL allocation attempt
from IRQ context.
I think that this discussion will continue at
http://lkml.kernel.org/r/201804231921.dgb18791.qovflfmjfts...@i-love.sakura.ne.jp
.
>From be88e559ec13f49b1c3aec2457c14c70f6b1926a Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Mon, 23 Apr 2018 11:21:03 +0900
Subject: [PATCH] bdi: Fix use after free bug in debugfs_remove()
syzbot is reporting use after free bug in debugfs_remove() [1].
This is because fault injection m
Greg Kroah-Hartman wrote:
> > I think this can be fixed by backporting commit 4a072c71f49b
> > "random: silence compiler warnings and fix race" but I'm not sure
> > whether that depends on other changes.
>
> According to Tetsuo Handa, it's also c
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 No
David Rientjes wrote:
> How have you tested this?
>
> I'm wondering why you do not see oom killing of many processes if the
> victim is a very large process that takes a long time to free memory in
> exit_mmap() as I do because the oom reaper gives up trying to acquire
> mm->mmap_sem and just s
On 2018/03/28 16:01, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 3eb2ce825ea1ad89d20f7a3b5780df850e4be274 (Sun Mar 25 22:44:30 2018 +)
> Linux 4.16-rc7
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?extid=108696293d7a21ab688f
>
> So far this c
Dmitry Vyukov wrote:
> This looks somewhat similar to "INFO: rcu detected stall in __process_echoes":
> https://syzkaller.appspot.com/bug?id=17f23b094cd80df750e5b0f8982c521ee6bcbf40
> But I am not sure because stall stacks are somewhat different.
Yes, this will be the same one which can be reprodu
On 2018/04/10 23:33, Tetsuo Handa wrote:
> syzbot wrote:
>> syzbot has found reproducer for the following crash on upstream commit
>> c18bb396d3d261ebbb4efbc05129c5d354c541e4 (Tue Apr 10 00:04:10 2018 +)
>> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>
On 2018/04/01 5:47, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +)
> Merge tag 'ceph-for-4.16-rc8' of git://github.com/ceph/ceph-client
> syzbot dashboard link:
> https://syzkaller.appspot.co
Tetsuo Handa wrote:
> Eric Biggers wrote:
> > It seems that ->bd_mutex is held while opening and closing block devices,
> > which
> > should rank it above both ->lo_ctl_mutex and loop_index_mutex (see
> > lo_open() and
> > lo_release()).
> >
> &g
David Rientjes wrote:
> On Thu, 19 Apr 2018, Michal Hocko wrote:
>
> > > exit_mmap() does not block before set_bit(MMF_OOM_SKIP) once it is
> > > entered.
> >
> > Not true. munlock_vma_pages_all might take page_lock which can have
> > unpredictable dependences. This is the reason why we are ruli
Michal Hocko wrote:
> > We need to teach the OOM reaper stop reaping as soon as entering
> > exit_mmap().
> > Maybe let the OOM reaper poll for progress (e.g. none of get_mm_counter(mm,
> > *)
> > decreased for last 1 second) ?
>
> Can we start simple and build a more elaborate heuristics on top
Michal Hocko wrote:
> > exit_mmap() does not block before set_bit(MMF_OOM_SKIP) once it is
> > entered.
>
> Not true. munlock_vma_pages_all might take page_lock which can have
> unpredictable dependences. This is the reason why we are ruling out
> mlocked VMAs in the first place when reaping the
Kirill Tkhai wrote:
> On 18.04.2018 17:14, Tetsuo Handa wrote:
> > Kirill Tkhai wrote:
> >> The patch introduces shrinker::id number, which is used to enumerate
> >> memcg-aware shrinkers. The number start from 0, and the code tries
> >> to maintain it as small
Michal Hocko wrote:
> > > > Then, I'm tempted to call __oom_reap_task_mm() before holding mmap_sem
> > > > for write.
> > > > It would be OK to call __oom_reap_task_mm() at the beginning of
> > > > __mmput()...
> > >
> > > I am not sure I understand.
> >
> > To reduce possibility of __oom_reap_
801 - 900 of 1705 matches
Mail list logo
