dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock

In the Linux kernel, the following vulnerability has been resolved:

dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock

__dma_entry_alloc_check_leak() calls into printk -> serial console

output (qcom geni) and grabs port->lock under free_entries_lock

spin lock, which is a reverse locking dependency chain as qcom_geni

IRQ handler can call into dma-debug code and grab free_entries_lock

under port->lock.

Move __dma_entry_alloc_check_leak() call out of free_entries_lock

scope so that we don't acquire serial console's port->lock under it.

Trimmed-down lockdep splat:

The existing dependency chain (in reverse order) is:

-> #2 (free_entries_lock){-.-.}-{2:2}:

_raw_spin_lock_irqsave+0x60/0x80

dma_entry_alloc+0x38/0x110

debug_dma_map_page+0x60/0xf8

dma_map_page_attrs+0x1e0/0x230

dma_map_single_attrs.constprop.0+0x6c/0xc8

geni_se_rx_dma_prep+0x40/0xcc

qcom_geni_serial_isr+0x310/0x510

__handle_irq_event_percpu+0x110/0x244

handle_irq_event_percpu+0x20/0x54

handle_irq_event+0x50/0x88

handle_fasteoi_irq+0xa4/0xcc

handle_irq_desc+0x28/0x40

generic_handle_domain_irq+0x24/0x30

gic_handle_irq+0xc4/0x148

do_interrupt_handler+0xa4/0xb0

el1_interrupt+0x34/0x64

el1h_64_irq_handler+0x18/0x24

el1h_64_irq+0x64/0x68

arch_local_irq_enable+0x4/0x8

____do_softirq+0x18/0x24

...

-> #1 (&port_lock_key){-.-.}-{2:2}:

_raw_spin_lock_irqsave+0x60/0x80

qcom_geni_serial_console_write+0x184/0x1dc

console_flush_all+0x344/0x454

console_unlock+0x94/0xf0

vprintk_emit+0x238/0x24c

vprintk_default+0x3c/0x48

vprintk+0xb4/0xbc

_printk+0x68/0x90

register_console+0x230/0x38c

uart_add_one_port+0x338/0x494

qcom_geni_serial_probe+0x390/0x424

platform_probe+0x70/0xc0

really_probe+0x148/0x280

__driver_probe_device+0xfc/0x114

driver_probe_device+0x44/0x100

__device_attach_driver+0x64/0xdc

bus_for_each_drv+0xb0/0xd8

__device_attach+0xe4/0x140

device_initial_probe+0x1c/0x28

bus_probe_device+0x44/0xb0

device_add+0x538/0x668

of_device_add+0x44/0x50

of_platform_device_create_pdata+0x94/0xc8

of_platform_bus_create+0x270/0x304

of_platform_populate+0xac/0xc4

devm_of_platform_populate+0x60/0xac

geni_se_probe+0x154/0x160

platform_probe+0x70/0xc0

...

-> #0 (console_owner){-...}-{0:0}:

__lock_acquire+0xdf8/0x109c

lock_acquire+0x234/0x284

console_flush_all+0x330/0x454

console_unlock+0x94/0xf0

vprintk_emit+0x238/0x24c

vprintk_default+0x3c/0x48

vprintk+0xb4/0xbc

_printk+0x68/0x90

dma_entry_alloc+0xb4/0x110

debug_dma_map_sg+0xdc/0x2f8

__dma_map_sg_attrs+0xac/0xe4

dma_map_sgtable+0x30/0x4c

get_pages+0x1d4/0x1e4 [msm]

msm_gem_pin_pages_locked+0x38/0xac [msm]

msm_gem_pin_vma_locked+0x58/0x88 [msm]

msm_ioctl_gem_submit+0xde4/0x13ac [msm]

drm_ioctl_kernel+0xe0/0x15c

drm_ioctl+0x2e8/0x3f4

vfs_ioctl+0x30/0x50

...

Chain exists of:

console_owner --> &port_lock_key --> free_entries_lock

Possible unsafe locking scenario:

CPU0 CPU1

---- ----

lock(free_entries_lock);

lock(&port_lock_key);

lock(free_entries_lock);

lock(console_owner);

*** DEADLOCK ***

Call trace:

dump_backtrace+0xb4/0xf0

show_stack+0x20/0x30

dump_stack_lvl+0x60/0x84

dump_stack+0x18/0x24

print_circular_bug+0x1cc/0x234

check_noncircular+0x78/0xac

__lock_acquire+0xdf8/0x109c

lock_acquire+0x234/0x284

console_flush_all+0x330/0x454

consol

---truncated---