From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Hellstrom Subject: Re: [PATCH] drm: Drop modeset locking from crtc init function Date: Mon, 8 Sep 2014 14:57:23 +0200 Message-ID: <540DA7B3.2080601@vmware.com> References: <1409920466-20837-1-git-send-email-daniel.vetter@ffwll.ch> <1410159801-28400-1-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1410159801-28400-1-git-send-email-daniel.vetter@ffwll.ch> Sender: stable-owner@vger.kernel.org To: Daniel Vetter Cc: DRI Development , Rob Clark , maarten.lankhorst@canonical.com, stable@vger.kernel.org, Daniel Vetter List-Id: dri-devel@lists.freedesktop.org On 09/08/2014 09:03 AM, Daniel Vetter wrote: > At driver init no one can access modeset objects and we're > single-threaded. So locking is just cargo-culting here. Worse, with > the new ww mutexes and ww mutex slowpath debugging the mutex_lock > might actually fail, and we don't have the full-blown ww recovery > dance. > > Which then leads to fireworks when we try to unlock the not-locked > crtc lock. > > An audit of all the functions called from here shows that none of them > contain locking checks, so there's also no reason to keep the locking > around just for consistency of caller contexts. Besides that I have > the rule (at least in i915) that such places where we take locks just > to simplify locking checks and not for correctness always require a > comment. I'm not really opposed to any of the patches. It's clear that trylock will work, and it's also clear that locking is not strictly needed, at least not of a lock that has not been published yet. However, I tend to go for the "lock even if it's unnecessary" version for a couple of reasons: a) If that turns out to be impossible or very hard, then something is probably wrong with the design. b) It's good to think of locks where possible as "protecting data" rather than serializing something. With that in mind, and if we in the future were to have tools to automatically check that relevant locks are held while accessing lock-protected stuff, we're in trouble. c) Even if there aren't any functions now that check for relevant locks held, there might be in the future. d) People will probably spend time wondering why locking is done elsewhere but not here. So at least considering d) and b) I'd like to see documentation the other way around: If we avoid taking locks around data accesses that are supposed to be protected by the lock for whatever reason, the reason should be documented. Thanks, Thomas