On 2018/10/18 15:55, Michal Hocko wrote:
> On Thu 18-10-18 11:46:50, Tetsuo Handa wrote:
>> This is essentially a ratelimit approach, roughly equivalent with:
>>
>> static DEFINE_RATELIMIT_STATE(oom_no_victim_rs, 60 * HZ, 1);
>> oom_no_victim_rs.flags |= RATELIMIT
On 2018/10/18 17:13, Sergey Senozhatsky wrote:
> On (10/18/18 09:56), Michal Hocko wrote:
>> On Thu 18-10-18 15:10:18, Sergey Senozhatsky wrote:
>> [...]
>>> and let's hear from MM people what they can suggest.
>>>
>>> Michal, Andrew, Johannes, any thoughts?
>>
>> I have already stated my position.
Petr Mladek wrote:
> This looks very complex and I see even more problems:
>
> + You would need to update the rate limit intervals when
> new console is attached. Note that the ratelimits might
> get initialized early during boot. It might be solvable
> but ...
>
> + You might nee
On 2018/10/19 8:54, Sergey Senozhatsky wrote:
> On (10/18/18 20:58), Tetsuo Handa wrote:
>>>
>>> A knob might do.
>>> As well as /proc/sys/kernel/printk tweaks, probably. One can even add
>>> echo "a b c d" > /proc/sys/kernel/printk to .bash
not want to use timeout.
I believe that timeout based back off is the only approach we can use
for now.
[1] https://marc.info/?i=20180910125513.311-1-mho...@kernel.org
Signed-off-by: Tetsuo Handa
---
include/linux/oom.h | 2 +-
kernel/fork.c | 13 ++
mm/mmap.c | 4
On 2018/10/21 16:10, syzbot wrote:
> BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:188
> [inline]
> BUG: KASAN: use-after-free in task_is_descendant.part.2+0x610/0x670
> security/yama/yama_lsm.c:295
> Read of size 8 at addr 8801c4666b20 by task syz-executor3/12722
>
Michal Hocko wrote:
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -898,6 +898,7 @@ static void __oom_kill_process(struct task_struct *victim)
> if (unlikely(p->flags & PF_KTHREAD))
> continue;
> do_send_sig_info(SIGKILL, SEND_SIG_FORCED, p, PIDTY
Steve Kemp wrote:
> This is an interesting idea, and an evolution since the initial
> approach which was submitted based upon xattr attributes. I still
> find the idea of using attributes simpler to manage though, since
> they're easy to add, and audit for.
>
> I suspect the biggest objection to
On 2018/10/22 17:48, Michal Hocko wrote:
> On Mon 22-10-18 16:58:50, Tetsuo Handa wrote:
>> Michal Hocko wrote:
>>> --- a/mm/oom_kill.c
>>> +++ b/mm/oom_kill.c
>>> @@ -898,6 +898,7 @@ static void __oom_kill_process(struct task_struct
>>> *victim)
>&
On 2018/10/22 18:54, Oleg Nesterov wrote:
> On 10/21, Tetsuo Handa wrote:
>>
>> On 2018/10/21 16:10, syzbot wrote:
>>> BUG: KASAN: use-after-free in __read_once_size include/linux/compiler.h:188
>>> [inline]
>>> BUG: KASAN: use-after-free in task_is_d
On 2018/10/22 19:43, Michal Hocko wrote:
> On Mon 22-10-18 18:42:30, Tetsuo Handa wrote:
>> On 2018/10/22 17:48, Michal Hocko wrote:
>>> On Mon 22-10-18 16:58:50, Tetsuo Handa wrote:
>>>> Michal Hocko wrote:
>>>>> --- a/mm/oom_kill.c
>>>>&g
On 2018/10/22 16:13, Michal Hocko wrote:
> From: Michal Hocko
>
> Tetsuo has reported [1] that a single process group memcg might easily
> swamp the log with no-eligible oom victim reports due to race between
> the memcg charge and oom_reaper
>
> Thread 1 Thread2
On 2018/10/22 21:03, Michal Hocko wrote:
> On Mon 22-10-18 20:45:17, Tetsuo Handa wrote:
>> On 2018/10/22 16:13, Michal Hocko wrote:
>>> From: Michal Hocko
>>>
>>> Tetsuo has reported [1] that a single process group memcg might easily
>>> swamp the l
On 2018/10/22 22:43, Michal Hocko wrote:
> On Mon 22-10-18 22:20:36, Tetsuo Handa wrote:
>> I mean:
>>
>> mm/memcontrol.c | 3 +-
>> mm/oom_kill.c | 111
>> +---
>> 2 files changed, 12 insertions
Michal Hocko wrote:
> On Mon 22-10-18 20:45:17, Tetsuo Handa wrote:
> > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > index e79cb59552d9..a9dfed29967b 100644
> > > --- a/mm/memcontrol.c
> > > +++ b/mm/memcontrol.c
> > > @@ -1380,10 +1380,2
On 2018/10/23 17:21, Petr Mladek wrote:
> On Fri 2018-10-19 09:18:16, Tetsuo Handa wrote:
>> I assumed we calculate the average dynamically, for the amount of
>> messages printed by an OOM event is highly unstable (depends on
>> hardware configuration such as number of n
On 2018/09/15 11:33, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 11da3a7f84f1 Linux 4.19-rc3
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=141ffbca40
> kernel config: https://syzkaller.appspot.com/x/.config?x=99
On 2018/09/17 8:00, Kees Cook wrote:
> On Sun, Sep 16, 2018 at 11:49 AM, Casey Schaufler
> wrote:
>> One solution is to leave security= as is, not affecting "minor"
>> modules and only allowing specification of one major module, and adding
>
> I would much prefer this, yes.
>
> A question remain
On 2018/07/16 16:44, Michal Hocko wrote:
>> If setting MMF_OOM_SKIP is guarded by oom_lock, we can enforce
>> last second allocation attempt like below.
>>
>> CPU 0 CPU 1
>>
>> mutex_trylock(&oom_lock) in __alloc_pages_may_oom() succeeds.
>> get_page_from_
Ingo, is this patch acceptable?
On 2018/07/07 22:54, Tetsuo Handa wrote:
>From 61752cef56fad2a910f6bfd277e1b9b028aeab43 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Sat, 7 Jul 2018 22:45:30 +0900
> Subject: [PATCH v2] x86: Avoid pr_cont() in show_opcodes()
>
> Since
Roman Gushchin wrote:
> On Tue, Jul 17, 2018 at 06:13:47AM +0900, Tetsuo Handa wrote:
> > No response from Roman and David...
> >
> > Andrew, will you once drop Roman's cgroup-aware OOM killer and David's
> > patches?
> > Roman's series has a bug
>From e8360c16fd07985686bcfb388364103f35a6523a Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 17 Jul 2018 16:43:32 +0900
Subject: [PATCH] n_tty: Protect tty->disc_data using refcount.
syzbot is reporting NULL pointer dereference at n_tty_set_termios() [1].
This is because
well.
>From 96d9d4d135994a081e54d33d23f5007c53d9b5dd Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 17 Jul 2018 22:47:11 +0900
Subject: [PATCH v3] x86: Avoid pr_cont() in show_opcodes()
Since syzbot is confused by concurrent printk() messages [1],
this patch changes show_opcodes() to use %*ph for
Corrected Signed-off-by: addresses.
>From 96d9d4d135994a081e54d33d23f5007c53d9b5dd Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 17 Jul 2018 22:47:11 +0900
Subject: [PATCH v4] x86: Avoid pr_cont() in show_opcodes()
Since syzbot is confused by concurrent printk() messages [1],
t
This patch should be dropped from linux-next because it is incorrectly
using MMF_UNSTABLE.
On 2018/06/22 6:35, David Rientjes wrote:
> diff --git a/mm/mmap.c b/mm/mmap.c
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -3059,25 +3059,28 @@ void exit_mmap(struct mm_struct *mm)
> if (unlikely(mm_is_oo
mp;x=139d342c40
Signed-off-by: Tetsuo Handa
Signed-off-by: Rasmus Villemoes
Cc: Borislav Petkov
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Andy Lutomirski
---
arch/x86/kernel/dumpstack.c | 29 +
1 file changed, 9 insert
On 2018/07/18 17:58, syzbot wrote:
> mmap: syz-executor7 (10902) uses deprecated remap_file_pages() syscall. See
> Documentation/vm/remap_file_pages.rst.
There are many reports which are stalling inside __getblk_gfp().
And there is horrible comment for __getblk_gfp():
/*
* __getblk_gfp() wi
Dmitry,
this is yet another example of stalling inside __bread_gfp().
Can you find all reports where NMI backtrace contains __bread_gfp ?
I need to wget all reports if I try to do that on my side.
If you can locally grep on your side, it will be nice.
On 2018/07/18 19:38, syzbot wrote:
> CPU: 1
On 2018/07/18 20:41, Dmitry Vyukov wrote:
> This seems to be related to 9p. After rerunning the log I got:
>
> root@syzkaller:~# ps afxu | grep syz
> root 18253 0.0 0.0 0 0 ttyS0Zl 10:16 0:00 \_
> [syz-executor]
> root@syzkaller:~# cat /proc/18253/task/*/stack
> [<0>] p9_c
On 2018/07/18 22:04, Dmitry Vyukov wrote:
> On Wed, Jul 18, 2018 at 2:53 PM, Tetsuo Handa
> wrote:
>> On 2018/07/18 20:41, Dmitry Vyukov wrote:
>>> This seems to be related to 9p. After rerunning the log I got:
>>>
>>> root@syzkaller:~# ps afxu | grep syz
&g
On 2018/07/18 23:11, Dmitry Vyukov wrote:
> On Wed, Jul 18, 2018 at 3:35 PM, Tetsuo Handa
> wrote:
>>>>> This seems to be related to 9p. After rerunning the log I got:
>>>>>
>>>>> root@syzkaller:~# ps afxu | grep syz
>>>>>
Bisection reached commit f9dac92ba908 ("virtio_ring: enable premapped mode
whatever use_dma_api").
On 2024/05/26 1:12, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:56fb6f92854f Merge tag 'drm-next-2024-05-25' of https://gi..
> git tree: upstream
> con
On 2024/06/18 10:27, Xuan Zhuo wrote:
> Maybe this patch can fix this issue:
>
>
> http://lore.kernel.org/all/20240606111345.93600-1-xuanz...@linux.alibaba.com
Yes, thank you.
#syz fix: virtio_ring: fix KMSAN error for premapped mode
call printk(), guard the whole section
between raw_spin_rq_{lock,lock_nested,trylock}() and raw_spin_rq_unlock()
using printk_deferred_{enter,exit}().
Reported-by: syzbot
Closes: https://syzkaller.appspot.com/bug?extid=18cfb7f63482af8641df
Signed-off-by: Tetsuo Handa
---
This is a repost of
On 2021/02/15 21:45, Jan Kara wrote:
> On Sat 13-02-21 23:26:37, Tetsuo Handa wrote:
>> Excuse me, but it seems to me that nothing prevents
>> ext4_xattr_set_handle() from reaching ext4_xattr_inode_lookup_create()
>> without memalloc_nofs_save() when hitting ext4_get_nojourna
On 2021/04/08 21:51, Greg Kroah-Hartman wrote:
> Remove users of tty_warn() and replace them with calls to dev_warn()
> which provides more information about the tty that has the error and
> uses the standard formatting logic.
Ouch. This series would be good for clean up, but this series might be
Hello.
I checked my patch using checkpatch.pl version 0.10
and I got the following error.
ERROR: need consistent spacing around '*' (ctx:WxV)
#2334: FILE: security/tomoyo/common.c:2306:
+static unsigned int tmy_poll(struct file *file, poll_table *wait)
Hello.
Satyam Sharma wrote:
> Looks like a checkpatch.pl bug to me -- that was nothing to warn about.
I see. I'll wait for next version.
> struct poll_table {
> poll_queue_proc qproc;
> };
poll_table is defined in include/linux/poll.h .
To change this, we have to do "sed
Hello.
Pavel Machek wrote:
> What is that? Language parser in kernel?
Yes. This is a policy parser in kernel.
TOMOYO Linux' policy is passed from/to the kernel as a plain text
(i.e. ASCII printable) file via /proc/tomoyo interface.
For example, to add a permission to allow /usr/sbin/sshd
to exe
Hello.
Richard Guy Briggs wrote:
> > Richard Guy Briggs wrote:
> > > On 14/09/28, Tetsuo Handa wrote:
> > > > (Q2) Does auxiliary record work with only type=SYSCALL case?
> > >
> > > Auxiliary records don't work with AUDIT_LOGIN because that re
Peter Zijlstra wrote:
> On Thu, Dec 25, 2014 at 10:10:45PM +0900, Tetsuo Handa wrote:
> > >From 052595ab1a1d1c5668d9de61395c9cc17694597e Mon Sep 17 00:00:00 2001
> > From: Tetsuo Handa
> > Date: Thu, 25 Dec 2014 15:51:21 +0900
> > Subject: [PATCH] sched/fair
Peter Zijlstra wrote:
> On Thu, Dec 25, 2014 at 10:10:45PM +0900, Tetsuo Handa wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index ef2b104..586ee15 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -7756,8 +7756,12 @@
>From 8579fc072fda603c4ae472cc3f0390d61556ac01 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Fri, 5 Dec 2014 21:22:22 +0900
Subject: [PATCH] sched: Fix potential call to __ffs(0) in sched_show_task()
"struct task_struct"->state is "volatile long" and __ffs() warns
Since it has been an unwritten rule that GFP_KERNEL allocations for
low-order (<=PAGE_ALLOC_COSTLY_ORDER) never fail unless chosen by
the OOM killer, there are a lot of code where allocation failure error
paths are hardly tested.
This is an update of memory allocation failure injection tester
whic
>From 052595ab1a1d1c5668d9de61395c9cc17694597e Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Thu, 25 Dec 2014 15:51:21 +0900
Subject: [PATCH] sched/fair: Fix RCU stall upon ENOMEM at sched_create_group().
When alloc_fair_sched_group() in sched_create_group() failed,
free_sched_group()
unctions for date formatting, I split it as
a new function. If it is acceptable, I'd like to make that function public
and replace tomoyo_convert_time() in security/tomoyo/util.c with that
function.
Regards.
>From 50d59b5640a7501b8d5f843fb57283fcb62b1118 Mon Sep 17 0
Huang Ying wrote:
> > > BTW: the test is run on 32 bit system.
> >
> > That sounds like the cause of your problem. The system might be out of
> > address space available for the kernel (only 1GB if x86_32). You should
> > try running tests on 64 bit systems.
>
> We run test on 32 bit and 64 bit s
Michal Hocko wrote:
> On Fri 20-03-15 22:34:21, Tetsuo Handa wrote:
> > Huang Ying wrote:
> > > > > BTW: the test is run on 32 bit system.
> > > >
> > > > That sounds like the cause of your problem. The system might be out of
> > > >
Michal Hocko wrote:
> On Fri 20-03-15 23:02:09, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Fri 20-03-15 22:34:21, Tetsuo Handa wrote:
> > > > Huang Ying wrote:
> > > > > > > BTW: the test is run on 32 bit system.
> > > > &
Tetsuo Handa wrote:
> Michal Hocko wrote:
> > We are seeing issues with the fs code now because the test cases which
> > led to the current discussion exercise FS code. The code which does
> > lock(); kmalloc(GFP_KERNEL) is not reduced there though. I am pretty sure
Johannes Weiner wrote:
> There is a possible deadlock scenario between the page allocator and
> the OOM killer. Most allocations currently retry forever inside the
> page allocator, but when the OOM killer is invoked the chosen victim
> might try taking locks held by the allocating task. This ser
Michal Hocko wrote:
> On Tue 28-04-15 19:34:47, Tetsuo Handa wrote:
> [...]
> > [PATCH 8/9] makes the speed of allocating __GFP_FS pages extremely slow (5
> > seconds / page) because out_of_memory() serialized by the oom_lock sleeps
> > for
> > 5 seconds before retu
David Rientjes wrote:
> It's not vital and somewhat unrelated to your patch, but if we can't grab
> the mutex with the trylock in __alloc_pages_may_oom() then I think it
> would be more correct to do schedule_timeout_killable() rather than
> uninterruptible. I just mention it if you happen to g
Michal Hocko wrote:
> On Wed 29-04-15 08:55:06, Johannes Weiner wrote:
> > What we can do to mitigate this is tie the timeout to the setting of
> > TIF_MEMDIE so that the wait is not 5s from the point of calling
> > out_of_memory() but from the point of where TIF_MEMDIE was set.
> > Subsequent allo
Michal Hocko wrote:
> I mean we should eventually fail all the allocation types but GFP_NOFS
> is coming from _carefully_ handled code paths which is an easier starting
> point than a random code path in the kernel/drivers. So can we finally
> move at least in this direction?
I agree that all the
Tejun Heo wrote:
> * Implement netconsole retransmission support. Matching rx socket on
> the source port is automatically created for extended targets and
> the log receiver can request retransmission by sending reponse
> packets. This is completely decoupled from the main write path and
>
Tejun Heo wrote:
> Hello, David.
>
> On Fri, Apr 17, 2015 at 01:17:12PM -0400, David Miller wrote:
> > If userland cannot run properly, it is almost certain that neither will
> > your complex reliability layer logic.
>
> * The bulk of patches are to pipe extended log messages to console
> drive
Tejun Heo wrote:
> > printk() cannot wait for ack. Trying to wait for ack would break something.
> > How can you transmit subsequent kernel messages which failed to enqueue
> > due to waiting for ack for previous kernel messages?
>
> Well, if log buffer overflows and the messages aren't at the log
Tejun Heo wrote:
> On Sat, Apr 18, 2015 at 03:03:46AM +0900, Tetsuo Handa wrote:
> > packet will be sufficient for finding out whether the packets were lost
> > and/or
> > reordered in flight.
> >
> > printk("Hello");
> >=> netc
Tejun Heo wrote:
> > If we can assume that scheduler is working, adding a kernel thread that
> > does
> >
> > while (1) {
> > read messages with metadata from /dev/kmsg
> > send them using UDP network
> > }
> >
> > might be easier than modifying netconsole module.
>
> But, I mean
Johannes Weiner wrote:
> The argument here was always that NOFS allocations are very limited in
> their reclaim powers and will trigger OOM prematurely. However, the
> way we limit dirty memory these days forces most cache to be clean at
> all times, and direct reclaim in general hasn't been allow
Michal Hocko wrote:
> > > The feature is implemented as a delayed work which is scheduled when
> > > the OOM condition is declared for the first time (oom_victims is still
> > > zero) in out_of_memory and it is canceled in exit_oom_victim after
> > > the oom_victims count drops down to zero. For th
Michal Hocko wrote:
> On Thu 11-06-15 22:12:40, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> [...]
> > > > The moom_work used by SysRq-f sometimes cannot be executed
> > > > because some work which is processed before the moom_work is processed
> > >
to use panic_on_oom > 0 by setting
adequate values to these timeouts.
>From e59b64683827151a35257384352c70bce61babdd Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Fri, 12 Jun 2015 23:56:18 +0900
Subject: [RFC] oom: im
Michal Hocko wrote:
> > This patch implements system_memdie_panic_secs sysctl which configures
> > a maximum timeout for the OOM killer to resolve the OOM situation.
> > If the system is still under OOM (i.e. the OOM victim cannot release
> > memory) after the timeout expires, it will panic the sys
Michal Hocko wrote a few minutes ago:
> Subject: [RFC -v2] panic_on_oom_timeout
Oops, we raced...
Michal Hocko wrote:
> On Tue 16-06-15 22:14:28, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > > This patch implements system_memdie_panic_secs sysctl which configures
&
Michal Hocko wrote:
> Hi,
> I was thinking about this and I am more and more convinced that we
> shouldn't care about panic_on_oom=2 configuration for now and go with
> the simplest solution first. I have revisited my original patch and
> replaced delayed work by a timer based on the feedback from
Michal Hocko wrote:
> > > + if (sysctl_panic_on_oom_timeout) {
> > > + if (sysctl_panic_on_oom > 1) {
> > > + pr_warn("panic_on_oom_timeout is ignored for
> > > panic_on_oom=2\n");
> > > + } else {
> > > + /*
> > > + * Only schedule
Michal Hocko wrote:
> > > Let's move check_panic_on_oom up before the current task is
> > > checked so that the knob value is . Do the same for the memcg in
> > > mem_cgroup_out_of_memory.
> > >
> > > Reported-by: Tetsuo Handa
> > >
Michal Hocko wrote:
> On Sat 06-06-15 15:51:35, Tetsuo Handa wrote:
> > For me, !__GFP_FS allocations not calling out_of_memory() _forever_ is a
> > violation of the user policy.
>
> Yes, the current behavior of GFP_NOFS is highly suboptimal, but this has
> _nothing_ what
Andrew Morton wrote:
> On Mon, 1 Jun 2015 15:00:01 +0200 Michal Hocko wrote:
>
> > I somehow forgot about these patches. The previous version was
> > posted here: http://marc.info/?l=linux-mm&m=142668784122763&w=2. The
> > first attempt was broken but even when fixed it seems like ignoring
> > m
David Rientjes wrote:
> On Sat, 6 Jun 2015, Tetsuo Handa wrote:
>
> > For me, !__GFP_FS allocations not calling out_of_memory() _forever_ is a
> > violation of the user policy.
> >
>
> I agree that we need work in this area to prevent livelocks that rely on
>
Michal Hocko wrote:
> Hi,
> during the last iteration of the timeout based oom killer discussion
> (http://marc.info/?l=linux-mm&m=143351457601723) I've proposed to
> introduce panic_on_oom_timeout as an extension to panic_on_oom rather
> than oom timeout which would allow OOM killer to select anot
Michal Hocko wrote:
> On Wed 17-06-15 22:59:54, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> [...]
> > > But you have a point that we could have
> > > - constrained OOM which elevates oom_victims
> > > - global OOM killer strikes but wouldn't st
Michal Hocko wrote:
> Yes I was thinking about this as well because the primary assumption
> of the OOM killer is that the victim will release some memory. And it
> doesn't matter whether the OOM killer was constrained or the global
> one. So the above looks good at first sight, I am just afraid it
Tetsuo Handa wrote:
> One case is that the system can not panic of threads are unable to call
> out_of_memory() for some reason.
^ if
> Well, if without analysis purpose,
>
> if (time_after(jiffies, oom_start + sysctl_panic_on_o
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
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
>
Forwarded by penguin-ker...@i-love.sakura.ne.jp
--- Original Message ---
From:Tetsuo Handa
To: Petr Mladek
Cc: kernel test robot , Cong Wang
, Dave Hansen , Johannes
Weiner , Mel Gorman , Michal Hocko
, Vlastimil Babka , Peter Zijlstra
,
On 2018/04/03 12:10, Eric Biggers wrote:
> On Mon, Apr 02, 2018 at 06:00:57PM -0500, Eric W. Biederman wrote:
>> syzbot writes:
>>
>>> Hello,
>>>
>>> syzbot hit the following crash on upstream commit
>>> 9dd2326890d89a5179967c947dab2bab34d7ddee (Fri Mar 30 17:29:47 2018 +)
>>> Merge tag 'ceph-
Al and Michal, are you OK with this patch?
>From bbc0d00935ebcb7e287403bae545fae9340830d9 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 4 Apr 2018 12:19:42 +0900
Subject: [PATCH] mm,vmscan: Allow preallocating memory for register_shrinker().
syzbot is catching so many bugs trigge
Yury, are you OK with this patch?
>From 7f21827cdfe9780b4949b22bcd19efa721b463d2 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 4 Apr 2018 21:12:10 +0900
Subject: [PATCH] lib/bitmap: Rewrite __bitmap_parselist().
syzbot is catching stalls at __bitmap_parselist() [1]. The trigger
This seems to be an AB-BA deadlock where the lockdep cannot report (due to use
of nested lock?).
When PID=6540 was (reported as hung) at mutex_lock_nested(&lo->lo_ctl_mutex, 1)
(id=43ca8836),
it was already holding down_write_nested(&s->s_umount, SINGLE_DEPTH_NESTING)
(id=566d4c39).
But when PI
Yury Norov wrote:
> Hi Tetsuo,
>
> Thanks for the patch.
>
> On Wed, Apr 04, 2018 at 09:21:43PM +0900, Tetsuo Handa wrote:
> > Yury, are you OK with this patch?
> >
> >
> > >From 7f21827cdfe9780b4949b22bcd19efa721b463d2 Mon Sep 17 00:00:00 2001
> &g
;sb->s_umount); */
When reporting an AB-BA deadlock like shown above, it would be nice if
trace of PID=6541 is printed as well as trace of PID=6540 before calling
panic().
Showing hung tasks up to /proc/sys/kernel/hung_task_warnings could delay
calling pa
Hello.
I manually simplified the reproducer. Since the bug is timing dependent,
this reproducer might fail to reproducer the bug. Anyway, I guess that
there is a race condition between
vfree(ldata);
tty->disc_data = NULL;
at n_tty_close() by something (ioctl(TIOCVHANGUP) ?) and
ult bug. Why not to fix?
>From 7051b364605c65d4266a71c52e5140ca5dbb4ea9 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Thu, 5 Apr 2018 09:42:43 +0900
Subject: [PATCH] tty: Don't call panic() at tty_ldisc_init()
syzbot is reporting kernel panic [1] triggered by memory allocation failur
ster
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>
> Again, what am I supposed to do with this?
>
> thanks,
>
> greg k-h
>
>From 023cf07f799d0efd160ec1c1617d5b8902577765 Mon Sep 17 00:00:00 2001
From: Tet
On 2018/04/04 2:01, syzbot wrote:
> BUG: KASAN: global-out-of-bounds in string+0x1cb/0x200 lib/vsprintf.c:598
> Write of size 1 at addr 89e166a0 by task syz-executor0/4522
>
> CPU: 1 PID: 4522 Comm: syz-executor0 Not tainted 4.16.0+ #12
> Hardware name: Google Google Compute Engine/Google
I tried the reproducer in my environment. The reproducer can trivially
reproduce a hung up. If the bug I'm observing is what the syzbot is
reporting (I ran the reproducer using init= kernel command line option),
the reason __blkdev_get() is blocked waiting for bdev->bd_mutex is that
an exiting thre
>From 91c081c4c5f6a99402542951e7de661c38f928ab Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 27 Mar 2018 19:38:33 +0900
Subject: [PATCH v2] lockdep: Show address of "struct lockdep_map" at
print_lock().
Since "struct lockdep_map" is embedded into lock obj
>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].
OK. Patch was sent to linux.git as 6c1e851c4edc13a4.
#syz fix: random: fix possible sleeping allocation from irq context
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?
>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
>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 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
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
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
>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
701 - 800 of 2177 matches
Mail list logo
