From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
To: Michal Hocko <mhocko@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, guro@fb.com,
kirill.shutemov@linux.intel.com, linux-kernel@vger.kernel.org,
rientjes@google.com, yang.s@alibaba-inc.com,
Andrew Morton <akpm@linux-foundation.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [RFC PATCH] memcg, oom: throttle dump_header for memcg ooms without eligible tasks
Date: Mon, 15 Oct 2018 21:47:08 +0900 [thread overview]
Message-ID: <6c0a57b3-bfd4-d832-b0bd-5dd3bcae460e@i-love.sakura.ne.jp> (raw)
In-Reply-To: <20181015112427.GI18839@dhcp22.suse.cz>
On 2018/10/15 20:24, Michal Hocko wrote:
> On Mon 15-10-18 19:57:35, Tetsuo Handa wrote:
>> On 2018/10/15 17:19, Michal Hocko wrote:
>>> As so many dozens of times before, I will point you to an incremental
>>> nature of changes we really prefer in the mm land. We are also after a
>>> simplicity which your proposal lacks in many aspects. You seem to ignore
>>> that general approach and I have hard time to consider your NAK as a
>>> relevant feedback. Going to an extreme and basing a complex solution on
>>> it is not going to fly. No killable process should be a rare event which
>>> requires a seriously misconfigured memcg to happen so wildly. If you can
>>> trigger it with a normal user privileges then it would be a clear bug to
>>> address rather than work around with printk throttling.
>>>
>>
>> I can trigger 200+ times / 900+ lines / 69KB+ of needless OOM messages
>> with a normal user privileges. This is a lot of needless noise/delay.
>
> I am pretty sure you have understood the part of my message you have
> chosen to not quote where I have said that the specific rate limitting
> decisions can be changed based on reasonable configurations. There is
> absolutely zero reason to NAK a natural decision to unify the throttling
> and cook a per-memcg way for a very specific path instead.
>
>> No killable process is not a rare event, even without root privileges.
>>
>> [root@ccsecurity kumaneko]# time ./a.out
>> Killed
>>
>> real 0m2.396s
>> user 0m0.000s
>> sys 0m2.970s
>> [root@ccsecurity ~]# dmesg | grep 'no killable' | wc -l
>> 202
>> [root@ccsecurity ~]# dmesg | wc
>> 942 7335 70716
>
> OK, so this is 70kB worth of data pushed throug the console. Is this
> really killing any machine?
>
Nobody can prove that it never kills some machine. This is just one example result of
one example stress tried in my environment. Since I am secure programming man from security
subsystem, I really hate your "Can you trigger it?" resistance. Since this is OOM path
where nobody tests, starting from being prepared for the worst case keeps things simple.
next prev parent reply other threads:[~2018-10-15 12:47 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-10 0:08 INFO: rcu detected stall in shmem_fault syzbot
2018-10-10 0:12 ` Tetsuo Handa
2018-10-10 4:11 ` David Rientjes
2018-10-10 7:55 ` Dmitry Vyukov
2018-10-10 9:13 ` Michal Hocko
2018-10-10 9:33 ` Dmitry Vyukov
2018-10-10 9:02 ` Michal Hocko
2018-10-10 8:59 ` Michal Hocko
2018-10-10 10:43 ` Tetsuo Handa
2018-10-10 11:35 ` Michal Hocko
2018-10-10 11:48 ` Sergey Senozhatsky
2018-10-10 12:25 ` Michal Hocko
2018-10-10 12:29 ` Dmitry Vyukov
2018-10-10 12:36 ` Dmitry Vyukov
2018-10-10 13:10 ` Tetsuo Handa
2018-10-10 13:17 ` Dmitry Vyukov
2018-10-11 1:17 ` Sergey Senozhatsky
2018-10-10 15:17 ` Sergey Senozhatsky
2018-10-10 14:19 ` Tetsuo Handa
2018-10-10 15:11 ` [RFC PATCH] memcg, oom: throttle dump_header for memcg ooms without eligible tasks Michal Hocko
2018-10-11 6:37 ` Tetsuo Handa
2018-10-12 10:47 ` Tetsuo Handa
2018-10-12 11:20 ` Johannes Weiner
2018-10-12 12:08 ` Michal Hocko
2018-10-12 12:10 ` Tetsuo Handa
2018-10-12 12:41 ` Johannes Weiner
2018-10-12 12:58 ` Tetsuo Handa
2018-10-13 11:09 ` Tetsuo Handa
2018-10-13 11:22 ` Johannes Weiner
2018-10-13 11:28 ` Tetsuo Handa
2018-10-15 8:19 ` Michal Hocko
2018-10-15 10:57 ` Tetsuo Handa
2018-10-15 11:24 ` Michal Hocko
2018-10-15 12:47 ` Tetsuo Handa [this message]
2018-10-15 13:35 ` Michal Hocko
2018-10-16 0:55 ` Tetsuo Handa
2018-10-16 9:20 ` Michal Hocko
2018-10-16 11:05 ` Tetsuo Handa
2018-10-16 11:17 ` Michal Hocko
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=6c0a57b3-bfd4-d832-b0bd-5dd3bcae460e@i-love.sakura.ne.jp \
--to=penguin-kernel@i-love.sakura.ne.jp \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=pmladek@suse.com \
--cc=rientjes@google.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=yang.s@alibaba-inc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).