Re: kobject: delayed kobject release: help find buggy drivers

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Thu, Sep 05, 2013 at 09:11:37PM -0400, Dave Jones wrote:
> As discussed on irc, with this updated patch it hangs *really* early in boot. 
> 
> With earlyprintk=vga I can see some of the trace..
> 
> kobject_init
> firmware_map_add_entry
> firmware_map_add_early
> e820_reserve_resources
> setup_arch
> start_kernel
> x86_64_start_reservations
> x86_64_start_kernel
> 
> <RIP> kmem_cache_alloc_trace

Argh, so kobject_init() gets used before the memory allocators are setup.
This is starting to look like we can't separate the delayed_work from
the kobject struct to provide a layer of isolation.  I'm running out of
ideas here.

Do we have a way to tell if the memory allocators have been initialised?
I can't see anything that would, with the exception that the scheduler
initialisation requires memory allocators are up and running, and it has
its own scheduler_running state, but that's buried in the scheduler.

system_state is useless for this because it gets set to the running state
after device initialisation, and just before we drop into userspace.

We could go back to doing the allocation at kobject_add() time, that seemed
to be marginally successful for you - but I'm fairly certain it won't get
all kobjects that are later released (because its possible to init a
kobject and then put it once to discard it.)