linux-kernel - Re: [Linaro-mm-sig] [PATCH RFC] dma-buf/fs Add get_[file|dma_buf]_unless

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKMK7uEZggdDmsnhwU_riNDjia__b010ieVLB4pTb+k82xfYuA@mail.gmail.com>
Date:	Fri, 8 Nov 2013 18:28:39 +0100
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Thomas Hellstrom <thellstrom@...are.com>
Cc:	dri-devel <dri-devel@...ts.freedesktop.org>,
	"linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Linaro-mm-sig] [PATCH RFC] dma-buf/fs Add get_[file|dma_buf]_unless_doomed

On Fri, Nov 8, 2013 at 9:50 AM, Thomas Hellstrom <thellstrom@...are.com> wrote:
> This, however comes with two implications
> 1) Once a DMA-buf is added, it stays alive at least until someone removes
> the gem name of the exporting object, regardless whether there are any
> external users or not. I think this is OK, but unnecessary.

Imo that's actually fairly nice guarantee, since if you have dumb
userspace that always re-does the export/import dance accross a device
the importer can check whether it has the same object already
somewhere.

Without this guarantee we'll end up mapping the same underlying
storage multiple times. btw this is the part where userspace can still
trick the kernel. I have testcases for it, but thus far lacked the
time to implement the fix. It needs a combination of nasty+dumb
userspace though to be a real issue.

> 2) If someone decides to get a new handle from fd, and the gem name has
> already been removed, a new gem name is created for the exporting dma-buf by
> the requested client. This is why I can't do the same. Because of the
> relaxed RCU locking, I can't re-add a name to a TTM base object. Removing it
> is always part of the object destruction sequence.

Yeah, we seem to have a bit a split in how gem handles userspace
handles and the weak references they cause and how ttm does it. ttm
uses kref_get_unless_zero for weak references. Atm gem objects
themselves still need the big mutex, but the only blocker is the mmap
code (actually the has table). My plan (somewhere on my todo list) is
to do the same trick for that weak reference from the mmap offset
lookup structure.

Anyway I just wanted to point out with my original mail that this
problem can be solved in different ways. But I see that the weak ref
approach with a possibly failing get call suits the current ttm design
(and so I guess vmwgfx) a bit better.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/