All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Inki Dae <inki.dae@samsung.com>
Cc: Rob Clark <robdclark@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	DRI mailing list <dri-devel@lists.freedesktop.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	linux-fbdev <linux-fbdev@vger.kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"myungjoo.ham" <myungjoo.ham@samsung.com>,
	YoungJun Cho <yj44.cho@samsung.com>
Subject: Re: Introduce a new helper framework for buffer synchronization
Date: Mon, 13 May 2013 08:00:52 +0000	[thread overview]
Message-ID: <51909DB4.2060208@canonical.com> (raw)
In-Reply-To: <CAAQKjZNNw4qddo6bE5OY_CahrqDtqkxdO7Pm9RCguXyj9F4cMQ@mail.gmail.com>

Op 09-05-13 09:33, Inki Dae schreef:
> Hi all,
>
> This post introduces a new helper framework based on dma fence. And the
> purpose of this post is to collect other opinions and advices before RFC
> posting.
>
> First of all, this helper framework, called fence helper, is in progress
> yet so might not have enough comments in codes and also might need to be
> more cleaned up. Moreover, we might be missing some parts of the dma fence.
> However, I'd like to say that all things mentioned below has been tested
> with Linux platform and worked well.

> ....
>
> And tutorial for user process.
>         just before cpu access
>                 struct dma_buf_fence *df;
>
>                 df->type = DMA_BUF_ACCESS_READ or DMA_BUF_ACCESS_WRITE;
>                 ioctl(fd, DMA_BUF_GET_FENCE, &df);
>
>         after memset or memcpy
>                 ioctl(fd, DMA_BUF_PUT_FENCE, &df);
NAK.

Userspace doesn't need to trigger fences. It can do a buffer idle wait, and postpone submitting new commands until after it's done using the buffer.
Kernel space doesn't need the root hole you created by giving a dereferencing a pointer passed from userspace.
Your next exercise should be to write a security exploit from the api you created here. It's the only way to learn how to write safe code. Hint: df.ctx = mmap(..);

~Maarten

WARNING: multiple messages have this Message-ID (diff)
From: maarten.lankhorst@canonical.com (Maarten Lankhorst)
To: linux-arm-kernel@lists.infradead.org
Subject: Introduce a new helper framework for buffer synchronization
Date: Mon, 13 May 2013 10:00:52 +0200	[thread overview]
Message-ID: <51909DB4.2060208@canonical.com> (raw)
In-Reply-To: <CAAQKjZNNw4qddo6bE5OY_CahrqDtqkxdO7Pm9RCguXyj9F4cMQ@mail.gmail.com>

Op 09-05-13 09:33, Inki Dae schreef:
> Hi all,
>
> This post introduces a new helper framework based on dma fence. And the
> purpose of this post is to collect other opinions and advices before RFC
> posting.
>
> First of all, this helper framework, called fence helper, is in progress
> yet so might not have enough comments in codes and also might need to be
> more cleaned up. Moreover, we might be missing some parts of the dma fence.
> However, I'd like to say that all things mentioned below has been tested
> with Linux platform and worked well.

> ....
>
> And tutorial for user process.
>         just before cpu access
>                 struct dma_buf_fence *df;
>
>                 df->type = DMA_BUF_ACCESS_READ or DMA_BUF_ACCESS_WRITE;
>                 ioctl(fd, DMA_BUF_GET_FENCE, &df);
>
>         after memset or memcpy
>                 ioctl(fd, DMA_BUF_PUT_FENCE, &df);
NAK.

Userspace doesn't need to trigger fences. It can do a buffer idle wait, and postpone submitting new commands until after it's done using the buffer.
Kernel space doesn't need the root hole you created by giving a dereferencing a pointer passed from userspace.
Your next exercise should be to write a security exploit from the api you created here. It's the only way to learn how to write safe code. Hint: df.ctx = mmap(..);

~Maarten

WARNING: multiple messages have this Message-ID (diff)
From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Inki Dae <inki.dae@samsung.com>
Cc: Rob Clark <robdclark@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	DRI mailing list <dri-devel@lists.freedesktop.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	linux-fbdev <linux-fbdev@vger.kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"myungjoo.ham" <myungjoo.ham@samsung.com>,
	YoungJun Cho <yj44.cho@samsung.com>
