On Sun, 1 Dec 2002, Adam Belay wrote:
> It caused an oops? I'll bet the pnp layer got confused by it. I'll add
> some busy flags to prevent drivers from calling this when the device is
> being used by the driver through the conventional driver-model style.
> Thanks for pointing this out.
Here is what the stack looked like;
EIP is at kfree+0xcd/0xe0
[<c024228d>] pnp_free_ids+0x1d/0x30
[<c0241beb>] pnp_release_device+0x1b/0x30
[<c02555a5>] device_release+0x15/0x20
[<c02390e3>] kobject_cleanup+0x73/0x80
[<c0241dac>] pnp_remove_device+0x1c/0xcd
We were releasing an already freed block of memory (this one was slab
poisoned).
> I see now. The problem is that when the remove function is called, the pnp
> layer expects the device's resources to be freed and not in use. I should
> add some checks for this as well. The pnp layer will disable the device
> and this could cause big problems if the driver is used in between the time
> of the ALSA remove code path and this driver removal. Furthermore, if there
> is more than one sound card and the driver-model wants to remove one, a
> problem would occur. Perhaps this aspect of ALSA needs to be changed.
> Any ideas?
Hmm i thought ->remove was per device or do you iterate internally over
all registered driver devices? Thats why i originally did the
pnp_remove_device in the driver's card removal path. How about only
disabling registered devices on final driver unregister?
As an aside where does this fit in with the whole pci_dev business?
Cheers,
Zwane
-- function.linuxpower.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:11 EST