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 <penguin-ker...@i-love.sakura.ne.jp>
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 de
>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].
Since
Oh, pull request was already sent. Should be merged shortly.
https://marc.info/?l=linux-kernel=152472466201090=2
Oh, pull request was already sent. Should be merged shortly.
https://marc.info/?l=linux-kernel=152472466201090=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]
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]
>From 3606b60f60f5a2053290e7160a6fd3ee40f38a51 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
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 allocat
>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()
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 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 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 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.
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
> >
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 <se...@hallyn.com> wrote:
> > Quoting Tycho Andersen (ty...@tycho.ws):
> >> On Tue, Apr 24, 2018 at 11:46:38PM +0900, Tetsuo Handa wrote:
> >> > Tycho Andersen wrote:
> >>
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 ==
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 recl
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 recl
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.
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
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 <penguin-ker...@i-love.sakura.ne.jp>
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_shut
>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 mi
> 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 tryi
> 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 tryi
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
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
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
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
.
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 <penguin-ker...@i-love.sakura.ne.jp>
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_re
>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 causing pro
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 causing pro
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
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
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
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
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
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
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
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
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/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:
>
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:
>
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
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
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
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
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
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
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
> >>
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
> >>
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
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
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 as possible.
>
> This will be used as to represent a memcg-aware shrinkers in memcg
> shrinkers map.
I'm not
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 as possible.
>
> This will be used as to represent a memcg-aware shrinkers in memcg
> shrinkers map.
I'm not
>From 3f396857d23d4bf1fac4d4332316b5ba0af6d2f9 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Wed, 18 Apr 2018 23:00:53 +0900
Subject: [PATCH v2] fs, elf: don't complain MAP_FIXED_NOREPLACE unless -EEXIST
error.
Commit 4ed28639519c7bad ("
>From 3f396857d23d4bf1fac4d4332316b5ba0af6d2f9 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 18 Apr 2018 23:00:53 +0900
Subject: [PATCH v2] fs, elf: don't complain MAP_FIXED_NOREPLACE unless -EEXIST
error.
Commit 4ed28639519c7bad ("fs, elf: drop MAP_FIXED usage from
Michal Hocko wrote:
> > > Can we try a simpler way and get back to what I was suggesting before
> > > [1] and simply not play tricks with
> > > down_write(>mmap_sem);
> > > up_write(>mmap_sem);
> > >
> > > and use the write lock in exit_mmap for oom_victims?
> >
> > You mean
Michal Hocko wrote:
> > > Can we try a simpler way and get back to what I was suggesting before
> > > [1] and simply not play tricks with
> > > down_write(>mmap_sem);
> > > up_write(>mmap_sem);
> > >
> > > and use the write lock in exit_mmap for oom_victims?
> >
> > You mean
Michal Hocko wrote:
> On Tue 17-04-18 19:52:41, David Rientjes wrote:
> > Since exit_mmap() is done without the protection of mm->mmap_sem, it is
> > possible for the oom reaper to concurrently operate on an mm until
> > MMF_OOM_SKIP is set.
> >
> > This allows munlock_vma_pages_all() to
Michal Hocko wrote:
> On Tue 17-04-18 19:52:41, David Rientjes wrote:
> > Since exit_mmap() is done without the protection of mm->mmap_sem, it is
> > possible for the oom reaper to concurrently operate on an mm until
> > MMF_OOM_SKIP is set.
> >
> > This allows munlock_vma_pages_all() to
Michal Hocko wrote:
> > Don't complain if IS_ERR_VALUE(),
>
> this is simply wrong. We do want to warn on the failure because this is
> when the actual clash happens. We should just warn on EEXIST.
>From 25442cdd31aa5cc8522923a0153a77dfd2ebc832 Mon Sep 17 00:00:00 2001
Michal Hocko wrote:
> > Don't complain if IS_ERR_VALUE(),
>
> this is simply wrong. We do want to warn on the failure because this is
> when the actual clash happens. We should just warn on EEXIST.
>From 25442cdd31aa5cc8522923a0153a77dfd2ebc832 Mon Sep 17 00:00:00 2001
From:
>From 0ba20dcbbc40b703413c9a6907a77968b087811b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Wed, 18 Apr 2018 15:31:48 +0900
Subject: [PATCH] fs, elf: don't complain MAP_FIXED_NOREPLACE if mapping
failed.
Commit 4ed28639519c7bad ("fs, elf:
>From 0ba20dcbbc40b703413c9a6907a77968b087811b Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 18 Apr 2018 15:31:48 +0900
Subject: [PATCH] fs, elf: don't complain MAP_FIXED_NOREPLACE if mapping
failed.
Commit 4ed28639519c7bad ("fs, elf: drop MAP_FIXED usage from elf_map"
David Rientjes wrote:
> On Wed, 18 Apr 2018, Tetsuo Handa wrote:
> > > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> > > reaped. This prevents the concurrent munlock_vma_pages_range() and
> > > unmap_page_range(). The oom reaper wi
David Rientjes wrote:
> On Wed, 18 Apr 2018, Tetsuo Handa wrote:
> > > Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> > > reaped. This prevents the concurrent munlock_vma_pages_range() and
> > > unmap_page_range(). The oom reaper wi
David Rientjes wrote:
> Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> reaped. This prevents the concurrent munlock_vma_pages_range() and
> unmap_page_range(). The oom reaper will simply not operate on an mm that
> has the bit set and leave the unmapping to exit_mmap().
David Rientjes wrote:
> Fix this by reusing MMF_UNSTABLE to specify that an mm should not be
> reaped. This prevents the concurrent munlock_vma_pages_range() and
> unmap_page_range(). The oom reaper will simply not operate on an mm that
> has the bit set and leave the unmapping to exit_mmap().
David Rientjes wrote:
> Since exit_mmap() is done without the protection of mm->mmap_sem, it is
> possible for the oom reaper to concurrently operate on an mm until
> MMF_OOM_SKIP is set.
>
> This allows munlock_vma_pages_all() to concurrently run while the oom
> reaper is operating on a vma.
David Rientjes wrote:
> Since exit_mmap() is done without the protection of mm->mmap_sem, it is
> possible for the oom reaper to concurrently operate on an mm until
> MMF_OOM_SKIP is set.
>
> This allows munlock_vma_pages_all() to concurrently run while the oom
> reaper is operating on a vma.
Dmitry Vyukov wrote:
> On Sat, Apr 14, 2018 at 6:40 PM, Tetsuo Handa
> <penguin-ker...@i-love.sakura.ne.jp> wrote:
> > Dmitry Vyukov wrote:
> >> On Thu, Apr 12, 2018 at 3:20 PM, Tetsuo Handa
> >> <penguin-ker...@i-love.sakura.ne.jp> wrote:
>
Dmitry Vyukov wrote:
> On Sat, Apr 14, 2018 at 6:40 PM, Tetsuo Handa
> wrote:
> > Dmitry Vyukov wrote:
> >> On Thu, Apr 12, 2018 at 3:20 PM, Tetsuo Handa
> >> wrote:
> >> > Dmitry Vyukov wrote:
> >> >> > I browsed demo_setup.sh and th
Eric Biggers wrote:
> Here's a simplified reproducer:
>
> #include
> #include
> #include
> #include
>
> int main()
> {
> int loopfd, fd;
> struct loop_info info = { .lo_flags = LO_FLAGS_PARTSCAN };
>
> loopfd = open("/dev/loop0", O_RDWR);
>
>
Eric Biggers wrote:
> Here's a simplified reproducer:
>
> #include
> #include
> #include
> #include
>
> int main()
> {
> int loopfd, fd;
> struct loop_info info = { .lo_flags = LO_FLAGS_PARTSCAN };
>
> loopfd = open("/dev/loop0", O_RDWR);
>
>
eference.
> >
> > If someone reports kernel panic triggered by forcing all memory allocations
> > for tty_ldisc_restore() to fail, we can consider adding __GFP_NOFAIL for
> > tty_ldisc_restore() case.
> >
> > [1]
> > https://syzkaller.appspot.com/
eference.
> >
> > If someone reports kernel panic triggered by forcing all memory allocations
> > for tty_ldisc_restore() to fail, we can consider adding __GFP_NOFAIL for
> > tty_ldisc_restore() case.
> >
> > [1]
> > https://syzkaller.appspot.com/bug?id=6ac
The patch was sent to linux.git as commit bdac616db9bbadb9.
#syz fix: loop: fix LOOP_GET_STATUS lock imbalance
The patch was sent to linux.git as commit bdac616db9bbadb9.
#syz fix: loop: fix LOOP_GET_STATUS lock imbalance
OK. The patch was sent to linux.git as commit 1e047eaab3bb5564.
#syz fix: block/loop: fix deadlock after loop_set_status
Dmitry Vyukov <dvyu...@google.com>" wrote:
> On Tue, Apr 10, 2018 at 3:04 PM, Tetsuo Handa
> <penguin-ker...@i-love.sakura.ne.jp> wrote:
> > Dmi
OK. The patch was sent to linux.git as commit 1e047eaab3bb5564.
#syz fix: block/loop: fix deadlock after loop_set_status
Dmitry Vyukov " wrote:
> On Tue, Apr 10, 2018 at 3:04 PM, Tetsuo Handa
> wrote:
> > Dmitry Vyukov wrote:
> >> On Tue, Apr 10, 2018 at 12:55 PM
Infinite loop inside shrink_dcache_parent() due to lack of cond_resched().
I can reproduce this issue by running the reproducer on one CPU (using "taskset
-c 0").
Reverting commit 32785c0539b7e96f ("fs/dcache.c: add cond_resched() in
shrink_dentry_list()")
solves this issue.
#syz dup: INFO: rcu
Infinite loop inside shrink_dcache_parent() due to lack of cond_resched().
I can reproduce this issue by running the reproducer on one CPU (using "taskset
-c 0").
Reverting commit 32785c0539b7e96f ("fs/dcache.c: add cond_resched() in
shrink_dentry_list()")
solves this issue.
#syz dup: INFO: rcu
Infinite loop inside shrink_dcache_parent() due to lack of cond_resched().
I can reproduce this issue by running the reproducer on one CPU (using "taskset
-c 0").
Reverting commit 32785c0539b7e96f ("fs/dcache.c: add cond_resched() in
shrink_dentry_list()")
solves this issue.
#syz dup: INFO: rcu
Infinite loop inside shrink_dcache_parent() due to lack of cond_resched().
I can reproduce this issue by running the reproducer on one CPU (using "taskset
-c 0").
Reverting commit 32785c0539b7e96f ("fs/dcache.c: add cond_resched() in
shrink_dentry_list()")
solves this issue.
#syz dup: INFO: rcu
Infinite loop inside shrink_dcache_parent() due to lack of cond_resched().
I can reproduce this issue by running the reproducer on one CPU (using "taskset
-c 0").
Reverting commit 32785c0539b7e96f ("fs/dcache.c: add cond_resched() in
shrink_dentry_list()")
solves this issue.
#syz dup: INFO: rcu
1201 - 1300 of 3819 matches
Mail list logo
