Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp2753809ybb; Mon, 30 Mar 2020 12:10:39 -0700 (PDT) X-Google-Smtp-Source: ADFU+vuEUmj1L/DvB1hiPlqsn1VSW/FMZJocrHNQ2U3u6Fh+GgT0g6iIkMMw5ZNBF5GnorcbkwGP X-Received: by 2002:aca:4a86:: with SMTP id x128mr637360oia.29.1585595439530; Mon, 30 Mar 2020 12:10:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585595439; cv=none; d=google.com; s=arc-20160816; b=y7xUWBbd2clPDb6Gs8X01eEBPJW4rQHlcjBkj6bsIgYZV2a+4worh62A1OmV1zy84b hRRiTd0pqjTELz9ZTKcbRidjSmqpfiNjcLu6sPgpeaUEI1e7FxZi+49EvvnPN1PstvNG AU2hpP9LbSdkOH4zqnNo0RARxP4FHWjRZTy5wKbCXq96FGJSbGZR1RVPt3OP2jNUxbRo 1mgOEOxGZ0AneSU0Fwd+zrgMNmEH1WM5AX3UgXbhwSUNzXZztm5e7PPKVvUG9m1N15AF E2rJpSh8HR54dmlzhhIhqVEIygT3bHRShqJ3lV7rfsdW7I5NO09L0x6N5EpTR4+yS31s z6yA== 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=4TLbYbadCTzQb766DrSDG5Lahxlr6Dx0ouu48WkPX4c=; b=Ivm02d+vbh+/Zzsb7tnqyZN9MluW8bHl2Im+3HMQ069FhzS9ifRCtBQE/R7gTLGIYe gAbG2uiVrwiiEXbVp3neCV2oVtsoyfcwsnESUZSH3wDohIG+Qe5csPnjKlBn/b8E3c1m BK1Qwi/illm8gyrrHFQ2i1CnEWxLcCDEETcO/ViJ67R37SI6/VwP9RAuWZgyenNHx8Kz EZCzTzZiINHusvmV/Js1NdVOKNuz/r5MzXG1t3bxQwjmDs46vMzHa9dycHIg6XfAYIr8 MZx3jJ9ibG9fLmQ6O7Bs3W0MZ0eTmGHPqcjO8jTq/PAWgv5lP8R9P/rSpRAUU7krH6Ht RvsQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d13si6012779oij.140.2020.03.30.12.10.24; Mon, 30 Mar 2020 12:10:39 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727954AbgC3TIG (ORCPT + 99 others); Mon, 30 Mar 2020 15:08:06 -0400 Received: from asavdk3.altibox.net ([109.247.116.14]:46740 "EHLO asavdk3.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726781AbgC3TIF (ORCPT ); Mon, 30 Mar 2020 15:08:05 -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 asavdk3.altibox.net (Postfix) with ESMTPS id BD7EB20039; Mon, 30 Mar 2020 21:08:00 +0200 (CEST) Date: Mon, 30 Mar 2020 21:07:59 +0200 From: Sam Ravnborg To: Nicolas Pitre Cc: gregkh@linuxfoundation.org, Chen Wandun , Adam Borowski , 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 v2] vt: don't use kmalloc() for the unicode screen buffer Message-ID: <20200330190759.GE7594@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=eMA9ckh1 c=1 sm=1 tr=0 a=UWs3HLbX/2nnQ3s7vZ42gw==:117 a=UWs3HLbX/2nnQ3s7vZ42gw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=dg4UtMH5AAAA:8 a=VwQbUJbxAAAA:8 a=7gkXJVJtAAAA:8 a=2V0kcv-1AK-FgQnCDtkA:9 a=CjuIK1q_8ugA:10 a=byNfn09xH3PuSfgbYLsR:22 a=AjGcO6oz07-iQ99wixmX:22 a=E9Po1WZjFZOl8hwRPBS3:22 a=pHzHmUro8NiASowvMSCR:22 a=nt3jZW36AmriUCFCBwmW:22 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Nicolas On Sat, Mar 28, 2020 at 10:25:11PM -0400, Nicolas Pitre wrote: > Even if the actual screen size is bounded in vc_do_resize(), the unicode > buffer is still a little more than twice the size of the glyph buffer > and may exceed MAX_ORDER down the kmalloc() path. This can be triggered > from user space. > > Since there is no point having a physically contiguous buffer here, > let's avoid the above issue as well as reducing pressure on high order > allocations by using vmalloc() instead. > > Signed-off-by: Nicolas Pitre > Cc: > > --- > > Changes since v1: > > - Added missing include, found by kbuild test robot. > Strange that my own build doesn't complain. When I did the drmP.h removal vmalloc was one of the header files that turned up missing in many cases - but only for some architectures. I learned to include alpha in the build. If it survived building for alpha then I had fixed the majority of the issues related to random inherited includes. The patch itself looks good. Acked-by: Sam Ravnborg > > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c > index 15d2769805..d9eb5661e9 100644 > --- a/drivers/tty/vt/vt.c > +++ b/drivers/tty/vt/vt.c > @@ -81,6 +81,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -350,7 +351,7 @@ static struct uni_screen *vc_uniscr_alloc(unsigned int cols, unsigned int rows) > /* allocate everything in one go */ > memsize = cols * rows * sizeof(char32_t); > memsize += rows * sizeof(char32_t *); > - p = kmalloc(memsize, GFP_KERNEL); > + p = vmalloc(memsize); > if (!p) > return NULL; > > @@ -366,7 +367,7 @@ static struct uni_screen *vc_uniscr_alloc(unsigned int cols, unsigned int rows) > > static void vc_uniscr_set(struct vc_data *vc, struct uni_screen *new_uniscr) > { > - kfree(vc->vc_uni_screen); > + vfree(vc->vc_uni_screen); > vc->vc_uni_screen = new_uniscr; > } >