Am 08.05.24 um 13:51 schrieb David Laight:
From: Christian König
Sent: 07 May 2024 15:05
...
I actually have been telling people to (ab)use the epoll behavior to
check if two file descriptors point to the same underlying file when
KCMP isn't available.
In what way?
Something like this:
From: Christian König
> Sent: 07 May 2024 15:05
...
> I actually have been telling people to (ab)use the epoll behavior to
> check if two file descriptors point to the same underlying file when
> KCMP isn't available.
In what way?
You can add both fd to the same epoll fd.
Relying on the implicit
On Tue, May 7, 2024 at 11:17 AM T.J. Mercier wrote:
>
> On Tue, May 7, 2024 at 7:04 AM Christian König
> wrote:
> >
> > Am 07.05.24 um 15:39 schrieb Daniel Vetter:
> > > On Tue, May 07, 2024 at 12:10:07PM +0200, Christian König wrote:
> > >> Am 06.05.24 um 21:04 schrieb T.J. Mercier:
> > >>> On
On Tue, May 7, 2024 at 7:04 AM Christian König wrote:
>
> Am 07.05.24 um 15:39 schrieb Daniel Vetter:
> > On Tue, May 07, 2024 at 12:10:07PM +0200, Christian König wrote:
> >> Am 06.05.24 um 21:04 schrieb T.J. Mercier:
> >>> On Mon, May 6, 2024 at 2:30 AM Charan Teja Kalla
> >>> wrote:
> Hi
Am 07.05.24 um 15:39 schrieb Daniel Vetter:
On Tue, May 07, 2024 at 12:10:07PM +0200, Christian König wrote:
Am 06.05.24 um 21:04 schrieb T.J. Mercier:
On Mon, May 6, 2024 at 2:30 AM Charan Teja Kalla
wrote:
Hi TJ,
Seems I have got answers from [1], where it is agreed upon epoll() is
the
On Tue, May 07, 2024 at 12:10:07PM +0200, Christian König wrote:
> Am 06.05.24 um 21:04 schrieb T.J. Mercier:
> > On Mon, May 6, 2024 at 2:30 AM Charan Teja Kalla
> > wrote:
> > > Hi TJ,
> > >
> > > Seems I have got answers from [1], where it is agreed upon epoll() is
> > > the source of issue.
Am 06.05.24 um 21:04 schrieb T.J. Mercier:
On Mon, May 6, 2024 at 2:30 AM Charan Teja Kalla
wrote:
Hi TJ,
Seems I have got answers from [1], where it is agreed upon epoll() is
the source of issue.
Thanks a lot for the discussion.
[1]
On Mon, May 6, 2024 at 2:30 AM Charan Teja Kalla
wrote:
>
> Hi TJ,
>
> Seems I have got answers from [1], where it is agreed upon epoll() is
> the source of issue.
>
> Thanks a lot for the discussion.
>
> [1] https://lore.kernel.org/lkml/2d631f0615918...@google.com/
>
> Thanks
>
Hi TJ,
Seems I have got answers from [1], where it is agreed upon epoll() is
the source of issue.
Thanks a lot for the discussion.
[1] https://lore.kernel.org/lkml/2d631f0615918...@google.com/
Thanks
Charan
On 5/5/2024 9:50 PM, Charan Teja Kalla wrote:
> Thanks T.J for the reply!!
Thanks T.J for the reply!!
On 5/4/2024 4:43 AM, T.J. Mercier wrote:
> It looks like a similar conclusion about epoll was reached at:
> https://lore.kernel.org/all/a87d7ef8-2c59-4dc5-ba0a-b821d1eff...@amd.com/
>
I am unaware of this discussion. Thanks...
> I agree with Christian that it should
On Fri, May 3, 2024 at 6:40 AM Charan Teja Kalla
wrote:
>
> Thanks Christian/TJ for the inputs!!
>
> On 4/18/2024 12:16 PM, Christian König wrote:
> > As far as I can see the EPOLL holds a reference to the files it
> > contains. So it is perfectly valid to add the file descriptor to EPOLL
> > and
Thanks Christian/TJ for the inputs!!
On 4/18/2024 12:16 PM, Christian König wrote:
> As far as I can see the EPOLL holds a reference to the files it
> contains. So it is perfectly valid to add the file descriptor to EPOLL
> and then close it.
>
> In this case the file won't be closed, but be kept
Am 18.04.24 um 03:33 schrieb zhiguojiang:
在 2024/4/15 19:57, Christian König 写道:
[Some people who received this message don't often get email from
christian.koe...@amd.com. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
Am 15.04.24 um 12:35 schrieb
在 2024/4/15 19:57, Christian König 写道:
[Some people who received this message don't often get email from
christian.koe...@amd.com. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
Am 15.04.24 um 12:35 schrieb zhiguojiang:
在 2024/4/12 14:39, Christian König
Am 15.04.24 um 12:35 schrieb zhiguojiang:
在 2024/4/12 14:39, Christian König 写道:
[Some people who received this message don't often get email from
christian.koe...@amd.com. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
Am 12.04.24 um 08:19 schrieb
在 2024/4/12 14:39, Christian König 写道:
[Some people who received this message don't often get email from
christian.koe...@amd.com. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
Am 12.04.24 um 08:19 schrieb zhiguojiang:
[SNIP]
-> Here task 2220 do epoll
Am 12.04.24 um 08:19 schrieb zhiguojiang:
[SNIP]
-> Here task 2220 do epoll again where internally it will get/put then
start to free twice and lead to final crash.
Here is the basic flow:
1. Thread A install the dma_buf_fd via dma_buf_export, the fd refcount
is 1
2. Thread A add the fd
在 2024/4/3 2:22, T.J. Mercier 写道:
[你通常不会收到来自 tjmerc...@google.com 的电子邮件。请访问
https://aka.ms/LearnAboutSenderIdentification，以了解这一点为什么很重要]
On Tue, Apr 2, 2024 at 1:08 AM Christian König wrote:
Am 02.04.24 um 08:49 schrieb zhiguojiang:
As far as I can see that's not because of the DMA-buf
On Tue, Apr 2, 2024 at 1:08 AM Christian König wrote:
>
> Am 02.04.24 um 08:49 schrieb zhiguojiang:
> >> As far as I can see that's not because of the DMA-buf code, but
> >> because you are somehow using this interface incorrectly.
> >>
> >> When dma_buf_poll() is called it is mandatory for the
Am 02.04.24 um 08:49 schrieb zhiguojiang:
As far as I can see that's not because of the DMA-buf code, but
because you are somehow using this interface incorrectly.
When dma_buf_poll() is called it is mandatory for the caller to hold
a reference to the file descriptor on which the poll
As far as I can see that's not because of the DMA-buf code, but
because you are somehow using this interface incorrectly.
When dma_buf_poll() is called it is mandatory for the caller to hold a
reference to the file descriptor on which the poll operation is executed.
So adding code like "if
Hi T.J.,
What is the most recent kernel version you've seen the bug on?
The latest kernel version of the issue we discovered is kernel-6.1.25, and
kernel-5.15 also reported this issue.
You are closing the dmabuf fd from another thread while it is still
part of the epoll interest list?
Yes,
Am 27.03.24 um 03:29 schrieb Zhiguo Jiang:
The issue is a UAF issue of dmabuf file fd. Throght debugging, we found
that the dmabuf file fd is added to the epoll event listener list, and
when it is released, it is not removed from the epoll list, which leads
to the UAF(Use-After-Free) issue.
As
On Tue, Mar 26, 2024 at 7:29 PM Zhiguo Jiang wrote:
>
> The issue is a UAF issue of dmabuf file fd. Throght debugging, we found
> that the dmabuf file fd is added to the epoll event listener list, and
> when it is released, it is not removed from the epoll list, which leads
> to the
The issue is a UAF issue of dmabuf file fd. Throght debugging, we found
that the dmabuf file fd is added to the epoll event listener list, and
when it is released, it is not removed from the epoll list, which leads
to the UAF(Use-After-Free) issue.
The UAF issue can be solved by checking dmabuf
25 matches
Mail list logo