Subject: Re: Introduce a new helper framework for buffer synchronization
Date: Mon, 13 May 2013 10:00:52 +0200	[thread overview]
Message-ID: <51909DB4.2060208@canonical.com> (raw)
In-Reply-To: <CAAQKjZNNw4qddo6bE5OY_CahrqDtqkxdO7Pm9RCguXyj9F4cMQ@mail.gmail.com>

Op 09-05-13 09:33, Inki Dae schreef:
> Hi all,
>
> This post introduces a new helper framework based on dma fence. And the
> purpose of this post is to collect other opinions and advices before RFC
> posting.
>
> First of all, this helper framework, called fence helper, is in progress
> yet so might not have enough comments in codes and also might need to be
> more cleaned up. Moreover, we might be missing some parts of the dma fence.
> However, I'd like to say that all things mentioned below has been tested
> with Linux platform and worked well.

> ....
>
> And tutorial for user process.
>         just before cpu access
>                 struct dma_buf_fence *df;
>
>                 df->type = DMA_BUF_ACCESS_READ or DMA_BUF_ACCESS_WRITE;
>                 ioctl(fd, DMA_BUF_GET_FENCE, &df);
>
>         after memset or memcpy
>                 ioctl(fd, DMA_BUF_PUT_FENCE, &df);
NAK.

Userspace doesn't need to trigger fences. It can do a buffer idle wait, and postpone submitting new commands until after it's done using the buffer.
Kernel space doesn't need the root hole you created by giving a dereferencing a pointer passed from userspace.
Your next exercise should be to write a security exploit from the api you created here. It's the only way to learn how to write safe code. Hint: df.ctx = mmap(..);

~Maarten

  reply	other threads:[~2013-05-13  8:00 UTC|newest]

