On Thu, Feb 14, 2013 at 11:22 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> These functions will return -EDEADLK instead of -EAGAIN if >> reservation_id is the same as the reservation_id that's attempted to >> lock the mutex with, since in that case you presumably attempted to >> lock the same lock twice. > > Since the user always has to check the return value, would it be > possible to provide only the interruptible kind of this function > but not the non-interruptible one? In general, interruptible locks > are obviously harder to use, but they are much user friendlier when > something goes wrong. At least in drm/i915 we only use _interruptible locking on the command-submission ioctls for all locks which could be held while waiting for the gpu. We need unwind paths and ioctl restarting anyway to bail out on catastrophic events like gpu hangs, so signal interrupt handling comes for free. Otoh in the modeset code we generally don't bother with that, since unwinding a modeset sequence mid-way is something you don't want to do really if your sanity is dear to you. But we also never need mutli-object reservations in the modeset code, neither can I imagine a future need for it. So from my side we could drop the non-interruptible interface. But I have not checked whether dropping this would complicate the ttm conversion. >> mutex_reserve_lock_slow and mutex_reserve_lock_intr_slow: >> Similar to mutex_reserve_lock, except it won't backoff with -EAGAIN. >> This is useful when mutex_reserve_lock failed with -EAGAIN, and you >> unreserved all buffers so no deadlock can occur. > > Are these meant to be used a lot? If not, maybe prefix them with __mutex_ > instead of mutex_. If you detect an inversion in a multi-buffer reservation you have to drop all locks and call these functions on the buffer which failed (that's the contention point, hence it's the right lock to sleep on). So every place using ticket locks will also call the above slowpath functions by necessity. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
