From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f175.google.com (mail-pg1-f175.google.com [209.85.215.175]) (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 8F16E477E31 for ; Tue, 19 May 2026 10:00:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779184833; cv=none; b=dRoQqNZdNtEtWSUogOUREOYzzOH+OMA6AxGdHEB+0HFwYhDt+250Z7PifkTJMpmIDMz3HNaUxgFCVlhSbNvV4nV44UDzK6uf6PmmEYaqb1fg22kRQmer0AEtJRu4U31HCfcbfcPqV/mgW+TcFPzcsGupEIA965HuyRObt5miDO8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779184833; c=relaxed/simple; bh=3nUL3rrmcUfID0DDtH+fnolF/wVDYul0PA1V7JWUZpE=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=WZY5Ff/QGBIulALjUhXqLahGAAbgpXqX42zDpuEkeBBIVG0vduiDCIb/ZoeiGhjShkkeSt3b5hoMh7nW+9ow2bUxUEF4eLOHuv112vaKoM/GxQkkVzgLxhu+t6s6Lg6JrCkdp3VVJtrigVGZqYLJyPtjPNTcqYVcwoxRuvsC67w= 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=fKmwsiot; arc=none smtp.client-ip=209.85.215.175 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="fKmwsiot" Received: by mail-pg1-f175.google.com with SMTP id 41be03b00d2f7-c8021c8c42fso1336311a12.3 for ; Tue, 19 May 2026 03:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779184831; x=1779789631; 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=wPlnCZIGFehZKOWoeObeqnRwLPoyuMVquqLHAA3dDM4=; b=fKmwsiot8l+L8eXmTAA/xyJ0iGcNYQYyYhB4THzkoEsiL0mBi5jkix6UMZGu2r6A0P 7q+J2VSjC+ORO4bC1wvD63Smef7N8LOhGX4bIa+3PfZ9mO0Ay9bDI5Zze4iHQr0tww8J 171JN+kl0CO4RqX6qMWDBBnoZ0FMvc55vSIwb42X34iX0BsAsVepccumWOOvIZtpBQOv Rs8iYdJm0dLlCTKw1tP6rF4kN60pFbBwT0G2wz99EuFYdVPVbIU96e3Y4IIESEWuaxxG crfmUqb5FHOLjORdau0euF85cDUitY5UZO7SJEmmvcQNI4LcqLLP/a4BCz67F/Illb8r BUSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779184831; x=1779789631; 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=wPlnCZIGFehZKOWoeObeqnRwLPoyuMVquqLHAA3dDM4=; b=I35TAK8YwVlEgr5GOowfQvupCpT0c02Qfd5qucvfN/HHY6E4Fw66pQ4Ji//y8iYw4B V/x7AfolkiYyKchUkgmELBEvZQ9aJ7TaUL/pu6FEQWi8lkMxvLm6y5GovzSyEzuyyPW6 1KQxlaWmR2UfZWcmxK8puklsslSZ9DOwI4+O4at/JJddGYMVBbbX0I2alv6ZdrtpQcAW ZEG2RGqdxTXv6Ba5cR/ICqcuEW/1YyFAWcqa+tivy0Snzn/nPqoO28tlL6EkYz8BS336 kS+W+aRiRD6vXO2NlhOZ5RPb8w6egYjlfDiEq8lk38hcH8PvIon691gxq8HM534zqeIX rzZA== X-Forwarded-Encrypted: i=1; AFNElJ/zxNJBeMhmoh+VQeIrpadtNt8JDqHPp1WVpCfArCCghJosfbeT82UeTNqVZKk5Nbu73B2TAK7SEQOEMrs=@vger.kernel.org X-Gm-Message-State: AOJu0YziySvgBz7q+5ieI71Cn9iBQnruZXSSC4x/8SSB34N8CLcbM5jJ wDf0uIW33rO7tbcY/9nK4ktl9uJ3wDE6RfajPzVTNKDQq50hPL2jleYY X-Gm-Gg: Acq92OEArWorrULuzdbjTSZ6OC6MSvBPgeSHlX7L2Q1IWy55vXKuHUzC7weOpcRVLXb muDzbb/ngF3ai3C9OO8gnVfopWYQoSyl63gIBClw+khVqaH6HkTtt3YG9F7nlI9LcRBjVzQgaaz u6EDvgUJ/SzQUrpwR+9h8pzgaNsuWacG84505urch7ciA73PST9+s9J7Lvy4fyzzuOzuoF+HhHJ O5NOnUT0XhWPbqYlcs/zUpZmiJkLdhPtbd3FzysjJIKorGpRlIr53kEBM4n6e5iGFaaSd3xkEEL UmBGxHAFnHPtAhCwb0jPpI6lpGVzavsWcYDf+f2r1hk+eW/s4LW3Gj1ihbkF4ISreST5ukltpUj xaExQNQCUhBZw+XfOkv4wNgLHk38URayIQXtCNS/WHLip25GxbrNZQ+WfKfiZvjRFZjyQbEiM/5 Aj6BfhkQVc8eJLpaEQhJb8/iggboT2p9BUpqUcqvFAX2otKHcu X-Received: by 2002:a17:90b:1344:b0:366:4f8a:9847 with SMTP id 98e67ed59e1d1-36951b711dcmr18287582a91.17.1779184830724; Tue, 19 May 2026 03:00:30 -0700 (PDT) Received: from csl-conti-dell7858.ntu.edu.sg ([155.69.195.57]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3696e24e857sm6085380a91.0.2026.05.19.03.00.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 03:00:30 -0700 (PDT) From: Maoyi Xie To: Heiko Carstens , Vasily Gorbik , Alexander Gordeev Cc: Christian Borntraeger , Sven Schnelle , linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org Subject: s390/tape: iterator after loop end in tape_assign_minor? Date: Tue, 19 May 2026 18:00:26 +0800 Message-Id: <20260519100026.1970224-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 reading drivers/s390/char/tape_core.c I noticed something that looks like a past the end iterator pattern. I would appreciate it if you could take a look and let me know whether this is a real issue, and whether it is worth fixing. The site is tape_assign_minor() (linux-7.1-rc1, around line 339): list_for_each_entry(tmp, &tape_device_list, node) { if (minor < tmp->first_minor) break; minor += TAPE_MINORS_PER_DEV; } if (minor >= 256) { write_unlock(&tape_device_lock); return -ENODEV; } device->first_minor = minor; list_add_tail(&device->node, &tmp->node); When the loop walks all entries without break (every existing entry has first_minor at or below the candidate minor), tmp is past the end. tmp->node then aliases tape_device_list (the list head) via container_of offset cancellation. list_add_tail(&device->node, &tape_device_list) inserts the new device at the tail of the list. That is the intended behaviour for a sorted insertion where the new device has the largest first_minor. The dereference of the past the end iterator is undefined per C11. Jakob Koschel cleaned up many such sites in 2022, for example commits 99d8ae4ec8a (tracing: Remove usage of list iterator variable after the loop), 2966a9918df (clockevents: Use dedicated list iterator variable) and dc1acd5c946 (dlm: replace usage of found with dedicated list iterator variable). This site was not covered. A candidate fix would track an explicit insertion target. Declare `struct list_head *insert_before = &tape_device_list` before the loop. Overwrite it to `&tmp->node` only when the loop breaks early. The final list_add_tail then reads `insert_before`. On break that points to the entry right after the insertion position. On fall-through it stays at the list head, so list_add_tail appends at the tail. The behaviour is unchanged in all cases, including an empty list and a list with one entry. If this is intentional or already known, please disregard. Otherwise, I am happy to send a [PATCH] or to leave the fix to you. Thank you for your time, and sorry for the noise if this is not actually worth fixing or has already been spotted. Thanks, Maoyi Xie https://maoyixie.com/