Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1050348imm; Fri, 29 Jun 2018 10:30:16 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf++y5vdTGA7rZAPAJfhXl0HSbXfwTa3xdpsNKvb5A5KCfRj3WEAUzDS7I6D6rXYOR4WeZu X-Received: by 2002:a65:6411:: with SMTP id a17-v6mr9655835pgv.287.1530293416051; Fri, 29 Jun 2018 10:30:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530293416; cv=none; d=google.com; s=arc-20160816; b=uILcpou5KJEbqEb9BDCp4Qim0dO/ZDv/KkcEi20lgBP3RkRdnJ8PopUlOQ9az36z6x q+YIzTygGXHI0Uk58MD8jt7BM+vBCUJutcUep5bwaQfPXU3n8l55jcLDS5Ch/cBXoXzz G9+V/zbo/iS0n5k6HrbLdkC+qLncPv7KfPDenLRuBWnsmCsmZapLihucj/5UfScL5ije 9G7DLSwogvi7daoYmxDfhRkpv4GsZhLwrqzCy3X0FswcP+W8rIwE5TN9KlWBmb7isfM5 R4e8BNJVYxsPWgGNBOnD6CvvaQ79akiDrG8n6wkgReLD7YZfQ6wE2uucxR8Q1eYgq9cd P8Gg== 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-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=HP0syZDi1yF45ejt0ubqGDle8gmDDpJa6skVolldT+M=; b=RlCK+1IFDEUUxEGJozlRmt6/nmXKbcIZYsOHe01iwSN9dbiwkUld7frs5melxf5WWD ZCmCpqr8c1vqAVyU2ljALaLamwiK9Ng5wunTC3t6zMwtD6AgNzsOQnjY2NtJR1iKdL+E FJtsCENrXV05ivvp3mQ9OaAwrAHULMuR9crA+Q6iGxj3yz0R8N/eddOxMTbUzLXldSju cExGOGi4tVX2j+IX2gXljvMb/JhGiTvHjUrLgl2ylIxhuwcvenJIBPpiV+GV3ZPGt3ju jv8VVrwpSwh0jPoNvjZoA81o502BYAiZjf3+xAg0B0r8+rdifyhHGWQkeumHHCRols2L BluA== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i6-v6si8912985pgt.470.2018.06.29.10.30.01; Fri, 29 Jun 2018 10:30:16 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936858AbeF2QMR (ORCPT + 99 others); Fri, 29 Jun 2018 12:12:17 -0400 Received: from mga04.intel.com ([192.55.52.120]:53559 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936537AbeF2QMQ (ORCPT ); Fri, 29 Jun 2018 12:12:16 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2018 09:12:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,285,1526367600"; d="scan'208";a="51511896" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by fmsmga008.fm.intel.com with SMTP; 29 Jun 2018 09:12:05 -0700 Received: by stinkbox (sSMTP sendmail emulation); Fri, 29 Jun 2018 19:12:05 +0300 Date: Fri, 29 Jun 2018 19:12:05 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Michel =?iso-8859-1?Q?D=E4nzer?= Cc: Gustavo Padovan , Maarten Lankhorst , Sean Paul , David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH] drm: Use kvzalloc for allocating blob property memory Message-ID: <20180629161205.GE5565@intel.com> References: <20180629142710.2069-1-michel@daenzer.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180629142710.2069-1-michel@daenzer.net> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 29, 2018 at 04:27:10PM +0200, Michel D?nzer wrote: > From: Michel D?nzer > > The property size may be controlled by userspace, can be large (I've > seen failure with order 4, i.e. 16 pages / 64 KB) and doesn't need to be > physically contiguous. I wonder if we should enforce some kind of reasonable limit on the blob size. Looks like we allow anything up to ULONG_MAX currently. We can't tell at createblob time how the thing is going to be used, so can't have any kind of property specific limit unfortunately. > > Signed-off-by: Michel D?nzer > --- > drivers/gpu/drm/drm_property.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c > index 1f8031e30f53..cdb10f885a4f 100644 > --- a/drivers/gpu/drm/drm_property.c > +++ b/drivers/gpu/drm/drm_property.c > @@ -532,7 +532,7 @@ static void drm_property_free_blob(struct kref *kref) > > drm_mode_object_unregister(blob->dev, &blob->base); > > - kfree(blob); > + kvfree(blob); > } > > /** > @@ -559,7 +559,7 @@ drm_property_create_blob(struct drm_device *dev, size_t length, > if (!length || length > ULONG_MAX - sizeof(struct drm_property_blob)) > return ERR_PTR(-EINVAL); > > - blob = kzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL); > + blob = kvzalloc(sizeof(struct drm_property_blob)+length, GFP_KERNEL); > if (!blob) > return ERR_PTR(-ENOMEM); > > @@ -576,7 +576,7 @@ drm_property_create_blob(struct drm_device *dev, size_t length, > ret = __drm_mode_object_add(dev, &blob->base, DRM_MODE_OBJECT_BLOB, > true, drm_property_free_blob); > if (ret) { > - kfree(blob); > + kvfree(blob); > return ERR_PTR(-EINVAL); > } > > -- > 2.18.0 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrj?l? Intel