On Tue, 08 Feb 2011 08:52:52 +1000, Dave Airlie airlied@redhat.com wrote:
On Sun, 2011-02-06 at 19:24 +0200, adam zeira wrote:
is this a problem? before trying to submit a solution I wanted to make sure with the experts
it seems open_count isn't locked and can cause problems
and if it is a problem, and needs to be solved, should locking be done or is it better implemented with the (as I understand standard) kref?
Ickle?
1a72d65d6291ec248cbc5f05df2487edd714aba6 was your doing and I'm not entirely sure you actually checked all the paths looking back.
Would this clarify matters? Perhaps there is some spare annotation that could be used here as well?
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index 2ec7d48..5b4ca5b 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -125,6 +125,13 @@ int drm_open(struct inode *inode, struct file *filp) struct drm_minor *minor; int retcode = 0;
+ /* Typically we are called (via the driver) from drm_stub_open() + * as their own fops->open and so already hold the global mutex. + * Enforce this. + */ + if (WARN_ON(!mutex_is_locked(&drm_global_mutex))) + return -EINVAL; + minor = idr_find(&drm_minors_idr, minor_id); if (!minor) return -ENODEV;