From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Whitcroft Subject: Re: [PATCH 0/1] [RFC] DRM locking issues during early open Date: Fri, 20 Apr 2012 11:31:10 +0100 Message-ID: <20120420103110.GD3467@shadowen.org> References: <1334852525-14950-1-git-send-email-apw@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Dave Airlie Cc: David Airlie , dri-devel@lists.freedesktop.org, Jesse Barnes , Bryce Harrington , linux-kernel@vger.kernel.org List-Id: dri-devel@lists.freedesktop.org On Fri, Apr 20, 2012 at 10:40:35AM +0100, Dave Airlie wrote: > I've just revisited this, maybe I'm going insane but why does > drm_global_mutex not stop this? > > drm_get_pci_dev takes drm_global_mutex before calling drm_fill_in_dev > and drm_get_minor. > > Now the fops should be pointing at stub_open at this point, as we > won't have switched to the per device fops yet, > and one of the first things drm_stub_open does is take the > drm_global_mutex before doing the idr lookup. > > So is the problem opening some sysfs or proc file early? I may be reading things wrong but the initialisation does indeed hold drm_global_mutex, but and back when this first occured we would have been using kernel_lock() which was at least partially reentrant right? Anyhow, I will go back to the reporter and try and get a proper reproduce by, there is no point in fixing something which is something else. -apw