[PATCH] ARM: dma-mapping: preallocate DMA-debug hash tables in pure_initcall

[linux@armlinux.org.uk (Russell King - ARM Linux)]

On Tue, Nov 15, 2016 at 11:04:55AM +0100, Marek Szyprowski wrote:
> fs_initcall is definitely too late to initialize DMA-debug hash tables,
> because some drivers might get probed and use DMA mapping framework
> already in core_initcall. Late initialization of DMA-debug results in
> false warning about accessing memory, that was not allocated, like this
> one:

I think using pure_initcall() is not justified here - and if you read
the comments in include/linux/init.h, you're going against its
documented purpose - it says that it exists only to allow variables
that could not be statically initialised to be so.

It's also wrong, because debugfs gets initialised at core_initcall()
time, which happens after pure_initcall(), and dma_debug_init() calls
debugfs functions.

So, I really don't like this patch - it's subsituting one initcall
ordering issue for a different ordering issue.

Core code (which includes arch/arm/mm/) gets linked before drivers, so
moving this to be a core_initcall() would result in it being initialised
before drivers - and it actually makes total sense that this is a core
initcall.

It looks like this is safe from the debugfs perspective as well -
debugfs also gets initialised at core_initcall(), and that is earlier
than arch code in the link order, so debugfs should get initialised
first and then the DMA debug.

So, I'll accept a patch to change this from fs_initcall() to
core_initcall().

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.