haven: hh_msgq: Use GFP_ATOMIC allocations in hh_msgq_alloc_entry()

Commit 81d6b86bd96e ("haven: hh_msgq: Disallow multiple
registrations with same label") makes the entire gh_msgq_alloc_entry()
function a critical section by calling it with the gh_msgq_cap_list_lock
spinlock held. It also changed the allocation flags of one of the three
memory allocation operations from GFP_KERNEL to GFP_ATOMIC for this
reason, leaving the other two intact. This sometimes leads to the
following:
[    0.052850][    T1] BUG: sleeping function called from invalid context at mm/slab.h:557
[    0.052852][    T1] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
[    0.052854][    T1] Preemption disabled at:
[    0.052861][    T1] [<ffffffc010578698>] gh_msgq_populate_cap_info+0x3c/0x26c
[    0.052864][    T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.43-debug-04611-g00783572e88c-dirty #1
[    0.052866][    T1] Hardware name: Qualcomm Technologies, Inc. Waipio SVM MTP (DT)
[    0.052868][    T1] Call trace:
[    0.052873][    T1]  dump_backtrace+0x0/0x20c
[    0.052875][    T1]  show_stack+0x18/0x24
[    0.052880][    T1]  dump_stack_lvl+0xbc/0x134
[    0.052883][    T1]  ___might_sleep+0x16c/0x1c0
[    0.052884][    T1]  __might_sleep+0x50/0x88
[    0.052887][    T1]  __kmalloc_track_caller+0x6c/0x388
[    0.052891][    T1]  kvasprintf+0xa8/0x134
[    0.052892][    T1]  kasprintf+0x54/0x7c
[    0.052894][    T1]  hh_msgq_alloc_entry+0x98/0x128
[    0.052896][    T1]  hh_msgq_populate_cap_info+0x74/0x26c
[    0.052897][    T1]  hh_msgq_probe_direction+0x78/0xf0
[    0.052899][    T1]  hh_msgq_probe+0x4c/0xdc
[    0.052901][    T1]  hh_rm_drv_probe+0x34/0x310
[    0.052904][    T1]  platform_drv_probe+0x3c/0x9c
[    0.052906][    T1]  really_probe+0x11c/0x4c8
[    0.052909][    T1]  driver_probe_device+0x84/0xec
[    0.052911][    T1]  device_driver_attach+0x4c/0x70
[    0.052913][    T1] __driver_attach.llvm.3781602661191075997+0x40/0x154
[    0.052915][    T1]  bus_for_each_dev+0x7c/0xc8
[    0.052917][    T1]  bus_add_driver+0x110/0x20c
[    0.052919][    T1]  driver_register+0x64/0x104
[    0.052921][    T1]  __platform_driver_register+0x44/0x50
[    0.052926][    T1] __initstub__kmod_gh_rm_drv__334_1315_gh_rm_driver_init6+0x1c/0x28
[    0.052928][    T1]  do_one_initcall+0x50/0x29c
[    0.052931][    T1]  do_initcall_level+0xa4/0x16c
[    0.052933][    T1]  do_initcalls+0x60/0xa0
[    0.052934][    T1]  do_basic_setup+0x20/0x2c
[    0.052936][    T1]  kernel_init_freeable+0x8c/0xdc
[    0.052939][    T1]  kernel_init+0x14/0x110
[    0.052941][    T1]  ret_from_fork+0x10/0x30
Even though the error signature says "BUG:" it isn't really a kernel
panic. It only dumps the stack and then carries on, courtesy
CONFIG_DEBUG_ATOMIC_SLEEP.
Change the remaining two memory allocation operations to use GFP_ATOMIC
as well and thereby fix the appearance of this error message.

Change-Id: If7f91e67541b1e925313eeb96f58cc4e2280dba2
Signed-off-by: Ashok Gummadidala <agumma@codeaurora.org>