From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) (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 1D1103A0E93 for ; Tue, 19 May 2026 20:28:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779222496; cv=none; b=nW5E9/nHsY+6BdV7tC6ZS6GA66v2N1M2U2TW0z3pIv1xD31pnm1Xt0osJcGEuqb8XFpeURWBK0bPZBRvLn6b+Pc6E/uz9qCDXEqdREBizuHdQn/yQVCaniF13YVZ2yyZ8EI7yqimZY6KqZz1XLXCldJzyS5HKWM8tTKwc1ARDbM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779222496; c=relaxed/simple; bh=h+opL5sjrXApX9lhRQJRTMACzgnfsVUGzcENRpKJzAc=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=j6NdG3GuO0els7uLQxOEBnekVOxNBLfqabXveBuzVImU1lb6U0eEJqQov6tZS9Qq3byzDicf6FLigRM+aBhov+EhxMXnx+4JIPnB9i+9vwsiMZJOMwZyRbPI3Vr1gPKiVlNWKedkvI7GnjBHQZWBO4SttsGkO16xIDJuGY/EmrQ= 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=RifF6gnP; arc=none smtp.client-ip=209.85.215.178 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="RifF6gnP" Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-c70fb6aa323so1696040a12.3 for ; Tue, 19 May 2026 13:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779222494; x=1779827294; 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=A8GywxHlqCZI7WpNixXQesnEQTxELbXrTJTNO5sDDRs=; b=RifF6gnPi2Y/y8OOPWYOITGNNxQcAl6RWmKIbEYJrOuorcV4sahjfgHc0bpd8yX81/ lANLKHawpRCiYx/cK8m8gGm44q4YT0nHmRCJNQ31AXoRbhc16+OVxk+RwIKnrV7OprN2 PbSec+/vpu31nL9Som0L4EXmeL220I0GilUaphzBiQdhOdUoDipK4WbWCosXDBVk7IYu ibnQQQ61dWhUwEGpV5SngJPGbIDZ6+oq89DCsSYfDRKQh7z7DFH8XsQWAtX19u1K+ZBv FcL2jM6lVZRYwLi5ZMsNthoZfECAEEr/EwiACeLYIsqizPBHrbfnkNiyAqvBfi/BElG5 1Bbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779222494; x=1779827294; 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=A8GywxHlqCZI7WpNixXQesnEQTxELbXrTJTNO5sDDRs=; b=TUitRbtrV6xcVDf6V8wMuEjuPsub1uSPMAdRMAjhWqnHdtZFQajQcwloyTmjsAtdXS TshEstBPpDjqSDCNsTL2uLVZL6Dh2c5asede2tmEbk9gpjUzndGrSRa18D39/xz00e3u JnDNWq0zqs0usNMVf+kIX00SFJKPltGhcqCssF2Nxz0g6uIz6SWOKgHUVFkct8K4pU6T SxDVBsgJros+UZPTBUZVCt22roUckYUv1vhpMZKdcVp8zQlVNn0yrozzow//F6K40icM Ty/YTBROquqge1NkBAiptkP7vD4QQO2KqhPyLb9Jw4H/dwfLmukkPwyaLvxNjXaxo+MR Xweg== X-Forwarded-Encrypted: i=1; AFNElJ9QYAKAZGScrPeXaIkXowJLDFYZbsQeuTLUi21MMFCpr78IKH8u/Yh4HiIkGj0E0O/hjH3YJvsTMTrgRzA=@vger.kernel.org X-Gm-Message-State: AOJu0YyLXydm4Nw23hYfQgfpEUk/TlMerSoksqe/9EgR3yAw4sGyDcx6 P3kUuC8PYakmbV6QQqunp8NetPR8x8tK8v5WZ79zco55o6DKTp/BwOIZ X-Gm-Gg: Acq92OFH+xYpgqru6rkPRIr8wO+tAnypXMyKmZg2Fqyqe4CLzF4Y0XSQHDjW884AEfI ZfldD721n7iMaueFd2yJtfULu3jtWv0Jd6Yw9H9hm2MhwGtQeAYxajzhLZRS6dXYTwpWILmkvfF 7mQ43Ems6amD+/vSyXkqO5T2IxmXacxxM8qs3ucWkTNikK+OvM4hZE4zwQYPQ8sCbJNAQozAiEs fdiMhitVSj0omeTQwit7m9dBQCh4+VdKR5jIzpAD+b8GmfxSrqnTUWv+6uicvyNeTVu6lVvgiGC CnpJlvSGghJqZp3ezKcr+draaMLv5/B7Ku/axaYRWtEvJKpU9PePk+0c5BmYDtIRxqnAcjbZjTl dXjI48WJ/WWehmCn7uvjX6rvi7b+cxBM78IqrIq60WnMUC4/GylrwwfBJKBSy+l4ajK57Sf4aeP S5yEGeihOLy5oPbc2GIVP/+xjrwZINZIxPJWaYKVRY3RrGnhGxyMyLWNERyK4= X-Received: by 2002:a05:6a21:600d:b0:3b2:6988:a6f5 with SMTP id adf61e73a8af0-3b26988d373mr15231355637.4.1779222494392; Tue, 19 May 2026 13:28:14 -0700 (PDT) Received: from csl-conti-dell7858.ntu.edu.sg ([155.69.195.57]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c82c4031662sm16874478a12.16.2026.05.19.13.28.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 13:28:14 -0700 (PDT) From: Maoyi Xie To: Chengchang Tang , Junxian Huang Cc: Jason Gunthorpe , Leon Romanovsky , linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org Subject: RDMA/hns: dead empty check on head->root in setup_root_hem? Date: Wed, 20 May 2026 04:28:09 +0800 Message-Id: <20260519202809.2437430-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 a place in drivers/infiniband/hw/hns/hns_roce_hem.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 this is worth fixing. The site is setup_root_hem() (linux-7.1-rc1, around line 1270): root_hem = list_first_entry(&head->root, struct hns_roce_hem_item, list); if (!root_hem) return -ENOMEM; total = 0; for (i = 0; i < region_cnt && total <= max_ba_num; i++) { ... cpu_base = root_hem->addr + total * BA_BYTE_LEN; ... list_first_entry() returns container_of(&head->root, struct hns_roce_hem_item, list) when head->root is empty, never NULL. The -ENOMEM early return is dead code. With an empty head->root, the fall through pointer aliases &head->root inside struct hns_roce_hem_head. root_hem->addr is then read from memory at a fixed offset inside that struct, producing a garbage DMA base address that is then handed to the hardware. head->root is empty if the caller fails to allocate and add the root item before calling setup_root_hem. A future caller could also miss that precondition. A candidate fix is a one liner. Switch to list_first_entry_or_null so the -ENOMEM early return runs. 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. This hns site appears 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/