mm/memblock: disable local irqs while late memblock changes

mm/memblock: disable local irqs while late memblock changes

There is a possibility of deadlock while doing late
memblock configuration as only preemption is disabled and
irq can be serviced while seqlock is held and in turn
memblock_is_memory can be called from irq context thus
trying to claim seqlock again. Following call stack was
observed,

[<c02136d4>] memblock_search+0x1c
[<c021487c>] memblock_is_memory+0x10
[<c01e4684>] free_kmem_pages+0x44
[<c0121c04>] free_task+0x28
[<c0178b30>] rcu_process_callbacks+0x488
[<c0127e30>] __do_softirq+0x150
[<c0128284>] irq_exit+0x84
[<c010c11c>] handle_IPI+0x12c
[<c0100588>] gic_handle_irq+0x70
[<c0e9efc0>] __irq_svc+0x40
[<c0214a8c>] memblock_region_resize_late_end+0xc
[<c057010c>] removed_alloc+0x110
[<c04ab2c4>] pil_boot+0x2b0
[<c04b7700>] __subsystem_get+0xe0
[<c04b79cc>] subsys_device_open+0x74
[<c0229f20>] chrdev_open+0x12c
[<c02246e4>] do_dentry_open+0x280
[<c0232698>] do_last+0x9a4
[<c0232b8c>] path_openat+0x23c
[<c0233bf0>] do_filp_open+0x2c

Fix it by disabling irqs during late memblock
configuration. It is a one time operation which changes
memblock related data structures and doesn't carry
performance impact.

CRs-Fixed: 1003890
Change-Id: I3ff1894f0c80580920b1971cda357915665b5054
Signed-off-by: Shiraz Hashim <shashim@codeaurora.org>