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
next prev parent 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.