Re: [PATCH v1] kernel/trace:check the val against the available mem

From: Steven Rostedt <rostedt@goodmis.org>
To: Zhaoyang Huang <huangzhaoyang@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>,
	linux-kernel@vger.kernel.org, kernel-patch-test@lists.linaro.org
Subject: Re: [PATCH v1] kernel/trace:check the val against the available mem
Date: Fri, 30 Mar 2018 10:07:34 -0400	[thread overview]
Message-ID: <20180330100734.7aa872f5@gandalf.local.home> (raw)
In-Reply-To: <CAGWkznGH96VcMujvep5VtwO6M42YOmXtV=M+QZM+xWH_5DPcEA@mail.gmail.com>

On Fri, 30 Mar 2018 11:32:22 +0800
Zhaoyang Huang <huangzhaoyang@gmail.com> wrote:

> Steve, thanks for your quick feedback. The original purpose is to
> avoid such kind
> of OOM as kernel can not define the behavior of the application. I
> think it is no need
> to do the alloc->free process if we have known the number of pages
> difinitly lead to failure.
> Furthermore,  the app which screw up the thing usually escape the OOM and cause
> the innocent to be sacrificed.

A couple of things. Your patch goes way too deep into coupling with the
memory management subsystem. If I were to accept this patch, Linus
would have a fit. That get_available_mem() does not belong in the
tracing code. If you want that feature, you need to get the mm folks to
accept it, and then tracing could call it.

Next, this may be an issue with the GPF_RETRY_MAYFAIL should not
trigger OOM (although, when it fails, other allocations that happen at
that time and before the ring buffer can clean up, will cause an OOM).
I'll send an email to folks about this.

-- Steve