All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	"Wei Yongjun" <yongjun_wei@trendmicro.com.cn>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Flora Cui" <Flora.Cui@amd.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
	"Tom St Denis" <tom.stdenis@amd.com>,
	"Thomas Hellstrom" <thellstrom@vmware.com>,
	"Laurent Pinchart" <laurent.pinchart+renesas@ideasonboard.com>,
	"Xinliang Liu" <z.liuxinliang@hisilicon.com>,
	"VMware Graphics" <linux-graphics-maintainer@vmware.com>,
	"Vitaly Prosyak" <vitaly.prosyak@amd.com>,
	"Alexandre Demers" <alexandre.f.demers@gmail.com>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	"Eric Engestrom" <eric@engestrom.ch>,
	"Emily Deng" <Emily.Deng@amd.com>,
	"Junwei Zhang" <Jerry.Zhang@amd.com>,
	"Michel Dänzer" <michel.daenzer@amd.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Colin Ian King" <colin.king@can>
Subject: Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()
Date: Thu, 10 Nov 2016 13:03:20 +0200	[thread overview]
Message-ID: <87pom3egw7.fsf@intel.com> (raw)
In-Reply-To: <1577179.SKedfdZVPT@avalon>

On Thu, 10 Nov 2016, Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@intel.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: "Eric Engestrom" <eric.engestrom@imgtec.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Eric Engestrom" <eric@engestrom.ch>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"David Airlie" <airlied@linux.ie>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Wei Yongjun" <yongjun_wei@trendmicro.com.cn>,
	"Daniel Vetter" <daniel.vetter@intel.com>,
	"Flora Cui" <Flora.Cui@amd.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
	"Tom St Denis" <tom.stdenis@amd.com>,
	"Chunming Zhou" <David1.Zhou@amd.com>,
	"Thomas Hellstrom" <thellstrom@vmware.com>,
	"Laurent Pinchart" <laurent.pinchart+renesas@ideasonboard.com>,
	"Sinclair Yeh" <syeh@vmware.com>,
	"Xinliang Liu" <z.liuxinliang@hisilicon.com>,
	"Xinwei Kong" <kong.kongxinwei@hisilicon.com>,
	"VMware Graphics" <linux-graphics-maintainer@vmware.com>,
	"Vitaly Prosyak" <vitaly.prosyak@amd.com>,
	"Alexandre Demers" <alexandre.f.demers@gmail.com>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	"Emily Deng" <Emily.Deng@amd.com>,
	"Colin Ian King" <colin.king@canonical.com>,
	"Junwei Zhang" <Jerry.Zhang@amd.com>,
	"Michel Dänzer" <michel.daenzer@amd.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>
Subject: Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()
Date: Thu, 10 Nov 2016 13:03:20 +0200	[thread overview]
Message-ID: <87pom3egw7.fsf@intel.com> (raw)
In-Reply-To: <1577179.SKedfdZVPT@avalon>

