CVE-2023-52516: 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 consoleoutput (qcom geni) and grabs port->lock under free_entries_lockspin lock, which is a reverse locking dependency chain as qcom_geniIRQ handler can call into dma-debug code and grab free_entries_lockunder port->lock.Move __dma_entry_alloc_check_leak() call out of free_entries_lockscope 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---