From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH] drm: Use kvzalloc for allocating blob property memory Date: Fri, 29 Jun 2018 19:38:32 +0300 Message-ID: <20180629163832.GF5565@intel.com> References: <20180629142710.2069-1-michel@daenzer.net> <20180629161205.GE5565@intel.com> <32deece3-b583-ca58-cd41-ba11846240c8@daenzer.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id B52A76F102 for ; Fri, 29 Jun 2018 16:38:38 +0000 (UTC) Content-Disposition: inline In-Reply-To: <32deece3-b583-ca58-cd41-ba11846240c8@daenzer.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Michel =?iso-8859-1?Q?D=E4nzer?= Cc: David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org T24gRnJpLCBKdW4gMjksIDIwMTggYXQgMDY6Mjc6MjhQTSArMDIwMCwgTWljaGVsIETDpG56ZXIg d3JvdGU6Cj4gT24gMjAxOC0wNi0yOSAwNjoxMiBQTSwgVmlsbGUgU3lyasOkbMOkIHdyb3RlOgo+ ID4gT24gRnJpLCBKdW4gMjksIDIwMTggYXQgMDQ6Mjc6MTBQTSArMDIwMCwgTWljaGVsIETDpG56 ZXIgd3JvdGU6Cj4gPj4gRnJvbTogTWljaGVsIETDpG56ZXIgPG1pY2hlbC5kYWVuemVyQGFtZC5j b20+Cj4gPj4KPiA+PiBUaGUgcHJvcGVydHkgc2l6ZSBtYXkgYmUgY29udHJvbGxlZCBieSB1c2Vy c3BhY2UsIGNhbiBiZSBsYXJnZSAoSSd2ZQo+ID4+IHNlZW4gZmFpbHVyZSB3aXRoIG9yZGVyIDQs IGkuZS4gMTYgcGFnZXMgLyA2NCBLQikgYW5kIGRvZXNuJ3QgbmVlZCB0byBiZQo+ID4+IHBoeXNp Y2FsbHkgY29udGlndW91cy4KPiA+IAo+ID4gSSB3b25kZXIgaWYgd2Ugc2hvdWxkIGVuZm9yY2Ug c29tZSBraW5kIG9mIHJlYXNvbmFibGUgbGltaXQKPiA+IG9uIHRoZSBibG9iIHNpemUuIExvb2tz IGxpa2Ugd2UgYWxsb3cgYW55dGhpbmcgdXAgdG8KPiA+IFVMT05HX01BWCBjdXJyZW50bHkuIFdl IGNhbid0IHRlbGwgYXQgY3JlYXRlYmxvYiB0aW1lIGhvdwo+ID4gdGhlIHRoaW5nIGlzIGdvaW5n IHRvIGJlIHVzZWQsIHNvIGNhbid0IGhhdmUgYW55IGtpbmQKPiA+IG9mIHByb3BlcnR5IHNwZWNp ZmljIGxpbWl0IHVuZm9ydHVuYXRlbHkuCj4gCj4gVGhlIGZhaWx1cmUgSSB3YXMgc2VlaW5nIHdh cyBmb3IgYSBnYW1tYSBMVVQsIHNvIGEgc2l6ZSBsaW1pdCBhbG9uZQo+IGNhbm5vdCBzb2x2ZSB0 aGUgaXNzdWUuCgpTdXJlLiBJIHdhcyBqdXN0IHRoaW5raW5nIHRoYXQgbWF5YmUgd2Ugc2hvdWxk bid0IGFsbG93IHNvbWVvbmUgdG8KYWxsb2NhdGUgdW5saW1pdGVkIGFtb3VudHMgb2Yga2VybmVs IG1lbW9yeSB2aWEgdGhpcyBpbnRlcmZhY2UuIEJ1dAp0byBkbyB0aGF0IGVmZmVjdGl2ZWx5IHdl J2QgYWxzbyBuZWVkIHRvIGxpbWl0IHRoZSB0b3RhbCBhbW91bnQgdXNlZApieSBhbGwgYmxvYnMu CgotLSAKVmlsbGUgU3lyasOkbMOkCkludGVsCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3Rz LmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44F8DC6778A for ; Fri, 29 Jun 2018 16:38:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DCB3423C49 for ; Fri, 29 Jun 2018 16:38:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DCB3423C49 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937023AbeF2Qik (ORCPT ); Fri, 29 Jun 2018 12:38:40 -0400 Received: from mga01.intel.com ([192.55.52.88]:38079 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753553AbeF2Qij (ORCPT ); Fri, 29 Jun 2018 12:38:39 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Jun 2018 09:38:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,286,1526367600"; d="scan'208";a="68830748" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga001.jf.intel.com with SMTP; 29 Jun 2018 09:38:33 -0700 Received: by stinkbox (sSMTP sendmail emulation); Fri, 29 Jun 2018 19:38:32 +0300 Date: Fri, 29 Jun 2018 19:38:32 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Michel =?iso-8859-1?Q?D=E4nzer?= Cc: 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: <20180629163832.GF5565@intel.com> References: <20180629142710.2069-1-michel@daenzer.net> <20180629161205.GE5565@intel.com> <32deece3-b583-ca58-cd41-ba11846240c8@daenzer.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <32deece3-b583-ca58-cd41-ba11846240c8@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 06:27:28PM +0200, Michel Dänzer wrote: > On 2018-06-29 06:12 PM, Ville Syrjälä wrote: > > 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. > > The failure I was seeing was for a gamma LUT, so a size limit alone > cannot solve the issue. Sure. I was just thinking that maybe we shouldn't allow someone to allocate unlimited amounts of kernel memory via this interface. But to do that effectively we'd also need to limit the total amount used by all blobs. -- Ville Syrjälä Intel