From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id J8kcFLmbSWg7ugkAWB0awg (envelope-from ) for ; Wed, 11 Jun 2025 11:07:37 -0400 Received: by simark.ca (Postfix, from userid 112) id 15BFB1E11F; Wed, 11 Jun 2025 11:07: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=-9.0 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED, RCVD_IN_VALIDITY_RPBL,RCVD_IN_VALIDITY_SAFE autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 8421F1E089 for ; Wed, 11 Jun 2025 11:07:34 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 25343385801B for ; Wed, 11 Jun 2025 15:07:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 25343385801B Received: from mailout1.rbg.tum.de (mailout1.rbg.tum.de [131.159.0.201]) by sourceware.org (Postfix) with ESMTPS id E35C63858D20 for ; Wed, 11 Jun 2025 15:07:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E35C63858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sec.in.tum.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sec.in.tum.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E35C63858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=131.159.0.201 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749654421; cv=none; b=Kkn+wSGtc2kDiFT57kh98PPHazdnfKE72DZypYtaLZkmeC6H0Ik1fIuUOMvidwiIxRDzGfvc+ZM2Ny1dyNEhYPwSBsfb617DQaEB4ehF7RR7wD8HVa7KURvyDlDuDzJB0WVv4+ExdAIjL874Pp1tLsh4X+YqoAFnwG/OqCgReWM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749654421; c=relaxed/simple; bh=6hBCoEK0qI7FlEUqiy8FzFCQrcBCVMXeBmUMLlazBCU=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=g5+8xloFg+UUx0LpheKZo3H0hrtC7VSWbcpBboSVT12MpKdgkhhRUGVk+0ib8mCTvf2gHlleARYGDOztcEk9SJ+wMcV8sYSxp+fQ3PKhCVZXgzmJslceODFNOzz/Fvy9BWVjHtegZoDm1wSJQJO4jm/nZ4jljQizos4y0JhxsJg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E35C63858D20 Received: from mailrelay1.rbg.tum.de (mailrelay1.in.tum.de [131.159.254.14]) by mailout1.rbg.tum.de (Postfix) with ESMTPS id E2BD060; Wed, 11 Jun 2025 17:06:59 +0200 (CEST) Received: by mailrelay1.rbg.tum.de (Postfix, from userid 112) id E0A3710D; Wed, 11 Jun 2025 17:06:59 +0200 (CEST) Received: from mailrelay1.rbg.tum.de (localhost [127.0.0.1]) by mailrelay1.rbg.tum.de (Postfix) with ESMTP id 9F06E102; Wed, 11 Jun 2025 17:06:55 +0200 (CEST) Received: from services.sec.in.tum.de (services.sec.in.tum.de [131.159.50.242]) by mailrelay1.rbg.tum.de (Postfix) with ESMTPS id 9C9F145; Wed, 11 Jun 2025 17:06:55 +0200 (CEST) Received: from [131.159.50.43] (dock6.sec.in.tum.de [131.159.50.43]) by services.sec.in.tum.de (Postfix) with ESMTPSA id 8BB5110061CAD; Wed, 11 Jun 2025 17:06:55 +0200 (CEST) Message-ID: <16834303-10e1-4244-a858-6d93e3c9cd7c@sec.in.tum.de> Date: Wed, 11 Jun 2025 17:06:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2][PR GDB/32956] gdb: implement linux namespace support for fileio_stat To: Andrew Burgess , gdb-patches@sourceware.org References: <20250511150113.3163767-1-kilger@sec.in.tum.de> <20250511150113.3163767-2-kilger@sec.in.tum.de> <87y0umgub1.fsf@redhat.com> <73be8b96-3a2a-4e64-885e-76f7b7ed6be1@sec.in.tum.de> <784e0c86-f879-46d5-8631-702e6ae611bc@sec.in.tum.de> <87zfeehany.fsf@redhat.com> <87wm9iha5l.fsf@redhat.com> Content-Language: en-US From: Fabian Kilger Autocrypt: addr=kilger@sec.in.tum.de; keydata= xjMEYHltfxYJKwYBBAHaRw8BAQdA7mzpLUfZIcIiMjdx+GBa8RuqZdMp/MUEpu4PDTb2YwXN JEZhYmlhbiBLaWxnZXIgPGtpbGdlckBzZWMuaW4udHVtLmRlPsKLBBMWCAAzFiEETPRi+vRL aNymGJvYr2lqRpshfmkFAmB5bX8CGwMFCwkIBwIGFQgJCgsCBRYCAwEAAAoJEK9pakabIX5p CzcA/ivCFRRbxJfpiwOzV5CvflcHPNN2LmCxSBlcrBpliBhWAP43PcAtWheftijoLpcwy3nD 0TVTDRrJY/hRkKDbvmrWCM44BGB5bX8SCisGAQQBl1UBBQEBB0BtYlZed2qkwQWmV+MaUhC7 8XgZI0ezLuU2nr8bocqXCAMBCAfCeAQYFggAIBYhBEz0Yvr0S2jcphib2K9pakabIX5pBQJg eW1/AhsMAAoJEK9pakabIX5pUNQA/juajzwCYdtbo+sXQUlZufPiPwLiPr6LuJBNZwL6Olbm AQDvyu6h+X9K2gzgLviiNEmcCAddwynvjXiLt3c+oir7AA== In-Reply-To: <87wm9iha5l.fsf@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------4HLsUSIf3CJ6Lfw9r3jwDWlf" 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 an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------4HLsUSIf3CJ6Lfw9r3jwDWlf Content-Type: multipart/mixed; boundary="------------HS0GIPWoXyMpNkj0dyuNriJ4"; protected-headers="v1" From: Fabian Kilger To: Andrew Burgess , gdb-patches@sourceware.org Message-ID: <16834303-10e1-4244-a858-6d93e3c9cd7c@sec.in.tum.de> Subject: Re: [PATCH 1/2][PR GDB/32956] gdb: implement linux namespace support for fileio_stat References: <20250511150113.3163767-1-kilger@sec.in.tum.de> <20250511150113.3163767-2-kilger@sec.in.tum.de> <87y0umgub1.fsf@redhat.com> <73be8b96-3a2a-4e64-885e-76f7b7ed6be1@sec.in.tum.de> <784e0c86-f879-46d5-8631-702e6ae611bc@sec.in.tum.de> <87zfeehany.fsf@redhat.com> <87wm9iha5l.fsf@redhat.com> In-Reply-To: <87wm9iha5l.fsf@redhat.com> --------------HS0GIPWoXyMpNkj0dyuNriJ4 Content-Type: multipart/mixed; boundary="------------W60IvUckjyCGivH4wl8tqWm6" --------------W60IvUckjyCGivH4wl8tqWm6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/11/25 11:58, Andrew Burgess wrote: > Andrew Burgess writes: >=20 >> Fabian Kilger writes: >> >>> While looking at it, I've noticed all implementations of stat functio= ns >>> actually use lstat and not stat. This maybe should be modified in the= >>> namespace case as well and I'll be changing this for v2. However, I >>> could not directly find a rationale behind why *_stat functions call >>> lstat instead. Possibly, it might make sense renaming the >>> target_fileio_stat to target_fileio_lstat as well, though this would = be >>> an independent change. >> >> Without digging into the history I say for sure why it's lstat over >> stat. >> >> I agree with you that renaming the API might make some sense, though I= >> suspect we're really a little stuck, the remote protocol packet is >> called 'stat', which is unfortunate, we cannot really change that. >=20 > OK, so I dug into the history, and it would appear that (a) it was just= > a mistake, and (b) it was all my fault :-/ >=20 > The code in question does want lstat, so really the whole API should > have been called lstat. >=20 > Most of this can easily be fixed, but the remote protocol part we're > unfortunately stuck with. Though I wonder if we can "fix" this by just= > have a 'stat' and 'lstat' remote protocol packet, change 'stat' to do a= n > actual 'stat', then on the GDB side we'll change the internal target AP= I > to be called 'lstat'. This would effectively orphan the remote 'stat' > packet, as nobody would use it, but that's OK I think, and only minimal= > overhead. I'll take a look at rolling something like this together. >=20 > For you, right now, you should name your functions 'stat', but do an > 'lstat' to be consistent. >=20 > Thanks, > Andrew >=20 Following the same logic of '"correct" style takes precedent over matching "incorrect" style', would it not make sense to start using lstat in the name for those functions that actually perform lstat? The code would be overall more clear if the functions are called _lstat and perform lstat imo. In case a 'lstat' remote protocol packet will be added, it would also be already clear if the existing functions are already named lstat. Especially in the namespace helper code and the communication protocol this lstat/stat name confusion would spread in a call chain of like 5 functions. Maybe my point would be more clear if I submit the current version of the patch. Best, Fabian --=20 Fabian Kilger, M.Sc. Wissenschaftlicher Mitarbeiter Technische Universit=C3=A4t M=C3=BCnchen TUM School of Computation, Information and Technology Chair of IT Security Boltzmannstra=C3=9Fe 3 Raum 01.08.053 85748 Garching (bei M=C3=BCnchen) Tel. +49 (0)89 289-18587 Fax +49 (0)89 289-18579 kilger@sec.in.tum.de www.sec.in.tum.de --------------W60IvUckjyCGivH4wl8tqWm6 Content-Type: application/pgp-keys; name="OpenPGP_0xAF696A469B217E69.asc" Content-Disposition: attachment; filename="OpenPGP_0xAF696A469B217E69.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xjMEYHltfxYJKwYBBAHaRw8BAQdA7mzpLUfZIcIiMjdx+GBa8RuqZdMp/MUEpu4P DTb2YwXNJEZhYmlhbiBLaWxnZXIgPGtpbGdlckBzZWMuaW4udHVtLmRlPsKLBBMW CAAzFiEETPRi+vRLaNymGJvYr2lqRpshfmkFAmB5bX8CGwMFCwkIBwIGFQgJCgsC BRYCAwEAAAoJEK9pakabIX5pCzcA/ivCFRRbxJfpiwOzV5CvflcHPNN2LmCxSBlc rBpliBhWAP43PcAtWheftijoLpcwy3nD0TVTDRrJY/hRkKDbvmrWCM44BGB5bX8S CisGAQQBl1UBBQEBB0BtYlZed2qkwQWmV+MaUhC78XgZI0ezLuU2nr8bocqXCAMB CAfCeAQYFggAIBYhBEz0Yvr0S2jcphib2K9pakabIX5pBQJgeW1/AhsMAAoJEK9p akabIX5pUNQA/juajzwCYdtbo+sXQUlZufPiPwLiPr6LuJBNZwL6OlbmAQDvyu6h +X9K2gzgLviiNEmcCAddwynvjXiLt3c+oir7AA=3D=3D =3DVdeZ -----END PGP PUBLIC KEY BLOCK----- --------------W60IvUckjyCGivH4wl8tqWm6-- --------------HS0GIPWoXyMpNkj0dyuNriJ4-- --------------4HLsUSIf3CJ6Lfw9r3jwDWlf Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- wnsEABYIACMWIQRM9GL69Eto3KYYm9ivaWpGmyF+aQUCaEmbjwUDAAAAAAAKCRCvaWpGmyF+aVDc AQD/2orGXx051X85+QhbJPz0nznqYclhNoa1zJCmuIU1hwD8D9HVvLiQycC6eEO1xJwqLG0AUdy1 EhkkgkzJ1iDOQw0= =eOvh -----END PGP SIGNATURE----- --------------4HLsUSIf3CJ6Lfw9r3jwDWlf--