From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jani Nikula Subject: Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name() Date: Thu, 10 Nov 2016 13:03:20 +0200 Message-ID: <87pom3egw7.fsf@intel.com> References: <20161108101558.ihvrprbbdqjwu5wg@phenom.ffwll.local> <2360827.8WFanMYCQ1@avalon> <871syjfwzy.fsf@intel.com> <1577179.SKedfdZVPT@avalon> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1577179.SKedfdZVPT@avalon> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Laurent Pinchart Cc: dri-devel , Wei Yongjun , Daniel Vetter , Flora Cui , Gustavo Padovan , Tom St Denis , Thomas Hellstrom , Laurent Pinchart , Xinliang Liu , VMware Graphics , Vitaly Prosyak , Alexandre Demers , intel-gfx , Eric Engestrom , Emily Deng , Junwei Zhang , Michel =?utf-8?Q?D=C3=A4nzer?= , Linux Kernel Mailing List , Alex Deucher , Colin Ian King List-Id: dri-devel@lists.freedesktop.org T24gVGh1LCAxMCBOb3YgMjAxNiwgTGF1cmVudCBQaW5jaGFydCA8bGF1cmVudC5waW5jaGFydEBp ZGVhc29uYm9hcmQuY29tPiB3cm90ZToKPiBIaSBKYW5pLAo+Cj4gT24gVGh1cnNkYXkgMTAgTm92 IDIwMTYgMTI6MzA6MDkgSmFuaSBOaWt1bGEgd3JvdGU6Cj4+IE9uIFRodSwgMTAgTm92IDIwMTYs IExhdXJlbnQgUGluY2hhcnQgd3JvdGU6Cj4+ID4gVGhlIGlzc3VlIGhlcmUgaXMgdGhhdCBwcmlu dGsgY2FuJ3QgZm9ybWF0IHRoZSBmb3VyY2MgYXMgYSBzdHJpbmcgYnkKPj4gPiBpdHNlbGYuIFRo ZXJlJ3MgYSBidW5jaCBvZiBwbGFjZXMgaW4gdGhlIGtlcm5lbCB3aGVyZSBhIHNpbWlsYXIKPj4g PiBmb3JtYXR0aW5nIHByb2JsZW0gb2NjdXJzLiBJbiBhIGZldyBvY2Nhc2lvbnMgaXQgaGFzIGJl ZW4gc29sdmVkIGJ5Cj4+ID4gZXh0ZW5kaW5nIHByaW50ayB3aXRoIGFkZGl0aW9uYWwgZm9ybWF0 IHNwZWNpZmllcnMgKHN1Y2ggYXMgZm9yIE1BQy9JUAo+PiA+IGFkZHJlc3NlcywgR1VJRHMsIHZh cmlvdXMga2luZCBvZiBkZXZpY2UgbmFtZXMsIC4uLikuIERSTSBmb3VyY2NzIGFyZQo+PiA+IHBy b2JhYmx5IHRvbyBEUk0gc3BlY2lmaWMgdG8gYmUgd29ydGggYSBmb3JtYXQgc3BlY2lmaWVyLCBi dXQgSSB3b25kZXIKPj4gPiB3aGV0aGVyIHdlIGNvdWxkIGludHJvZHVjZSBhIG5ldyBzcGVjaWZp ZXIgdGhhdCB0YWtlcyBhIGZ1bmN0aW9uIHBvaW50ZXIKPj4gPiBhcyBhIGZvcm1hdHRpbmcgaGVs cGVyLiBBbm90aGVyIHNpbWlsYXJseSBjcmF6eSBvcHRpb24gd291bGQgYmUgYSBmb3JtYXQKPj4g PiBzcGVjaWZpZXIgZm9yIHN0cmluZ3MgdGhhdCB3b3VsZCBmcmVlIHRoZSBwYXNzZWQgcG9pbnRl ciBhZnRlciBwcmludGluZwo+PiA+IGl0Lgo+PiAKPj4gSSB0aGluayB0aGVyZSBhcmUgdG9vIG1h bnkgbm9uLXN0YW5kYXJkIGZvcm1hdCBzcGVjaWZpZXJzIGFscmVhZHkuIEkKPj4gY2FuJ3QgcmV2 aWV3IHRoZSBub24tc3RhbmRhcmQgZm9ybWF0IHN0cmluZ3Mgd2l0aG91dCBsb29raW5nIGF0Cj4+ IERvY3VtZW50YXRpb24vcHJpbmstZm9ybWF0cy50eHQgZmlyc3QuIFRoZSBmb3JtYXR0aW5nIGhv b2sgd291bGQgYmUgYQo+PiBnZW5lcmljIGFsdGVybmF0aXZlLCBidXQgdGhhdCdzIG1vcmUgdGhh biBhIGxpdHRsZSBzY2FyeSBmcm9tIHRoZQo+PiBzZWN1cml0eSBzdGFuZHBvaW50LiBBbmQgd2hh dCBpZiB0aGUgaG9vayBoYXMgdG8gYWxsb2NhdGUgbWVtb3J5PyBDYW4ndAo+PiBkbyB0aGF0IGlu IGF0b21pYyBjb250ZXh0cy4KPgo+IFRoZXJlIGFyZSBsb3RzIG9mIGRldGFpbHMgdG8gc29ydCBv dXQgb2J2aW91c2x5IGFuZCBJIGRvbid0IGhhdmUgYW4gYW5zd2VyIHRvIAo+IGFsbCBxdWVzdGlv bnMgeWV0LiBJIHRoaW5rIGl0IHdvdWxkIGJlIHdvcnRoIHJlc2VhcmNoaW5nIHRoaXMsIGFzIHRo ZSBwcm9ibGVtIAo+IGlzbid0IHNwZWNpZmljIHRvIERSTS9LTVMuCgpUaGF0J3MgZWFzeSB0byBh Z3JlZSB0bzsgYXMgbXVjaCBhcyB5b3UgZGlkbid0IG1lYW4gdG8gc2hvb3QgZG93biB0aGUKcGF0 Y2gsIEkgZGlkbid0IG1lYW4gdG8gc2hvb3QgZG93biB5b3VyIGlkZWEhIDopCgpCUiwKSmFuaS4K CgotLSAKSmFuaSBOaWt1bGEsIEludGVsIE9wZW4gU291cmNlIFRlY2hub2xvZ3kgQ2VudGVyCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBt YWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755298AbcKJLDb (ORCPT ); Thu, 10 Nov 2016 06:03:31 -0500 Received: from mga07.intel.com ([134.134.136.100]:60409 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754654AbcKJLDa (ORCPT ); Thu, 10 Nov 2016 06:03:30 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,618,1473145200"; d="scan'208";a="784816439" From: Jani Nikula To: Laurent Pinchart Cc: Eric Engestrom , Daniel Vetter , Eric Engestrom , Linux Kernel Mailing List , David Airlie , dri-devel , Wei Yongjun , Daniel Vetter , Flora Cui , Gustavo Padovan , Tom St Denis , Chunming Zhou , Thomas Hellstrom , Laurent Pinchart , Sinclair Yeh , Xinliang Liu , Xinwei Kong , VMware Graphics , Vitaly Prosyak , Alexandre Demers , intel-gfx , Emily Deng , Colin Ian King , Junwei Zhang , Michel =?utf-8?Q?D=C3=A4nzer?= , Alex Deucher , Christian =?utf-8?Q?K=C3=B6nig?= Subject: Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name() In-Reply-To: <1577179.SKedfdZVPT@avalon> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20161108101558.ihvrprbbdqjwu5wg@phenom.ffwll.local> <2360827.8WFanMYCQ1@avalon> <871syjfwzy.fsf@intel.com> <1577179.SKedfdZVPT@avalon> Date: Thu, 10 Nov 2016 13:03:20 +0200 Message-ID: <87pom3egw7.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 10 Nov 2016, Laurent Pinchart wrote: > Hi Jani, > > On Thursday 10 Nov 2016 12:30:09 Jani Nikula wrote: >> On Thu, 10 Nov 2016, Laurent Pinchart wrote: >> > The issue here is that printk can't format the fourcc as a string by >> > itself. There's a bunch of places in the kernel where a similar >> > formatting problem occurs. In a few occasions it has been solved by >> > extending printk with additional format specifiers (such as for MAC/IP >> > addresses, GUIDs, various kind of device names, ...). DRM fourccs are >> > probably too DRM specific to be worth a format specifier, but I wonder >> > whether we could introduce a new specifier that takes a function pointer >> > as a formatting helper. Another similarly crazy option would be a format >> > specifier for strings that would free the passed pointer after printing >> > it. >> >> I think there are too many non-standard format specifiers already. I >> can't review the non-standard format strings without looking at >> Documentation/prink-formats.txt first. The formatting hook would be a >> generic alternative, but that's more than a little scary from the >> security standpoint. And what if the hook has to allocate memory? Can't >> do that in atomic contexts. > > There are lots of details to sort out obviously and I don't have an answer to > all questions yet. I think it would be worth researching this, as the problem > isn't specific to DRM/KMS. That's easy to agree to; as much as you didn't mean to shoot down the patch, I didn't mean to shoot down your idea! :) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center