From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752181AbcBEKfo (ORCPT ); Fri, 5 Feb 2016 05:35:44 -0500 Received: from lxorguk.ukuu.org.uk ([81.2.110.251]:56546 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751204AbcBEKfk (ORCPT ); Fri, 5 Feb 2016 05:35:40 -0500 Date: Fri, 5 Feb 2016 10:35:24 +0000 From: One Thousand Gnomes To: Dmitry Vyukov Cc: David Rientjes , Greg Kroah-Hartman , Jiri Slaby , Peter Hurley , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko Subject: Re: [PATCH] tty: use __GFP_NOWARN for user-controlled kmalloc Message-ID: <20160205103524.2a35ffff@lxorguk.ukuu.org.uk> In-Reply-To: References: <56B38F3F.40706@hurleysoftware.com> <1454610480-87854-1-git-send-email-dvyukov@google.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.29; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 5 Feb 2016 08:06:12 +0100 Dmitry Vyukov wrote: > On Thu, Feb 4, 2016 at 11:11 PM, David Rientjes wrote: > > On Thu, 4 Feb 2016, Dmitry Vyukov wrote: > > > >> Size of kmalloc() in vc_do_resize() is controlled by user. > >> Too large kmalloc() size triggers WARNING message on console. > >> > >> Use __GFP_NOWARN for this kmalloc() to not scare admins. > >> > > > > Hmm, this is hitting the WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)) for > > order >= MAX_ORDER. > > > > vc_do_resize() has > > > > if (cols > VC_RESIZE_MAXCOL || lines > VC_RESIZE_MAXROW) > > return -EINVAL; > > > > so the appropriate fix would seem to be to reject sizes that would exceed > > the page allocator's ability to return contiguous memory (MAX_ORDER) > > rather than ever trying the allocation in the first place. > > Hi David, > > Please see Alan response to original report here: > https://groups.google.com/d/msg/syzkaller/ufjvr5j0URo/lTlpYP0DBQAJ > I can't say that I fully understand it. I think we can go down to something like cols * lines < 4MB with complete safety. Alan