From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ICp0ALMgj2rYoAMAWB0awg (envelope-from ) for ; Wed, 26 Aug 2026 13:21:55 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ikSIA+uF; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id E37801E0A3; Wed, 26 Aug 2026 13:21:54 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 2A6041E033 for ; Wed, 26 Aug 2026 13:21:54 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6591B4BA79B4 for ; Wed, 26 Aug 2026 17:21:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6591B4BA79B4 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ikSIA+uF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id 0666A4BA2E39 for ; Wed, 26 Aug 2026 17:21:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0666A4BA2E39 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0666A4BA2E39 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787764887; cv=none; b=ws62En0G9Qxf/JfZuQ++wItS6GDhkiqFNu7jDafi48hDAgPti6XX4mXLYEPHhAc83P10BJymQtn2ybCv7PUGhTaK6UPt1T3Ok3pWZdMIe6BMqblfDDzXa0ZpjCAbfuHhkKvRDbaG3mAweGFtzYMk6xnCYddj1npUY6NDwgO0e4E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787764887; c=relaxed/simple; bh=aX6SqSgx9z8iZIuFqJSCDT9MprnH2fMpRpBD/8dEGlM=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=hYF+kW8bP6JGfeMmFkF78Jhg1+UVshBv5/yLbfoiornTZgSlng971fxHQFrUR4JUJTArCvsU7aeB25WoCiyB9lQnaPncldo4t3s29YjYTfOmkvOBf5TjahB+Oc/cEXkVVBMAFbQ3ucCXsFOz+VwULq0YClmo9PpzedxoUE7WlMA= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ikSIA+uF DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0666A4BA2E39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1787764886; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9jMmPA3REECCCoGQ51GIGYP2Xd8/CbOc5RThvxjLJ84=; b=ikSIA+uF2TPpfm0K55LsGOuYLDWzITO/ak90fX9L1ewOmaUdUCdZeIvywMgsO44H6hutJ5 iy9UIVpszTdLO3wKtvREY5+Yz4o6sW6ouSbmT3SjtOU0DzOQdui3rrozotTZNwjU8ep0WT 2rUwCcsQV49wlsV60VGfLNlM/+ZZX9U= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-191-p6ssF2DKPe2U-H-bhMrb-Q-1; Wed, 26 Aug 2026 13:21:24 -0400 X-MC-Unique: p6ssF2DKPe2U-H-bhMrb-Q-1 X-Mimecast-MFC-AGG-ID: p6ssF2DKPe2U-H-bhMrb-Q_1787764883 Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-c20e5890680so112981666b.1 for ; Wed, 26 Aug 2026 10:21:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787764883; x=1788369683; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=9jMmPA3REECCCoGQ51GIGYP2Xd8/CbOc5RThvxjLJ84=; b=AoHOi80JP7aXFAxGSot8kuA8bqbSNvMghduNnEDzoa9Dkeq6P+6IklJFuwLN76cQHt nh/4pFLqIHOW/NeZxjEP1gAj1cwr4+h47MQNEwQ6W+BtxjerJJp4IJcXdRJO/NEcmHvB /1ut/IKPJFiTssKhuh7P23VpAhsgwkUgg1o9GMheNeCYjnQFHuEUoEdR1fP54vY5x+hV 6gjeEsy1+6WUqFLf0aqiwArom/bQUIZe5D+541fR/jL/9lIzXaK0taiUjrAUZIRue/9I TbmQ8HJshgfGo9ref+D1GMf98Hogt9pVcMEcptt6KSd6uL4X86l4LMqPnd1/2hg+WQk4 oOmQ== X-Forwarded-Encrypted: i=1; AHgh+RpZUYbr02DYcWZwCT28cfkGiDFiUJ769gDZVS+ovQVqgWuZbErdsxshNdMeoOXHwoX7I89ecNtk2RaUNw==@sourceware.org X-Gm-Message-State: AFuF++n5IVASSH/DIWIvnP6X31vzfHCWhGccEMaLuOlWUSXx3UTEMU37 CknZSt5wR6i7KQT8//sBflR/r5j7rhDZvP1fNmvKdoGWdZxSd0FEh7K5RPgCbK/Ila0uJENlj+4 SpSoxWCJ+jT0BYbuYRJ4Yyrp6JgohA9+x4jCGTv6XmvN2VGODV/pExLEHxbtlUZ4= X-Gm-Gg: AR+sD12w42pm297sQVVjI+RgIMhOWTuEGNxA4keicQDiw6eUFqO0q1zr47CG0nkGU+Q p92qSOdF1dW3ZdEgjJFI9s/buTx92n0+wZMtFAEPqNpEK8bGjwZa/qQeM+QZl3Y0VCmA6ZL+qpA DXxqdWejwlkJZswZwc9hxkgJkDcScsLw0SwGhgrSJ61yKrSKFm9IweU5vUIgTRr0bzVBkNUwiXB ZbTkIydxa7Pv4sGNieg2XZxpH5PeMqFeYSbpdNh4FexmzMwo6HxadoysSJhJnpM0anaJeEgMv+U cCt/XaiYsfw8tAUBGp1AvCIdLzEjZ5IErcpvgIrhu8q9avU2VKW7oZ1xdrOw/9s8fZ8LD0y5kmz 6zIWTQ25K/8esvOPqVyNAWfp3dvQ= X-Received: by 2002:a05:6938:a086:10b0:c25:33db:939e with SMTP id a640c23a62f3a-c2533dba1f2mr173531666b.4.1787764883273; Wed, 26 Aug 2026 10:21:23 -0700 (PDT) X-Received: by 2002:a05:6938:a086:10b0:c25:33db:939e with SMTP id a640c23a62f3a-c2533dba1f2mr173521566b.4.1787764882755; Wed, 26 Aug 2026 10:21:22 -0700 (PDT) Received: from localhost (128.223.159.143.dyn.plus.net. [143.159.223.128]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c250a5d69a7sm899002466b.8.2026.08.26.10.21.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Aug 2026 10:21:22 -0700 (PDT) From: Andrew Burgess To: Abhay Kandpal , "gdb-patches@sourceware.org" Cc: Carl Love , Abhay Kandpal Subject: Re: remote fileio: st_ino truncated to 32 bits in vFile:stat/lstat In-Reply-To: <52636405-75ad-402c-8941-7851b1f2a16e@linux.ibm.com> References: <52636405-75ad-402c-8941-7851b1f2a16e@linux.ibm.com> Date: Wed, 26 Aug 2026 18:21:21 +0100 Message-ID: <87ecfku7am.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: SkHz8QRwh8AZVzg9keK9qYl5tXzurE53mmdoImodd2E_1787764883 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Abhay Kandpal writes: > 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. I think this would not be accepted as this would break communication between different versions of GDB and gdbserver, right? > 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. I think only fixing vFile would be a mistake. The 'F' packets are not an older protocol that has been replaced with vFile. The two systems offer similar functionality, but in opposite directions. If we're fixing one direction then we really should fix both. In c29a37f7417 I changed the underlying implementation of the 'stat' packet from using 'lstat' to using 'stat'. The actual on-the-wire bits didn't change, just what gdbserver did with them. An old GDB can still talk to a new gdbserver and vice versa. What you're proposing would break this cross version communication, just like option #1, right? > 3. Negotiate the wider format through qSupported. I think this is the only possible way forward unfortunately. It is going to be more work, but anything else is going to end up breaking backward compatibility. > > The second seems the least disruptive, but I don't have a good sense of who else implements these packets. That's a huge problem we have. We really have no visibility at all for how this stuff is used outside the GDB project. We solve this problem by basically assuming that anything that has been released might be being used, and so cannot be changed. That's probably not true, but we just have no way of knowing. > > 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. It sounds like what you're saying is that a whole bunch of fields are the wrong size. I put together this table: | Field Name | Type | Size | Actual | | | | Now | Size | |-------------+-------------+------+--------| | fst_dev | fio_uint_t | 4 | 8 | | fst_ino | fio_uint_t | 4 | 8 | | fst_mode | fio_mode_t | 4 | ? | | fst_nlink | fio_uint_t | 4 | ? | | fst_uid | fio_uint_t | 4 | ? | | fst_gid | fio_uint_t | 4 | ? | | fst_rdev | fio_uint_t | 4 | 8 | | fst_size | fio_ulong_t | 8 | ? | | fst_blksize | fio_ulong_t | 8 | ? | | fst_blocks | fio_ulong_t | 8 | ? | | fst_atime | fio_time_t | 4 | 8? | | fst_mtime | fio_time_t | 4 | 8? | | fst_ctime | fio_time_t | 4 | 8? | The 'Size Now' is the current field size in fio_stat, while the 'Actual Size' is what the fields need to be in order to be correct on your system. You mention the three timestamps above, but don't say what size they need to be. I'm assuming 8, but that might not be correct either. Also there are some fields that you haven't mentioned, maybe they are all correct, but we should check. What I'd suggest is that you finish filling in the above table, then I think you'll want to have two versions of fio_stat, one with the current field sizes, and one with the wider field sizes. I'd suggest that you update the core throughout to use the struct with the wider field sizes, but at some point before this struct is sent down the wire, if the use of the wide struct has not been negotiated, then you'll need to squeeze the wide struct into the short one, trimming the fields. I think it's OK to print a warning if non-zero information is discarded at this point. Similarly, when one of these structs is pulled from the wire, if the incoming packet is the narrow version, I'd expand it into the wide version. In this way, most GDB/gdbserver code will only need to handle the version with the wider fields, but the wire protocol remains unchanged. Thanks, Andrew