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
| ||
|
Message-ID: <53CE84AA.9030703@amd.com> Date: Tue, 22 Jul 2014 17:35:06 +0200 From: Christian König <christian.koenig@....com> To: Daniel Vetter <daniel.vetter@...ll.ch>, Christian König <deathsimple@...afone.de> CC: Dave Airlie <airlied@...il.com>, Maarten Lankhorst <maarten.lankhorst@...onical.com>, Thomas Hellstrom <thellstrom@...are.com>, nouveau <nouveau@...ts.freedesktop.org>, LKML <linux-kernel@...r.kernel.org>, dri-devel <dri-devel@...ts.freedesktop.org>, Ben Skeggs <bskeggs@...hat.com>, "Deucher, Alexander" <alexander.deucher@....com> Subject: Re: [Nouveau] [PATCH 09/17] drm/radeon: use common fence implementation for fences Am 22.07.2014 17:17, schrieb Daniel Vetter: > On Tue, Jul 22, 2014 at 3:45 PM, Christian König > <deathsimple@...afone.de> wrote: >>> Would that be something you can agree to? >> >> No, the whole enable_signaling stuff should go away. No callback from the >> driver into the fence code, only the other way around. >> >> fence->signaled as well as fence->wait should become mandatory and only >> called from process context without holding any locks, neither atomic nor >> any mutex/semaphore (rcu might be ok). > So for the enable_signaling, that's optional already. It's only for > drivers that don't want to keep interrupts enabled all the time. You > can opt out of that easily. > > Wrt holding no locks at all while calling into any fence functions, > that's just not going to work out. The point here is to make different > drivers work together and we can rework all the ttm and i915 code to > work locklessly in all cases where they need to wait for someone to > complete rendering. Or at least I don't think that's feasible. So if > you insist that no one might call into radeon code then we simply need > to exclude radeon from participating in any shared fencing. But that's > a bit pointless. > >>> Like I've said I think restricting the insanity other people are willing >>> to live with just because you don't like it isn't right. But it is >>> certainly right for you to insist on not being forced into any such >>> design. I think the above would achieve this. >> >> I don't think so. If it's just me I would say that I'm just to cautious and >> the idea is still save to apply to the whole kernel. >> >> But since Dave, Jerome and Ben seems to have similar concerns I think we >> need to agree to a minimum and save interface for all drivers. > Well I haven't yet seen a proposal that actually works. How about this: Drivers exporting fences need to provide a fence->signaled and a fence->wait function, everything else like fence->enable_signaling or calling fence_signaled() from the driver is optional. Drivers wanting to use exported fences don't call fence->signaled or fence->wait in atomic or interrupt context, and not with holding any global locking primitives (like mmap_sem etc...). Holding locking primitives local to the driver is ok, as long as they don't conflict with anything possible used by their own fence implementation. Christian. > From an intel > pov I don't care that much since we don't care about desktop prime, so > if radeon/nouveau don't want to do that, meh. Imo the design as-is is > fairly sound, and as simple as it can get given the requirements. I > haven't heard an argument convincing me otherwise, so I guess we > won't have prime support on linux that actually works, ever. > -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/
Powered by blists - more mailing lists