Thread overview: 114+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-09  7:33 Introduce a new helper framework for buffer synchronization Inki Dae
2013-05-13  8:00 ` Maarten Lankhorst [this message]
2013-05-13  8:00   ` Maarten Lankhorst
2013-05-13  8:00   ` Maarten Lankhorst
2013-05-13  9:21   ` Inki Dae
2013-05-13  9:21     ` Inki Dae
2013-05-13  9:21     ` Inki Dae
2013-05-13  9:52     ` Maarten Lankhorst
2013-05-13  9:52       ` Maarten Lankhorst
2013-05-13  9:52       ` Maarten Lankhorst
2013-05-13 11:24   ` Inki Dae
2013-05-13 11:24     ` Inki Dae
2013-05-13 11:24     ` Inki Dae
2013-05-13 11:40     ` Maarten Lankhorst
2013-05-13 11:40       ` Maarten Lankhorst
2013-05-13 11:40       ` Maarten Lankhorst
2013-05-13 19:29     ` Tomasz Figa
2013-05-13 19:29       ` Tomasz Figa
2013-05-13 19:29       ` Tomasz Figa
2013-05-13 12:21   ` Inki Dae
2013-05-13 12:21     ` Inki Dae
2013-05-13 12:21     ` Inki Dae
2013-05-13 13:48     ` Rob Clark
2013-05-13 13:48       ` Rob Clark
2013-05-13 13:48       ` Rob Clark
2013-05-13 17:18       ` Inki Dae
2013-05-13 17:58         ` Rob Clark
2013-05-13 17:58           ` Rob Clark
2013-05-13 17:58           ` Rob Clark
2013-05-14  2:52   ` Inki Dae
2013-05-14  2:52     ` Inki Dae
2013-05-14  2:52     ` Inki Dae
2013-05-14 13:38     ` Rob Clark
2013-05-14 13:38       ` Rob Clark
2013-05-14 13:38       ` Rob Clark
2013-05-15  5:19   ` Inki Dae
2013-05-15  5:19     ` Inki Dae
2013-05-15  5:19     ` Inki Dae
2013-05-15 14:06     ` Rob Clark
2013-05-15 14:06       ` Rob Clark
2013-05-15 14:06       ` Rob Clark
2013-05-17  4:19       ` Daniel Vetter
2013-05-17  4:19         ` Daniel Vetter
2013-05-17  4:19         ` Daniel Vetter
2013-05-18  7:43         ` Inki Dae
2013-05-18  6:47       ` Inki Dae
2013-05-20 21:13         ` Daniel Vetter
2013-05-20 21:13           ` Daniel Vetter
2013-05-20 21:13           ` Daniel Vetter
2013-05-20 21:30           ` Daniel Vetter
2013-05-20 21:30             ` Daniel Vetter
2013-05-20 21:30             ` Daniel Vetter
2013-05-21  7:03   ` Inki Dae
2013-05-21  7:03     ` Inki Dae
2013-05-21  7:03     ` Inki Dae
2013-05-21  7:44     ` Daniel Vetter
2013-05-21  7:44       ` Daniel Vetter
2013-05-21  7:44       ` Daniel Vetter
2013-05-21  9:22   ` Inki Dae
2013-05-21  9:22     ` Inki Dae
2013-05-21  9:22     ` Inki Dae
2013-05-23 11:55     ` Daniel Vetter
2013-05-23 11:55       ` Daniel Vetter
2013-05-23 11:55       ` Daniel Vetter
2013-05-23 13:37   ` Inki Dae
2013-05-23 13:37     ` Inki Dae
2013-05-23 13:37     ` Inki Dae
2013-05-27 10:38   ` Inki Dae
2013-05-27 10:38     ` Inki Dae
2013-05-27 10:38     ` Inki Dae
2013-05-27 15:23     ` Maarten Lankhorst
2013-05-27 15:23       ` Maarten Lankhorst
2013-05-27 15:23       ` Maarten Lankhorst
2013-05-27 15:23       ` Maarten Lankhorst
2013-05-27 15:47     ` Rob Clark
2013-05-27 15:47       ` Rob Clark
2013-05-27 15:47       ` Rob Clark
2013-05-27 16:02       ` Daniel Vetter
2013-05-27 16:02         ` Daniel Vetter
2013-05-27 16:02         ` Daniel Vetter
2013-05-28  2:49   ` Inki Dae
2013-05-28  2:49     ` Inki Dae
2013-05-28  2:49     ` Inki Dae
2013-05-28  7:23     ` Maarten Lankhorst
2013-05-28  7:23       ` Maarten Lankhorst
2013-05-28  7:23       ` Maarten Lankhorst
2013-05-28  7:23       ` Maarten Lankhorst
2013-05-28  3:56   ` Inki Dae
2013-05-28  3:56     ` Inki Dae
2013-05-28  3:56     ` Inki Dae
2013-05-28  3:56     ` Inki Dae
2013-05-28 10:32     ` Daniel Vetter
2013-05-28 10:32       ` Daniel Vetter
2013-05-28 10:32       ` Daniel Vetter
2013-05-28 13:48     ` Rob Clark
2013-05-28 13:48       ` Rob Clark
2013-05-28 13:48       ` Rob Clark
2013-05-28  4:04   ` Inki Dae
2013-05-28  4:04     ` Inki Dae
2013-05-28  4:04     ` Inki Dae
2013-05-28 14:43   ` Inki Dae
2013-05-28 14:43     ` Inki Dae
2013-05-28 14:43     ` Inki Dae
2013-05-28 14:50   ` Inki Dae
2013-05-28 14:50     ` Inki Dae
2013-05-28 14:50     ` Inki Dae
2013-05-28 16:49     ` Daniel Vetter
2013-05-28 16:49       ` Daniel Vetter
2013-05-28 16:49       ` Daniel Vetter
2013-05-29  2:21   ` Inki Dae
2013-05-29  2:21     ` Inki Dae
2013-05-29  2:21     ` Inki Dae
  -- strict thread matches above, loose matches on Subject: below --
2013-06-07  9:02 Introduce a dmabuf sync " Inki Dae
2013-06-07  9:02 ` Inki Dae

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=51909DB4.2060208@canonical.com \
    --to=maarten.lankhorst@canonical.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=inki.dae@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=myungjoo.ham@samsung.com \
    --cc=robdclark@gmail.com \
    --cc=yj44.cho@samsung.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.