From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id jZ27ADbZjWrJNAAAWB0awg (envelope-from ) for ; Tue, 25 Aug 2026 14:04:38 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=SLcseAjv; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D52EA1E0A3; Tue, 25 Aug 2026 14:04:37 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,WEIRD_PORT autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5C3191E033 for ; Tue, 25 Aug 2026 14:04:36 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A169F4BA79B4 for ; Tue, 25 Aug 2026 18:04:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A169F4BA79B4 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=SLcseAjv Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 8212D4BA23DE for ; Tue, 25 Aug 2026 18:04:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8212D4BA23DE Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8212D4BA23DE Authentication-Results: sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787681050; cv=none; b=S4QpGT6BrdK2v5LqQUIwMIV5rBWHyLV1xQFilj5pB21wtdGwbETocPyi/FU5dEWPRSxyfhr5VlWRhpeEdJ6EBwLOKxYCLuogBrDWZ6fxmVX4OXKenPFbvl/rwWQV4TeHUzPPGLR7pmxPnN3pQIDnpdbOGxpHfMG2PLl5oc5lCl4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787681050; c=relaxed/simple; bh=rUDeIBsagzT0ZTymcmVEakDxwaneMc5F2kByHTRuA9Y=; h=DKIM-Signature:Message-ID:Date:MIME-Version:From:Subject:To; b=MgafJX0e8547q6fI4ugU8bnCNcnTKiYpHtUXOQ17pb6/fv7zv/SmTJk6+cHAMLyaBlQsbU2kqXpTxoEH8KxuxULFiIqUpeHA6XFPvwIUMMsPdl/w6kOpIRmH7SlkdrRgUHVwoFh6mZhjXjr9f40wTAlcGK39XuuR4za7P6+t2bE= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=SLcseAjv DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8212D4BA23DE Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67PI1dK43932622; Tue, 25 Aug 2026 18:04:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:message-id:mime-version:subject:to; s= pp1; bh=Y4P2KhLa+pyLZ8U7TwKVc0ZD5vNra+RpDOlvEXjjbMk=; b=SLcseAjv f/CO1dlhXd71xEobr5bFflrKXpnYwXv0ZFzcLm8Dhe3X5RZgfXib4zTW9T+7ap+N Cyk8eMy65dqwgi86seet2dA4oBPL3XqLqbYijo9oGGY0wnA202LIYTrog5jsfQ38 NH7HAEJGHS8XbLVsRc3wlECQX2xsi0edmweE+Jp5JkF1qlJeFhBcaWA0hS91zx2I pAkeFBIEFoQnOsbGZlxTqUnRYB6oiDH2FvBXmw/cNR7tpz0tXDi3pR2s6oNECWCF sgdXrnisClvpV4z6HOhgDCC5aUx2UQJbMYxLmi36qRX7+jyYxU+aCjRPqZ3CM7Pl NyP8YU9zsa1wAg== Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4g73eqsucy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Aug 2026 18:04:07 +0000 (GMT) Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67PHuG2n027870; Tue, 25 Aug 2026 18:04:06 GMT Received: from smtprelay04.dal12v.mail.ibm.com ([172.16.1.6]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 4g7p3q5uj3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Aug 2026 18:04:06 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (smtpav06.dal12v.mail.ibm.com [10.241.53.105]) by smtprelay04.dal12v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 67PI44KS44958000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Aug 2026 18:04:04 GMT Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0ABF258055; Tue, 25 Aug 2026 18:04:04 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 61EF358043; Tue, 25 Aug 2026 18:04:02 +0000 (GMT) Received: from [9.39.23.197] (unknown [9.39.23.197]) by smtpav06.dal12v.mail.ibm.com (Postfix) with ESMTP; Tue, 25 Aug 2026 18:04:01 +0000 (GMT) Content-Type: multipart/alternative; boundary="------------Nl2kl9auNKyjE0E8Gp0Cen8W" Message-ID: <52636405-75ad-402c-8941-7851b1f2a16e@linux.ibm.com> Date: Tue, 25 Aug 2026 23:34:00 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Abhay Kandpal Content-Language: en-GB Subject: remote fileio: st_ino truncated to 32 bits in vFile:stat/lstat To: "gdb-patches@sourceware.org" Cc: Andrew Burgess , Carl Love , Abhay Kandpal X-TM-AS-GCONF: 00 X-Proofpoint-GUID: QAIhcutarpIR8Smb_O_qjNlY7JZAZd5Z X-Proofpoint-ORIG-GUID: QAIhcutarpIR8Smb_O_qjNlY7JZAZd5Z X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI1MDE1MyBTYWx0ZWRfX5EDFUpUWuv2+ iyHnurgtERUPC/DN03gw8QamyUJHhj94wbPPH+1PDGxoFvUsawi2+hwc/xZFYohQLSfMblv0NVO 4qjVBlOl3SWVilW1aKaLM3MwMfP65/OQzWG8JAWsguPpjm3w6AovriJpQm5SpQfxl9F82yoFNLI or5cAUbg1T7wEtYk7ucbhcUIja0IA9P9amoZ2ZAxHE/BtRmYRWn9a9ahRPG0Pe46AwxzLGFENAD Y/IesIVG4Kx2FDjITqLCchwX/csPQA0EhNHDGUoYHcUxg8BPXK/PB6M5xaidYxwm+GIlnOv0ZlY TWMD3n1Hy0YPZi5XFuqPLQa24nRjO2siXGSp8p+l5a2tEOrEG40bgeqo4Wd8xkpg6phlhsozQeq pGbhr1ZZxZgWyCvQWMrNQ5cdRevIfM2TvAyvIU37Zsav8ZfU+4NM866rWh/KWbEc58HWkfGFxJp CxtYt/BqPXIlqNyz/+g== X-Authority-Analysis: v=2.4 cv=QsRuG1yd c=1 sm=1 tr=0 ts=6a8dd917 cx=c_pps a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=uAbxVGIbfxUO_5tXvNgY:22 a=r77TgQKjGQsHNAKrUKIA:9 a=CCpqsmhAAAAA:8 a=EU46ilyjIMX0ZDRxuSMA:9 a=QEXdDO2ut3YA:10 a=8IkMhoxi5MxVBBZpoR4A:9 a=oaOHS6QnzIMV-Of9:21 a=_W_S_7VecoQA:10 a=ul9cdbp4aOFLsgKbc677:22 X-Proofpoint-Spam-Info: AW1haW4tMjYwODI1MDE1MyBTYWx0ZWRfXwwtsl/AVs/rY 1Zn71ObKRlgn4Z8bL7mRdr5Odi0t2Nztbawrl3nbrKGw8FluD4aWRTT4t87m08QFQyiRbKHwgVc h3wJc8CzHTMPLLKAsXX67AgU6qbj3js= X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-25_05,2026-08-24_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 adultscore=0 suspectscore=0 priorityscore=1501 impostorscore=0 spamscore=0 lowpriorityscore=0 clxscore=1015 bulkscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608250153 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org This is a multi-part message in MIME format. --------------Nl2kl9auNKyjE0E8Gp0Cen8W Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, I hit a failure in gdb.server/fileio-packets.exp on a machine whose filesystem uses inode numbers above 2^32. All four stat/lstat checks fail, with every field matching except st_ino: remote = {..., 'st_ino': 2161233200, ...} local = {..., 'st_ino': 122420317488, ...} 122420317488 = 0x1C80CE9BB0 2161233200 = 0x80CE9BB0 The field is 4 bytes wide in the protocol struct, while st_ino is 64-bit on Linux: gdbsupport/fileio.h:130 fio_uint_t fst_ino; gdbsupport/fileio.cc:281 host_to_fileio_uint ((long) st->st_ino, fst->fst_ino); fst_size, fst_blksize and fst_blocks in the same struct already use the 8-byte fio_ulong_t. It reproduces on xfs (86 TB, largest inode 171801755018) and passes on ext4 (2 TB, largest inode 132907009), so it depends on the filesystem rather than the architecture. https://sourceware.org/bugzilla/show_bug.cgi?id=34567 Before writing anything I wanted to ask how you'd prefer this handled. struct fio_stat is shared between the vFile packets and the older F-packet protocol, so widening fst_ino changes the wire layout for both. I can see three options: 1. Widen the shared field. 2. Add a separate wider struct used only by the vFile packets, along the lines of your reasoning in c29a37f7417 about those packetsstill being new. 3. Negotiate the wider format through qSupported. The second seems the least disruptive, but I don't have a good sense of who else implements these packets. Also worth deciding at the same time, if the layout is being revised: fst_dev and fst_rdev are fio_uint_t although dev_t is 64-bit, and the three timestamps are 4 bytes. Thanks, Abhay --------------Nl2kl9auNKyjE0E8Gp0Cen8W Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 
Hi Andrew,
I hit a failure in gdb.server/fileio-packets.exp on a machine whose filesystem uses inode numbers above 2^32.

All four stat/lstat checks fail, with every field matching except st_ino:
remote = {..., 'st_ino': 2161233200, ...}
local  = {..., 'st_ino': 122420317488, ...}
122420317488 = 0x1C80CE9BB0
2161233200  =   0x80CE9BB0
The field is 4 bytes wide in the protocol struct, while st_ino is 64-bit on Linux:
gdbsupport/fileio.h:130   fio_uint_t  fst_ino;
gdbsupport/fileio.cc:281  host_to_fileio_uint ((long) st->st_ino, fst->fst_ino);
fst_size, fst_blksize and fst_blocks in the same struct already use the 8-byte fio_ulong_t.
It reproduces on xfs (86 TB, largest inode 171801755018) and passes on ext4 (2 TB, largest inode 132907009),
so it depends on the filesystem rather than the architecture.
https://sourceware.org/bugzilla/show_bug.cgi?id=34567
Before writing anything I wanted to ask how you'd prefer this handled.

struct fio_stat is shared between the vFile packets and the older F-packet protocol,
so widening fst_ino changes the wire layout for both.

I can see three options:

 1. Widen the shared field.
 2. Add a separate wider struct used only by the vFile packets,
    along the lines of your reasoning in c29a37f7417 about those packetsstill being new.
 3. Negotiate the wider format through qSupported.
The second seems the least disruptive, but I don't have a good sense of who else implements these packets.

Also worth deciding at the same time, if the layout is being revised: 
fst_dev and fst_rdev are fio_uint_t although dev_t is 64-bit, and the three timestamps are 4 bytes.
Thanks,
Abhay


--------------Nl2kl9auNKyjE0E8Gp0Cen8W--