dmaengine: dead empty checks in mpc512x and rz-dmac descriptor pickup?

[Maoyi Xie <maoyixie.tju@gmail.com>]

Hi all,

While auditing list_first_entry callsites, I noticed two places in
drivers/dma where the developer wrote a NULL check for an empty
list case but used the unsafe API. The check is dead code. I
would appreciate it if you could take a look and let me know
whether these are worth fixing.

Site 1, drivers/dma/mpc512x_dma.c mpc_dma_prep_slave_sg()
(linux-7.1-rc1, around line 709):

    mdesc = list_first_entry(&mchan->free,
                                    struct mpc_dma_desc, node);
    if (!mdesc) {
            spin_unlock_irqrestore(&mchan->lock, iflags);
            mpc_dma_process_completed(mdma);
            return NULL;
    }

    list_del(&mdesc->node);

list_first_entry() returns container_of(&mchan->free, struct
mpc_dma_desc, node) when the free list is empty, never NULL. The
recovery path (drop lock, scan completed list, return NULL) is
dead code. With an empty free list, the fall through pointer
aliases &mchan->free. The subsequent list_del() then corrupts
the head's next and prev links.

Site 2, drivers/dma/sh/rz-dmac.c rz_dmac_chan_get_residue()
(linux-7.1-rc1, around line 726):

    current_desc = list_first_entry(&channel->ld_active,
                                    struct rz_dmac_desc, node);
    if (!current_desc)
            return 0;

Same shape. ld_active can be empty while a residue query races
with descriptor completion. The `return 0` shortcut never runs,
and current_desc is then dereferenced for status processing.

A candidate fix in both cases is a one liner. Switch the API to
list_first_entry_or_null so the existing NULL guard runs as the
author intended.

Similar dead empty checks after list_first_entry have been
cleaned up in the same shape, for example commit fbb8bc408027
(net: qed: Remove redundant NULL checks after list_first_entry),
commit c708d3fad421 (crypto: atmel: use list_first_entry_or_null
to simplify find_dev) and commit 10379171f346 (ksmbd: use
list_first_entry_or_null for opinfo_get_list). The qed commit
message describes the exact shape we observe here. These two
sites appear to be missed by those cleanups.

If this is intentional or already known for either site, please
disregard. Otherwise I am happy to send a [PATCH] series or to
leave the fix to you.

Thanks,
Maoyi Xie
https://maoyixie.com/