linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: DRI Development <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Roman Gushchin <guro@fb.com>, Vlastimil Babka <vbabka@suse.cz>,
	Jan Stancek <jstancek@redhat.com>,
	Kees Cook <keescook@chromium.org>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Huang Ying <ying.huang@intel.com>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	linux-mm@kvack.org
Subject: Re: [PATCH] mm: Don't let userspace spam allocations warnings
Date: Wed, 20 Feb 2019 23:05:10 +0100	[thread overview]
Message-ID: <20190220220510.GE4525@dhcp22.suse.cz> (raw)
In-Reply-To: <20190220204058.11676-1-daniel.vetter@ffwll.ch>

On Wed 20-02-19 21:40:58, Daniel Vetter wrote:
> memdump_user usually gets fed unchecked userspace input. Blasting a
> full backtrace into dmesg every time is a bit excessive - I'm not sure
> on the kernel rule in general, but at least in drm we're trying not to
> let unpriviledge userspace spam the logs freely. Definitely not entire
> warning backtraces.

Yes, this makes sense to me. This API sounds like an example where
returning ENOMEM to the userspace right away is much better than
spamming the log for large allocation requests. Smaller allocations
simply do not fail and the OOM killer report will be printed regardless
of __GFP_NOWARN.

> It also means more filtering for our CI, because our testsuite
> exercises these corner cases and so hits these a lot.
> 
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Roman Gushchin <guro@fb.com>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Jan Stancek <jstancek@redhat.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
> Cc: "Michael S. Tsirkin" <mst@redhat.com>
> Cc: Huang Ying <ying.huang@intel.com>
> Cc: Bartosz Golaszewski <brgl@bgdev.pl>
> Cc: linux-mm@kvack.org

Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  mm/util.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/util.c b/mm/util.c
> index 1ea055138043..379319b1bcfd 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -150,7 +150,7 @@ void *memdup_user(const void __user *src, size_t len)
>  {
>  	void *p;
>  
> -	p = kmalloc_track_caller(len, GFP_USER);
> +	p = kmalloc_track_caller(len, GFP_USER | __GFP_NOWARN);
>  	if (!p)
>  		return ERR_PTR(-ENOMEM);
>  
> -- 
> 2.20.1
> 

-- 
Michal Hocko
SUSE Labs

      parent reply	other threads:[~2019-02-20 22:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-20 20:40 [PATCH] mm: Don't let userspace spam allocations warnings Daniel Vetter
2019-02-20 21:08 ` Kees Cook
2019-02-20 22:05 ` Michal Hocko [this message]

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=20190220220510.GE4525@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=aryabinin@virtuozzo.com \
    --cc=brgl@bgdev.pl \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=guro@fb.com \
    --cc=jstancek@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mst@redhat.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=vbabka@suse.cz \
    --cc=ying.huang@intel.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).