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] [day] [month] [year] [list]

Message-ID: <52834216.2020409@vmware.com>
Date:	Wed, 13 Nov 2013 10:10:46 +0100
From:	Thomas Hellstrom <thellstrom@...are.com>
To:	Daniel Vetter <daniel.vetter@...ll.ch>
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 11/08/2013 06:28 PM, Daniel Vetter wrote:
> 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.

Yes. But anyway, I'll keep that get_dma_buf_unless_doomed() in local 
code until someone else finds it useful.
The fs guys had issues with it as well.

Thanks,
Thomas



> Cheers, Daniel
--
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/