linux-kernel - Re: kobject: delayed kobject release: help find buggy drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20130906075937.GM6617@n2100.arm.linux.org.uk>
Date:	Fri, 6 Sep 2013 08:59:37 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Dave Jones <davej@...hat.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kobject: delayed kobject release: help find buggy drivers

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.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/