From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71908 invoked by alias); 9 Jun 2015 14:23:35 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 71831 invoked by uid 89); 9 Jun 2015 14:23:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 09 Jun 2015 14:23:26 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 554DBBDD73; Tue, 9 Jun 2015 14:23:25 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t59ENNkv010668; Tue, 9 Jun 2015 10:23:23 -0400 Message-ID: <5576F6DA.5030205@redhat.com> Date: Tue, 09 Jun 2015 14:23:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gary Benson CC: gdb-patches@sourceware.org, Eli Zaretskii , Doug Evans , =?windows-1252?Q?Iago_L=F3pez_Galeiras?= Subject: Re: [PATCH 8/9 v2] Implement vFile:setfs in gdbserver References: <1429186791-6867-1-git-send-email-gbenson@redhat.com> <1430395542-16017-9-git-send-email-gbenson@redhat.com> <555DF2EE.2030707@redhat.com> <20150609141118.GA29533@blade.nx> In-Reply-To: <20150609141118.GA29533@blade.nx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg00131.txt.bz2 On 06/09/2015 03:11 PM, Gary Benson wrote: > Pedro Alves wrote: >> For the setns/ENOSYS case, how about somehow probing whether setns >> actually works here (with a new method, or probing one of the >> existing ones with getpid()) and return empty packet, instead of >> ending up with open failing with ENOSYS later on? > > Probing and then telling GDB we don't understand "vFile:setfs:" isn't > that good of an idea. If we do that with an inferior in another mount > namespace then the end result is that gdbserver will access the wrong > filesystem. You might get "file not found", or you might get an open > filehandle on another file (i.e. the file with the same name but in > gdbserver's filesystem). If the inferior's filesystem is different > from gdbserver and gdbserver cannot access that filesystem then the > only correct response is to fail. If the running system does not support "setfs", because it fails setns with ENOSYS, meaning, the system call isn't implemented at all, how can one end up in the situation that an inferior on the same kernel is running in a different filesystem namespace? > > I've updated linux_mntns_access_fs to translate ENOSYS from setns > into ENOTSUP, so neither native nor gdbserver will ever get ENOSYS > from this code. From [1] ENOTSUP seems to be the perfect code for > linux_mntns_{open_cloexec,unlink,readlink} to be returning: Great, thanks. > Thanks for hassling me about this, it took me a while to understand > what you were saying. Thanks for the patience and following through. Thanks, Pedro Alves