All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Michal Hocko <mhocko@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Rientjes <rientjes@google.com>,
	syzbot <syzbot+f0fc7f62e88b1de99af3@syzkaller.appspotmail.com>,
	'Dmitry Vyukov' via syzkaller-upstream-moderation
	<syzkaller-upstream-moderation@googlegroups.com>,
	linux-mm <linux-mm@kvack.org>
Subject: Re: [PATCH] mm, oom: Introduce time limit for dump_tasks duration.
Date: Thu, 6 Sep 2018 13:07:00 +0200	[thread overview]
Message-ID: <CACT4Y+Zx6Jrpjfo_sDMNuHcrPvcN3GRprtJM_bCAts7f3Cp0_g@mail.gmail.com> (raw)
In-Reply-To: <58aa0543-86d0-b2ad-7fb9-9bed7c6a1f6c@i-love.sakura.ne.jp>

On Thu, Sep 6, 2018 at 12:58 PM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2018/09/06 18:54, Dmitry Vyukov wrote:
>> On Thu, Sep 6, 2018 at 7:53 AM, Tetsuo Handa
>> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>> Dmitry Vyukov wrote:
>>>>> Also, another notable thing is that the backtrace for some reason includes
>>>>>
>>>>> [ 1048.211540]  ? oom_killer_disable+0x3a0/0x3a0
>>>>>
>>>>> line. Was syzbot testing process freezing functionality?
>>>>
>>>> What's the API for this?
>>>>
>>>
>>> I'm not a user of suspend/hibernation. But it seems that usage of the API
>>> is to write one of words listed in /sys/power/state into /sys/power/state .
>>>
>>> # echo suspend > /sys/power/state
>>
>> syzkaller should not write to /sys/power/state. The only mention of
>> "power" is in some selinux contexts.
>>
>
> OK. Then, I have no idea.
> Anyway, I think we can apply this patch.
>
> From 18876f287dd69a7c33f65c91cfcda3564233f55e Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Thu, 6 Sep 2018 19:53:18 +0900
> Subject: [PATCH] mm, oom: Introduce time limit for dump_tasks duration.
>
> Since printk() is slow, printing one line takes nearly 0.01 second.
> As a result, syzbot is stalling for 52 seconds trying to dump 5600

I wonder why there are so many of them?
We have at most 8 test processes (each having no more than 16 threads
if that matters).
No more than 1 instance of syz-executor1 at a time. But we see output
like the one below. It has lots of instances of syz-executor1 with
different pid's. So does it print all tasks that ever existed (kernel
does not store that info, right)? Or it livelocks picking up new and
new tasks as they are created slower than they are created? Or we have
tons of zombies?

...
[   8037]     0  8037    17618     8738   131072        0
0 syz-executor1
[   8039]     0  8039    17585     8737   131072        0
0 syz-executor3
[   8040]     0  8040    17618     8738   131072        0
0 syz-executor1
 schedule+0xfb/0x450 kernel/sched/core.c:3517
[   8056]     0  8056    17585     8738   126976        0
0 syz-executor4
[   8055]     0  8055    17618     8741   126976        0
0 syz-executor5
[   8060]     0  8060    17585     8740   126976        0
0 syz-executor0
[   8062]     0  8062    17585     8739   126976        0
0 syz-executor7
[   8063]     0  8063    17618     8741   126976        0
0 syz-executor5
[   8066]     0  8066    17585     8740   126976        0
0 syz-executor0
[   8067]     0  8067    17585     8737   126976        0
0 syz-executor6
[   8070]     0  8070    17618     8739   131072        0
0 syz-executor3
[   8073]     0  8073    17618     8738   131072        0
0 syz-executor1
[   8074]     0  8074    17585     8737   126976        0
0 syz-executor6
 __rwsem_down_read_failed_common kernel/locking/rwsem-xadd.c:269 [inline]
 rwsem_down_read_failed+0x362/0x610 kernel/locking/rwsem-xadd.c:286
