Re: LOR (drm,acpi)

On Tue, 2004-08-17 at 12:49, M. Warner Losh wrote:
> In message: <41224990.9050008_at_root.org>
>             Nate Lawson <nate_at_root.org> writes:
> : Alex Vasylenko wrote:
> : > The following was reported when leaving X on FreeBSD 5.2-CURRENT #6: Sat Aug 14 09:23:46 EDT 2004:
> : > 
> : > lock order reversal
> : > 1st 0xc18ae064 drm device (drm device) _at_ _at_/dev/drm/drm_irq.h:192
> : > 2nd 0xc0872060 ACPI root bus (ACPI root bus) _at_ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:841
> : > KDB: stack backtrace:
> : > kdb_backtrace(c06c0eb4,c0872060,c086c28e,c086c28e,c086c693) at kdb_backtrace+0x2e
> : > witness_checkorder(c0872060,9,c086c693,349,c06f0bc4) at witness_checkorder+0x6a6
> : > _sx_xlock(c0872060,c086c693,349,c06f0ba0,40) at _sx_xlock+0x7e
> : > acpi_release_resource(c1794680,c1742a00,1,0,c18046c0) at acpi_release_resource+0x2b
> : > bus_generic_release_resource(c1742e00,c1742a00,1,0,c18046c0) at bus_generic_release_resource+0x82
> : > resource_list_release(c1794084,c1801d00,c1742a00,1,0) at resource_list_release+0x84
> : > bus_generic_rl_release_resource(c1801d00,c1742a00,1,0,c18046c0) at bus_generic_rl_release_resource+0x86
> : > bus_generic_release_resource(c1802080,c1742a00,1,0,c18046c0) at bus_generic_release_resource+0x82
> : > resource_list_release(c1794084,c1742e80,c1742a00,1,0) at resource_list_release+0x13b
> : > bus_generic_rl_release_resource(c1742e80,c1742a00,1,0,c18046c0) at bus_generic_rl_release_resource+0x86
> : > bus_release_resource(c1742a00,1,0,c18046c0,c18ae064) at bus_release_resource+0x7f
> : > radeon_irq_uninstall(c18ae000,0,c1d85640,c0,c1d88130) at radeon_irq_uninstall+0x7b
> : > radeon_control(c1ce8b00,80086414,d5de0c58,43,c19a22c0) at radeon_control+0x8d
> : > radeon_ioctl(c1ce8b00,80086414,d5de0c58,43,c19a22c0) at radeon_ioctl+0x1f6
> : > spec_ioctl(d5de0b80,d5de0c2c,c0590fc1,d5de0b80,1) at spec_ioctl+0x1ce
> : > spec_vnoperate(d5de0b80,1,c06c6266,30e,c070f8a0) at spec_vnoperate+0x18
> : > vn_ioctl(c19acd48,80086414,d5de0c58,c1d91480,c19a22c0) at vn_ioctl+0x1c1
> : > ioctl(c19a22c0,d5de0d14,c,437,3) at ioctl+0x4f2
> : > syscall(2840002f,bfbf002f,bfbf002f,8945400,8734000) at syscall+0x2a0
> : > Xint0x80_syscall() at Xint0x80_syscall+0x1f
> : > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2827000f, esp = 0xbfbfeadc, ebp = 0xbfbfeaf8 ---
> : 
> : I can't see how the radeon and acpi locks are interrelated.  Anyone else 
> : have an idea?  The radeon call is just a simple:
> : 
> : bus_release_resource(dev->device, SYS_RES_IRQ, irqrid, dev->irqr);
> : 
> : Perhaps it's not ok to hold a sx lock while calling into the parent 
> : (from acpi.c):
> : 
> : ret = BUS_RELEASE_RESOURCE(device_get_parent(bus), child, type, rid, r);
> 
> The lock is the ACPI root lock vs the drm lock. It appears that there
> are two different code paths, one of which takes the drm lock first,
> the other of which takes the acpi lock first.  My guess is that the
> former is taken in the probe routine, while the latter is taken when
> reconfiguring itself via ioctl at runtime.  One should look there for
> the problems.

I had a hard time getting any review when adding locking to the DRM.  I
suspect that I made the mistake of holding the lock while calling into
other subsystems in some cases.  I could probably get things fixed up
now (having learned more, and having more examples available), but
unfortunately I'm consumed with critical bugfixes for the next X.Org
release and moving to a new house.

-- 
Eric Anholt                                eta_at_lclark.edu          
http://people.freebsd.org/~anholt/         anholt_at_FreeBSD.org