Received: by 2002:ac0:a679:0:0:0:0:0 with SMTP id p54csp52419imp; Wed, 20 Feb 2019 14:06:02 -0800 (PST) X-Google-Smtp-Source: AHgI3IbGogZyZpx/O/I0CObiOKs+Oy/GMVGTQo4byegvTtOq9IlE9VMdb0iHvwaohvfFsDbMpHjH X-Received: by 2002:a63:e80e:: with SMTP id s14mr31262146pgh.30.1550700362780; Wed, 20 Feb 2019 14:06:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550700362; cv=none; d=google.com; s=arc-20160816; b=mrd6EhOW4bwxjvs5V0Dn8gbSq6vA8Tn2yJVZASbmMxEgIyw5z6NfcATRl+KuuMxo/1 SIBrl8Ci6N00thXGWRsWik9G3ELoNieN4DpT5vQP3NbCDxn7nZgNE9eKVBg8UlPAfp1E 0GHPyzix/w419/hi1miPvn54ZlEp2Gj5/4e+Dg0emQupxj8Kgnb/cWeBVx9q4/j/u9M9 PO3fwsbBSiU7vWVGgJSUEqo5cKsfqvTErFy2JCZ+gf1kfpHinw+lUCeZvGpibIPLodiO 0jxzPp+6HiZOWu1oKyqAJbm3AXaoHWA4eZaS8N5PgtQkKZo53yVZLi2w58CJS/FMfL4Q XAAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=2DJFRfyEtFXCOTyT/90JFG4VBP6YTJFVG/ddjAQamoM=; b=Sa6/Yhk8eDPjLWQIP0w1hMLJ1NrAxgcvi21q+tc/tyMQT3pQFAxHoV2awz/uVX8T9s 7qRi+tTdMhNYofGjkGhYthnIEpL0BAffQgM9hWY4qyt13sOfcfu6qzy/NVWs/08ZvANE 5hpDp0CykSlSBw95QAUlHk1oawhEs0R4EYxIoPb3qE1EbGdbIqJy9UaHPUz+r+5AvFuK DKYXeP+DZJl6uGgPPUz+Sb9F+FIY1bL3ZefloFLz3R96eNDJDHLzUp8fcdG7E91fqlsZ aqxPtZwiYxq/8i7zUwEmA/zkII852FLbmL0CWzjDVb3sRst0GWUM20AF3kXnTzSsxv27 N5hg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q1si5873074pgm.154.2019.02.20.14.05.47; Wed, 20 Feb 2019 14:06:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727223AbfBTWFO (ORCPT + 99 others); Wed, 20 Feb 2019 17:05:14 -0500 Received: from mx2.suse.de ([195.135.220.15]:56468 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725869AbfBTWFN (ORCPT ); Wed, 20 Feb 2019 17:05:13 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 56E82B633; Wed, 20 Feb 2019 22:05:12 +0000 (UTC) Date: Wed, 20 Feb 2019 23:05:10 +0100 From: Michal Hocko To: Daniel Vetter Cc: DRI Development , LKML , Daniel Vetter , Andrew Morton , Mike Rapoport , Roman Gushchin , Vlastimil Babka , Jan Stancek , Kees Cook , Andrey Ryabinin , "Michael S. Tsirkin" , Huang Ying , Bartosz Golaszewski , linux-mm@kvack.org Subject: Re: [PATCH] mm: Don't let userspace spam allocations warnings Message-ID: <20190220220510.GE4525@dhcp22.suse.cz> References: <20190220204058.11676-1-daniel.vetter@ffwll.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190220204058.11676-1-daniel.vetter@ffwll.ch> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > Cc: Andrew Morton > Cc: Mike Rapoport > Cc: Michal Hocko > Cc: Roman Gushchin > Cc: Vlastimil Babka > Cc: Jan Stancek > Cc: Kees Cook > Cc: Andrey Ryabinin > Cc: "Michael S. Tsirkin" > Cc: Huang Ying > Cc: Bartosz Golaszewski > Cc: linux-mm@kvack.org Acked-by: Michal Hocko > --- > 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