Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp659999ybz; Fri, 17 Apr 2020 07:51:01 -0700 (PDT) X-Google-Smtp-Source: APiQypJ0xvJ8yj5c6k36dpJPPkq/QK2Iz1tf5XrIIgzVsYr9IvdsgK1GgJ3bTVkmY6GEAB+x4nct X-Received: by 2002:a05:6402:558:: with SMTP id i24mr3241600edx.347.1587135060866; Fri, 17 Apr 2020 07:51:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587135060; cv=none; d=google.com; s=arc-20160816; b=hHmUHObkSB6D6cIA6HTwhWh5Atz0HFzZKrDXKu/PvAGBpVV9m4+cG4Sdmbo8XviDGk GEHj5Z1QBgMbBKqP0d9s4HwQWpvqrnWlxnzZxHI4tGAI4zshZReL5X7U7/Dy5XcApUgk mFfmpsQqmcKEYpx2xySVcmKOMlrAEk6qFit+ICXLYzTjyBD5cFg1IIkKcm7IN2AVkXDl VLzIWWR6hjdaAjv+ILXwkCcofvZ6uCIi0zpxgn/898wa4tUluOSGyyoZmSeJ3sFKZrEQ Au35AUaaA/m1Si7GmcdoOI6ebTFioLo3L/20ualfLLKqoul8NLJENIuTvbohTYS6M5hS iyUg== 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=ueAgvY/Ed5Y79pzvR+40baegINet7RQ2Zj+qyJtXJU8=; b=ZrpHk8evxKU9nuoJAr3DZILObm/P+LFNZnk1XFkIE68SQ4CM+bG973KxeygikUw5+9 PwlQv9HVOSiV6QZqh3yZGGHXZZ6QqoZn8yQKkGvhV1SJmyFOOBW9KgxVcNbBxYrVH3+U FVU/91uS923eG2EGQjoalxV2ztHsp7I4CwXZjajEhacR/w3VT0Scav19K8/ssSNzMS7A nh5WngyjT4GUX4+raOQPaTH0zCvMKOQH8Gt7S6p9VCrZZSjouYa8HW16FezMgsOh9Bxh 7zlIcUM6hEc07TtsMCA6HppJz7GLS84QvTASubYhDcvpg8Fom4kwp1hW8BjcqeekG4jh BXcg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c12si2680660edv.443.2020.04.17.07.50.36; Fri, 17 Apr 2020 07:51:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728135AbgDQOtV (ORCPT + 99 others); Fri, 17 Apr 2020 10:49:21 -0400 Received: from asavdk4.altibox.net ([109.247.116.15]:40726 "EHLO asavdk4.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727877AbgDQOtV (ORCPT ); Fri, 17 Apr 2020 10:49:21 -0400 Received: from ravnborg.org (unknown [158.248.194.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by asavdk4.altibox.net (Postfix) with ESMTPS id 3AA40804D5; Fri, 17 Apr 2020 16:49:17 +0200 (CEST) Date: Fri, 17 Apr 2020 16:49:15 +0200 From: Sam Ravnborg To: Nicolas Pitre , Greg KH Cc: gregkh@linuxfoundation.org, Adam Borowski , Chen Wandun , jslaby@suse.com, daniel.vetter@ffwll.ch, b.zolnierkie@samsung.com, lukas@wunner.de, ghalat@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] vt: don't hardcode the mem allocation upper bound Message-ID: <20200417144915.GA25595@ravnborg.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=XpTUx2N9 c=1 sm=1 tr=0 a=UWs3HLbX/2nnQ3s7vZ42gw==:117 a=UWs3HLbX/2nnQ3s7vZ42gw==:17 a=kj9zAlcOel0A:10 a=dg4UtMH5AAAA:8 a=VwQbUJbxAAAA:8 a=Zidhv8YuL5__o8oUjuwA:9 a=CjuIK1q_8ugA:10 a=byNfn09xH3PuSfgbYLsR:22 a=AjGcO6oz07-iQ99wixmX:22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Greg. I assume you will take this patch. Not really drm-misc material. Sam On Sat, Mar 28, 2020 at 05:32:42PM -0400, Nicolas Pitre wrote: > The code in vc_do_resize() bounds the memory allocation size to avoid > exceeding MAX_ORDER down the kzalloc() call chain and generating a > runtime warning triggerable from user space. However, not only is it > unwise to use a literal value here, but MAX_ORDER may also be > configurable based on CONFIG_FORCE_MAX_ZONEORDER. > Let's use KMALLOC_MAX_SIZE instead. > > Note that prior commit bb1107f7c605 ("mm, slab: make sure that > KMALLOC_MAX_SIZE will fit into MAX_ORDER") the KMALLOC_MAX_SIZE value > could not be relied upon. > > Signed-off-by: Nicolas Pitre > Cc: # v4.10+ > > > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c > index 15d2769805..37c5f21490 100644 > --- a/drivers/tty/vt/vt.c > +++ b/drivers/tty/vt/vt.c > @@ -1193,7 +1193,7 @@ static int vc_do_resize(struct tty_struct *tty, struct vc_data *vc, > if (new_cols == vc->vc_cols && new_rows == vc->vc_rows) > return 0; > > - if (new_screen_size > (4 << 20)) > + if (new_screen_size > KMALLOC_MAX_SIZE) > return -EINVAL; > newscreen = kzalloc(new_screen_size, GFP_USER); > if (!newscreen)