[   8075]     0  8075    17618     8739   131072        0
0 syz-executor3
[   8077]     0  8077    17618     8738   131072        0
0 syz-executor1
[   8079]     0  8079    17585     8739   126976        0
0 syz-executor7
[   8092]     0  8092    17618     8738   131072        0
0 syz-executor1
...


> tasks at for_each_process() under RCU. Since such situation is almost
> inflight fork bomb attack (the OOM killer will print similar tasks for
> so many times), it makes little sense to print all candidate tasks.
> Thus, this patch introduces 3 seconds limit for printing.
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Dmitry Vyukov <dvyukov@google.com>
> ---
>  mm/oom_kill.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index f10aa53..48e5bf6 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -399,14 +399,22 @@ static void dump_tasks(struct mem_cgroup *memcg, const nodemask_t *nodemask)
>  {
>         struct task_struct *p;
>         struct task_struct *task;
> +       unsigned long start;
> +       unsigned int skipped = 0;
>
>         pr_info("Tasks state (memory values in pages):\n");
>         pr_info("[  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name\n");
>         rcu_read_lock();
> +       start = jiffies;
>         for_each_process(p) {
>                 if (oom_unkillable_task(p, memcg, nodemask))
>                         continue;
>
> +               if (time_after(jiffies, start + 3 * HZ)) {
> +                       skipped++;
> +                       continue;
> +               }
> +
>                 task = find_lock_task_mm(p);
>                 if (!task) {
>                         /*
> @@ -426,6 +434,8 @@ static void dump_tasks(struct mem_cgroup *memcg, const nodemask_t *nodemask)
>                 task_unlock(task);
>         }
>         rcu_read_unlock();
> +       if (skipped)
> +               pr_info("Printing %u tasks omitted.\n", skipped);
>  }
>
>  static void dump_header(struct oom_control *oc, struct task_struct *p)
> --
> 1.8.3.1
>

  reply	other threads:[~2018-09-06 11:07 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0000000000004a6b700575178b5a@google.com>
     [not found] ` <CACT4Y+aPRGUqAdJCMDWM=Zcy8ZQcHyrsB1ZuWS4VB_+wvLfeaQ@mail.gmail.com>
2018-09-05 10:53   ` INFO: task hung in ext4_da_get_block_prep Tetsuo Handa
2018-09-05 11:06     ` Dmitry Vyukov
2018-09-06  5:53       ` Tetsuo Handa
2018-09-06  9:54         ` Dmitry Vyukov
2018-09-06 10:58           ` [PATCH] mm, oom: Introduce time limit for dump_tasks duration Tetsuo Handa
2018-09-06 11:07             ` Dmitry Vyukov [this message]
2018-09-06 11:25               ` Tetsuo Handa
2018-09-06 11:23             ` Michal Hocko
2018-09-06 11:40               ` Tetsuo Handa
2018-09-06 11:53                 ` Michal Hocko
2018-09-06 12:08                   ` Dmitry Vyukov
2018-09-06 12:16                     ` Michal Hocko
2018-09-11 16:37                       ` Oleg Nesterov
2018-09-12 16:45                         ` Oleg Nesterov
2018-09-06 13:45                   ` Tetsuo Handa
2018-09-06 14:39                     ` Michal Hocko
2018-09-06 20:58                       ` Tetsuo Handa
2018-09-07  8:27                         ` Michal Hocko
2018-09-07  9:36                           ` Dmitry Vyukov
2018-09-07 10:49                             ` Tetsuo Handa
2018-09-07 11:08                             ` Michal Hocko
2018-09-08 14:00                               ` Dmitry Vyukov
2018-09-10 14:36                                 ` Dmitry Vyukov
2018-09-07 10:20                           ` Tetsuo Handa
2019-03-03 11:33 ` INFO: task hung in ext4_da_get_block_prep syzbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACT4Y+Zx6Jrpjfo_sDMNuHcrPvcN3GRprtJM_bCAts7f3Cp0_g@mail.gmail.com \
    --to=dvyukov@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=rientjes@google.com \
    --cc=syzbot+f0fc7f62e88b1de99af3@syzkaller.appspotmail.com \
    --cc=syzkaller-upstream-moderation@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.