On Thu, 10 Nov 2016, Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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

  reply	other threads:[~2016-11-10 11:03 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-04 15:32 [PATCH] drm: make drm_get_format_name atomic/irq safe again Rob Clark
2016-11-04 15:45 ` Rob Clark
2016-11-04 16:27 ` Ville Syrjälä
2016-11-04 17:12   ` Rob Clark
2016-11-04 17:32     ` Eric Engestrom
2016-11-04 17:33       ` [PATCH variant 1] " Eric Engestrom
2016-11-04 17:33         ` Eric Engestrom
2016-11-04 17:50       ` [PATCH] " Rob Clark
2016-11-04 18:13         ` Ville Syrjälä
2016-11-05  1:23         ` Eric Engestrom
2016-11-05  1:33           ` [PATCH] drm: move allocation out of drm_get_format_name() Eric Engestrom
2016-11-05  1:33             ` Eric Engestrom
2016-11-05  6:56             ` Thomas Hellstrom
2016-11-05  6:56               ` Thomas Hellstrom
2016-11-05 12:11             ` Christian König
2016-11-05 12:11               ` Christian König
2016-11-05 16:38               ` Eric Engestrom
2016-11-05 16:38                 ` Eric Engestrom
2016-11-05 16:49                 ` Rob Clark
2016-11-05 16:49                   ` Rob Clark
2016-11-06  9:47                   ` Christian König
2016-11-06  9:47                     ` Christian König
2016-11-06 13:03                     ` Rob Clark
2016-11-06 13:03                       ` Rob Clark
2016-11-07  0:47                       ` Eric Engestrom
2016-11-07  0:47                         ` Eric Engestrom
2016-11-07  0:48                         ` [PATCH v2] " Eric Engestrom
2016-11-07  0:48                           ` Eric Engestrom
2016-11-07  7:46                           ` Christian König
2016-11-07  7:46                             ` Christian König
2016-11-07  8:10                           ` Jani Nikula
2016-11-07  8:10                             ` Jani Nikula
2016-11-07 17:12                             ` Eric Engestrom
2016-11-07 17:12                               ` Eric Engestrom
2016-11-07 17:38                               ` Jani Nikula
2016-11-07 17:38                                 ` Jani Nikula
2016-11-08 10:15                                 ` [Intel-gfx] " Daniel Vetter
2016-11-08 10:15                                   ` Daniel Vetter
2016-11-09  0:17                                   ` [PATCH v3] " Eric Engestrom
2016-11-09  0:17                                     ` Eric Engestrom
2016-11-09  1:09                                     ` [Intel-gfx] " Daniel Vetter
2016-11-09  1:09                                       ` Daniel Vetter
2016-11-09  1:13                                       ` Daniel Vetter
2016-11-09  1:13                                         ` [Intel-gfx] " Daniel Vetter
2016-11-09 11:42                                         ` Eric Engestrom
2016-11-09 11:42                                           ` [Intel-gfx] " Eric Engestrom
2016-11-09 13:13                                           ` Daniel Vetter
2016-11-09 13:13                                             ` Daniel Vetter
2016-11-09 16:59                                             ` Eric Engestrom
2016-11-09 16:59                                               ` [Intel-gfx] " Eric Engestrom
2016-11-10 10:03                                               ` Laurent Pinchart
2016-11-10 10:03                                                 ` [Intel-gfx] " Laurent Pinchart
2016-11-10 10:30                                                 ` Jani Nikula
2016-11-10 10:30                                                   ` Jani Nikula
2016-11-10 10:59                                                   ` Laurent Pinchart
2016-11-10 10:59                                                     ` Laurent Pinchart
2016-11-10 11:03                                                     ` Jani Nikula [this message]
2016-11-10 11:03                                                       ` Jani Nikula
2016-11-11  9:26                                               ` Daniel Vetter
2016-11-11  9:26                                                 ` Daniel Vetter
2016-11-12  1:12                                                 ` [PATCH v4] " Eric Engestrom
2016-11-12  1:12                                                   ` Eric Engestrom
2016-11-07 14:45                           ` [PATCH v2] " Rob Clark
2016-11-07 14:45                             ` Rob Clark
2016-11-07 18:12                           ` Sinclair Yeh
2016-11-07 18:12                             ` Sinclair Yeh
2016-11-05  1:52           ` [PATCH] drm: make drm_get_format_name atomic/irq safe again Rob Clark
2016-11-05  2:15 ` ✓ Fi.CI.BAT: success for drm: move allocation out of drm_get_format_name() Patchwork
2016-11-07  1:15 ` ✗ Fi.CI.BAT: warning for drm: move allocation out of drm_get_format_name() (rev2) Patchwork
2016-11-07  8:18   ` Saarinen, Jani
2016-11-09  0:31 ` ✗ Fi.CI.BAT: failure for drm: move allocation out of drm_get_format_name() (rev3) Patchwork
2016-11-12  1:45 ` ✓ Fi.CI.BAT: success for drm: move allocation out of drm_get_format_name() (rev4) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pom3egw7.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=Emily.Deng@amd.com \
    --cc=Flora.Cui@amd.com \
    --cc=Jerry.Zhang@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexandre.f.demers@gmail.com \
    --cc=colin.king@can \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=eric@engestrom.ch \
    --cc=gustavo.padovan@collabora.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-graphics-maintainer@vmware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michel.daenzer@amd.com \
    --cc=thellstrom@vmware.com \
    --cc=tom.stdenis@amd.com \
    --cc=vitaly.prosyak@amd.com \
    --cc=yongjun_wei@trendmicro.com.cn \
    --cc=z.liuxinliang@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.