From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (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 9F2763B27D8 for ; Tue, 19 May 2026 19:41:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779219679; cv=none; b=QYenBJu52un5m6yb7IH0YJhR3tE9fkVFM80oJYc22rLrjdYo/KUjWqpfoWCT/sTUqpDwnsAdbkaKhxxgBP4WFSkS1+q/6TZwb/I/HmL8l4g6e6ayQp0XogFduiLnM5hbpjbDdgdrTdTyvyQ9wsCdQYab5nAD1t+NfoWCUtALZy4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779219679; c=relaxed/simple; bh=TDnrD6kQRgUs3gvaonuC0KL07mjcPV/VCBuU7XaSPnM=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=qQqzYR0Nhfea7yiILstufwqX+eGkx06ggSQCfMZBx1XHzrWzzXE7+NbUDouxKSnJCTUpdM4XTpmI+Ergk6HE0HNcP+0ZNF0roHlJEBCSC9aXS9cUsbCU5CcG4+MIB6cMZq4A5LYDXaQSiAa/G+R3kXdxkdleBu/KwP1QtOEhTlg= 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=Jw8VKp5B; arc=none smtp.client-ip=209.85.210.172 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="Jw8VKp5B" Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-83659d38e38so1630509b3a.1 for ; Tue, 19 May 2026 12:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779219678; x=1779824478; 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=5zkIDXNPi64nFlT7okV3y3GeLL/YTDVtR8pIYeqBjA4=; b=Jw8VKp5Ba3aBkupniKEIzGlIKuJTCSMmgEbm5CEK6se/hXtpgxgJzwr9QYwAiPAkwO rFzF4EqWgLYVe4l4/cVqK4ei4VCH8nnRrJPRyEj+oV+itqQe00odNXvQPh6UPUSSz9JN AqJkNLOMtH2ItQeE/c4cej9AFaLqsh8xZFZGHoxCm4AHDb6KzCrqjwKMfQrr7HCkFPdh TLUrMKX6O6Fb34h0baI6h18RSuzDWNq226aLsW/P8JgW11x7FXwfbkf0XWt6r2QwAMZZ 8OoL0N3CNvFvmh0h3HxHMIBsHQKvMWkPQgmLSW9qHJC6+Vav5RTompRmocNKPB7VcIsi WXNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779219678; x=1779824478; 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=5zkIDXNPi64nFlT7okV3y3GeLL/YTDVtR8pIYeqBjA4=; b=OpOa7SZOBluo6BgREP+4+P7veSbo0GrXIY0w+rS+MdZPc9BMhrtlWMMBBd5k5rlklF mao+R0yCODPn9HPfoHu3QIe8oFCJX65Z0CDyhEO/oEuZpYFy+WO0jvL5waCq4qtsUS+m 7IogvXEiWyJGXhRy3Mv82ecPIcLg+2+NRa4HEG3O6Pxwi3WJ8YlRP25/TuH8BmsFfJNb l7GkBq/qhGD2sNERjksu1QU97wOPYzKtfCJOLln8MTrX9WC2TKluxbOHAu1+cTmIRtlh LLsyQv+yMy4HZg6WtnoExPrCOqjIpWAeDYidib1J1RGoRppYi/3Wu0pWogM/j1MCLM0V kaBw== X-Forwarded-Encrypted: i=1; AFNElJ/BGMP9XTCda28VnjEktId474QOvHeaouKfnCSoTZP2xzd427XlL05A4ucmXUK6Q0UGprQ1ppsj+bn0tSA=@vger.kernel.org X-Gm-Message-State: AOJu0YxTO2BeYVaBbDdFY/PZsey/sCS1E/2I7wkz4VoH5UQU80UpVVAe lokwCIc2r2UlFY+u64AkE5c9qpai5w4qmdC8RGq+yv1bepRXBwAP9ycu X-Gm-Gg: Acq92OFUcCuzpiaqiU6sWp3RKEytGSyhWccX6+ZZ9Cqv19fgNss79Vlfdw2G+LTk2Ki XjkfSkhTJ854qhbsVaiNSO9DITDKzYewtZ1d4iJqMZ7tluR1nega/NHTdGBn9kcIXWfe23k5lsA U0WebsEvFUMyunjw3HYzRnsqu2sQLLhgZWG09Neu687xHaL6YtQU6GOxzN+dvUa+4/bc8PowWQT EAnL/fF9I6bv/vbxxD1ghcPwSqf5QSqlNxWy7mf7VyKbfJFywW5vNfQkweLZ0wUcxs0sel3QSxp r81gqxQ9foBTyDoANrglVgL/dy1JTDP7inPRtjrSCSCaHlDthSuLybUVAstFp0vcnbJ1tVwDpU4 iQQIWx0QbI+zzMzmtyp5ODI7eb22R2unJQDIAV7F0IxKSmNE0p9MZG84iVK4kyBp26R2Vb05n2s WaWdI5rk5cRP414dqoqK8LlMdPxMIJYtp0sV/rzEnu6+C1A7Xr X-Received: by 2002:a05:6a00:90aa:b0:829:8c08:d1f4 with SMTP id d2e1a72fcca58-83f33ccd856mr21588284b3a.39.1779219677970; Tue, 19 May 2026 12:41:17 -0700 (PDT) Received: from csl-conti-dell7858.ntu.edu.sg ([155.69.195.57]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-83f19c5ceb3sm18604410b3a.34.2026.05.19.12.41.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 12:41:17 -0700 (PDT) From: Maoyi Xie To: Alex Deucher , =?UTF-8?q?Christian=20K=C3=B6nig?= Cc: David Airlie , Simona Vetter , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: drm/amdgpu: dead empty checks on e->list in ring_mux ib_mark_offset and end_ib? Date: Wed, 20 May 2026 03:41:13 +0800 Message-Id: <20260519194113.2411822-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_last_entry callsites, I noticed two places in drivers/gpu/drm/amd/amdgpu/amdgpu_ring_mux.c where the developer wrote a NULL check for an empty list 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. The two sites are amdgpu_ring_mux_ib_mark_offset() and amdgpu_ring_mux_end_ib() (linux-7.1-rc1, around lines 497 and 530): chunk = list_last_entry(&e->list, struct amdgpu_mux_chunk, entry); if (!chunk) { DRM_ERROR("cannot find chunk!\n"); return; } list_last_entry() returns container_of(&e->list, struct amdgpu_mux_chunk, entry) when e->list is empty, never NULL. The "cannot find chunk!" error path is dead code. With an empty e->list, the fall through pointer aliases &e->list inside struct amdgpu_mux_entry. The writes that follow then corrupt fields of the mux_entry at the corresponding offsets. mark_offset writes cntl_offset, de_offset and ce_offset. end_ib writes end and sync_seq. e->list is empty if a software ring submits an IB mark or IB end before any chunk is queued for that ring. This can happen on a fresh start_ib path, or after end_ib drops the last chunk. A candidate fix is a one liner per site. Switch to list_last_entry_or_null so the existing error path runs. Similar dead empty checks after list_first_entry / list_last_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, please disregard. Otherwise I am happy to send a [PATCH] or to leave the fix to you. Thanks, Maoyi Xie https://maoyixie.com/