From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 862FF38F95B for ; Tue, 19 May 2026 19:04:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779217491; cv=none; b=tMMEwoZdbg+mpT9ZXvQQGmd5GE6XtSDl2KQWRc1vefFz7tRUQaIqD+h01eqSOzWekUNI1mr3Wl2frw0nIVvAbNp1IIp/CiTRwM+oCkCy99Ya7BLV/BYBeDlP83nTAJkel+J+e9as08d89pjceglmdVdy2Hm3hzWuT1Fl1V/EMCA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779217491; c=relaxed/simple; bh=ClGiD7Br2FRvKa7NIj3NIRbaGiCBSYKP0ikEdtKtThA=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=dE+VmV/duM9AjQM0ETBb6QQHfiIeDG805nV/JcRe3i2utXMo7iM+qoUJd4O1q55bOMfzzPQgugjZHZPEdomBlVb7skgT6m9iG621SmDfQ/BBlvD66WE/Guebp52uECK6AS3Fw4/5CxPh5cxxJ7kyNuZlvcWJMPRjgaLSaaOeEcA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=bet8Qz6m; arc=none smtp.client-ip=209.85.215.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="bet8Qz6m" Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-c80227b1f6cso1521521a12.1 for ; Tue, 19 May 2026 12:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779217486; x=1779822286; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=lt4E8/DsuDzGzbJ8IpIkgEnn/bBtXFj50NFYiiBCCoc=; b=bet8Qz6mLJZkQhRiQ6ClI5X5+FaACWevEv8HK96i3nHF1yAGmEcw7OlJaSwhIj+DCA N64NaZIxluUa2q3k9Q5AnHI6CFbzSmQHstj1JLaViJF5Yc1tR+obQYealfOVxxTLWM4u /wfF1MP83Qr7vOo+P1OvYyiv5tj1ozdN+dVdcaHB64cPxwiPqKS/j3Z7hDZnoMXz1RYW UzIcBaZ5+jLVjHpKsQWHtqOeXyuk4SvQQP+MxrocRg3tyY3ryVFtwZjh3lf8BiOnoKim iGj6vR4UijHyyyNk5lTZjOo3dxFC+P8ftmTRHIOAdofVFISb3Kg44SrM8RG4yUgMzbbr 54Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779217486; x=1779822286; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lt4E8/DsuDzGzbJ8IpIkgEnn/bBtXFj50NFYiiBCCoc=; b=SqLJDbnhYnCePERXaQFnpj+t/wH/0pJrXvMkwfvq0dbeTogWpgwZZl72cWGdZpXU5M Eid4ZhwmLcIivpqkWb9ELPbB/Hdz2K2rrJ7uqUulnG9Zz/g8piniXf6m9T8bEextafFG huSxqy6EGFY2TpwMaKAD5cgEaoDAvt5UH62MhcvF6P43VLnoSkWFfmRPwnL5zN3j7wiZ wE2nTMGNn2uRqXMADRj0+2BCsgyO+sfRFwlpu/8vw1ntROMMS1aTQHnQzurR6ZY+Et4p HrgH2bPHq1LVYFCxN+y208Ha5aQnZSwzP4AbTFfvfBBaHN5HDXQi7B/bfT3FMohAweg/ p0ww== X-Forwarded-Encrypted: i=1; AFNElJ+OfGQKKYZElyKmcHSsHwWr8iilaz8I3ugKuiE+jAl5I7wfPnWaZQ/xvHV4iGufdXCOZNcqaUDS5rZ5C6s=@vger.kernel.org X-Gm-Message-State: AOJu0Yw0lVRwzhq0g4i0NtKHioXYVGv+gDHDTvQUoeC02QaOWII8aZRP 39wDwg9vv4VIjCFORGFEZShfXP/WVnJOxmvmVEkrgeTpis3Jy/91ctr2DpXjDw== X-Gm-Gg: Acq92OEuItghOTmb1TQjyM3gCVjMzXl0sfilvn+WNyLA84w4GqGUYPDPQBae6G6Cd4F 2RGj/bW1vJGpRYAVHSv07vLEPNOSdG4CqGeTWS5GCPO4HzVaHR7yoI5/TN0zDdfeFMiGZqzsYwi oVZyUnzjecLHv+QprRAmoze+ianOWzD8RPxFLJ0aVvxQVSv5uk6ibOwL8lCsB12ZZ+U7eYkb8X6 jCz3gSUJUoOohRb90I40Kd1CRkqe3aMUNHNM7wSQnc4eA/VAedAFO04Rtk4mpqg+JpgrA2ciXhY jSV4oJJs0/aguRj73fmS+du7lpAry0NCXV/UG88Sz8GNhJmlnVItKpXAmjmwLvaRWibR1VnJMj5 HJZdU+NGiudDalHq+iOXhWeOPVO1S+H7XLA+lEgLQbcxzzYtOgo+zRE52hNTpKWDUTRifn6dHoc cy54zcsQus0y+rK2FC93AgRUesvI09JxSEKubuXqFhxsJBbZezsTSzML+Aus0= X-Received: by 2002:a05:6a20:9153:b0:3a3:171f:6b23 with SMTP id adf61e73a8af0-3b22e14de52mr23831258637.0.1779217486164; Tue, 19 May 2026 12:04:46 -0700 (PDT) Received: from csl-conti-dell7858.ntu.edu.sg ([155.69.195.57]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c82bb07b007sm17317550a12.11.2026.05.19.12.04.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 12:04:45 -0700 (PDT) From: Maoyi Xie To: Vinod Koul Cc: dmaengine@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: dmaengine: dead empty checks in mpc512x and rz-dmac descriptor pickup? Date: Wed, 20 May 2026 03:04:42 +0800 Message-Id: <20260519190442.2382986-1-maoyixie.tju@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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/