linux-kernel - Re: [PATCH] dma-buf: Use EXPORT

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]

Date:	Thu, 19 Jan 2012 07:26:23 +0000
From:	Dave Airlie <airlied@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	"Semwal, Sumit" <sumit.semwal@...com>,
	Robert Morell <rmorell@...dia.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	linux-kernel@...r.kernel.org, sumit.semwal@...aro.org,
	airlied@...ux.ie, dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

On Wed, Jan 18, 2012 at 12:23 PM, Mauro Carvalho Chehab
<mchehab@...hat.com> wrote:
> Em 18-01-2012 10:14, Arnd Bergmann escreveu:
>> On Wednesday 18 January 2012, Semwal, Sumit wrote:
>>> On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell <rmorell@...dia.com> wrote:
>>>> EXPORT_SYMBOL_GPL is intended to be used for "an internal implementation
>>>> issue, and not really an interface".  The dma-buf infrastructure is
>>>> explicitly intended as an interface between modules/drivers, so it
>>>> should use EXPORT_SYMBOL instead.
>>>
>>> + Konrad, Arnd, Mauro: there were strong objections on using
>>> EXPORT_SYMBOL in place of EXPORT_SYMBOL_GPL by all 3 of them; I
>>> suggest we first arrive at a consensus before merging this patch.
>>
>> We discussed this before. The reason for using EXPORT_SYMBOL_GPL here is
>> that the interface is low-level and that it's meant to be used by
>> subsystems that export user-level interface based on that and come
>> with their own device driver interface, such as V4L or DRM.
>>
>> While there is an eternal debate over whether there should or should
>> not be out of tree device drivers, I think there is very little to gain
>> by allowing dma_buf to be used by out of tree *subsystems*.
>> Further, a device driver that tries to use the interface but sits outside
>> of the regular subsystems is a bad technical choice and we should not
>> encourage those either.
>>
>> NAK
>
> I fully agree with Arnd.
>
> A bug on a driver using such low-level interface could cause side effects
> at the wrong places. In order to handle such bugs, the developers and the
> maintainers of both subsystems need to see the source code of the entire
> pipeline, with is not possible if is there any non-GPL'd driver.

Just as an aside you shouldn't be debugging tainted kernels anyways.

The thing is if we don't provide the interface that is known working
for this, then we end up requiring the nvidia binary to jump through
hoops which is more likely to make thing unstable.

At that point I'd start to seriously consider whether drm needs
dma-buf since one of the things I will get pressure to share buffers
with is for optimus. The pressure isn't from nvidia, but from users
and customers.

I'd like to at least remove debuggabilty from the argument, that is
why we have tainting, if you ignore taint + lsmod output then
export_symbol won't matter.

Dave.

>
> NAK
>
> Mauro.
> --
> 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/
--
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/