oops in i915_driver_irq_handler

[Matthew Bullock <matthew.bullock@tadpole.com>]

Hi,

I've just had an oops in i915_driver_irq_handler. It's a NULL pointer 
dereference at line 1179 in i915_irq.c (the bit that's about to call
READ_BREADCRUMB().

This is on 2.6.38. It's a dual core GM45 machine running a totally 
custom EGL application running directly on KMS with no X.

The system has no local storage so I haven't captured the oops output (I 
have a bad photo if you really want it) but it's very clear where it fails.

The code is:
                 if (dev->primary->master) {
                         master_priv = dev->primary->master->driver_priv;
                         if (master_priv->sarea_priv)
                                 master_priv->sarea_priv->last_dispatch =
                                         READ_BREADCRUMB(dev_priv);
                 }

dev->primary->master is not NULL.
dev->primary->master->driver_priv is NULL.
So reading sarea_priv triggers the oops.

The oops occurred sometime overnight and the owner of the machine is not 
entirely sure what state it was left in. However the most likely is that 
it was repeatedly restarting the application every 30 seconds so would 
have been opening and closing the drm device.

 From very briefly looking at the code it seems that the path through 
drm_release that sets driver_priv to NULL has no locking against the 
irq. Seems to me that the irq handler should also be checking 
driver_priv for NULL to cover this case? Or should the ordering be 
changed higher up so that master gets set to NULL before freeing the 
driver_priv?

I have this same code running on quite a few (20+) identical machines 
and haven't seen this before so I doubt I can reproduce it...

Matthew