Re: LOR (drm,acpi)

In message: <1092772654.928.12.camel_at_leguin>
            Eric Anholt <eta_at_lclark.edu> writes:
: 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.

Changes are excellent that this LOR can be ignored...for the moment.
It isn't critical.

Warner