Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752285Ab2JCIxU (ORCPT ); Wed, 3 Oct 2012 04:53:20 -0400 Received: from mail-ie0-f174.google.com ([209.85.223.174]:37618 "EHLO mail-ie0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750960Ab2JCIxQ (ORCPT ); Wed, 3 Oct 2012 04:53:16 -0400 MIME-Version: 1.0 X-Originating-IP: [178.83.130.250] In-Reply-To: <506BF93B.5010805@vmware.com> References: <20120928124148.14366.21063.stgit@patser.local> <5065B0C9.7040209@canonical.com> <5065FDAA.5080103@vmware.com> <50696699.7020009@canonical.com> <506A8DC8.5020706@vmware.com> <20121002080341.GA5679@phenom.ffwll.local> <506BED25.2060804@vmware.com> <506BF93B.5010805@vmware.com> Date: Wed, 3 Oct 2012 10:53:16 +0200 X-Google-Sender-Auth: UE9nyNle0o-az_iB9oH8p4bFW2I Message-ID: Subject: Re: [PATCH 1/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER From: Daniel Vetter To: Thomas Hellstrom Cc: Maarten Lankhorst , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, sumit.semwal@linaro.org, linux-media@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2225 Lines: 51 On Wed, Oct 3, 2012 at 10:37 AM, Thomas Hellstrom wrote: >>> So if I understand you correctly, the reservation changes in TTM are >>> motivated by the >>> fact that otherwise, in the generic reservation code, lockdep can only be >>> annotated for a trylock and not a waiting lock, when it *is* in fact a >>> waiting lock. >>> >>> I'm completely unfamiliar with setting up lockdep annotations, but the >>> only >>> place a >>> deadlock might occur is if the trylock fails and we do a >>> wait_for_unreserve(). >>> Isn't it possible to annotate the call to wait_for_unreserve() just like >>> an >>> interruptible waiting lock >>> (that is always interrupted, but at least any deadlock will be catched?). >> >> Hm, I have to admit that idea hasn't crossed my mind, but it's indeed >> a hole in our current reservation lockdep annotations - since we're >> blocking for the unreserve, other threads could potential block >> waiting on us to release a lock we're holding already, resulting in a >> deadlock. >> >> Since no other locking primitive that I know of has this >> wait_for_unlocked interface, I don't know how we could map this in >> lockdep. One idea is to grab the lock and release it again immediately >> (only in the annotations, not the real lock ofc). But I need to check >> the lockdep code to see whether that doesn't trip it up. > > > I imagine doing the same as mutex_lock_interruptible() does in the > interrupted path should work... It simply calls the unlock lockdep annotation function if it breaks out. So doing a lock/unlock cycle in wait_unreserve should do what we want. And to properly annotate the ttm reserve paths we could just add an unconditional wait_unreserve call at the beginning like you suggested (maybe with #ifdef CONFIG_PROVE_LOCKING in case ppl freak out about the added atomic read in the uncontended case). -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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/