From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66194 invoked by alias); 10 Jun 2015 09:41:02 -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 66183 invoked by uid 89); 10 Jun 2015 09:41:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 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; Wed, 10 Jun 2015 09:41:01 +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 8DE9B3679FC; Wed, 10 Jun 2015 09:40:59 +0000 (UTC) Received: from blade.nx (ovpn-116-112.ams2.redhat.com [10.36.116.112]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5A9evLS027585; Wed, 10 Jun 2015 05:40:58 -0400 Received: by blade.nx (Postfix, from userid 1000) id 63D4C2626FB; Wed, 10 Jun 2015 10:40:56 +0100 (BST) Date: Wed, 10 Jun 2015 09:41:00 -0000 From: Gary Benson To: Pedro Alves Cc: gdb-patches@sourceware.org, Eli Zaretskii , Doug Evans , Iago =?iso-8859-1?Q?L=F3pez?= Galeiras Subject: Re: [PATCH 8/9 v2] Implement vFile:setfs in gdbserver Message-ID: <20150610094056.GA18107@blade.nx> 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> <5576F6DA.5030205@redhat.com> <20150610090120.GA17727@blade.nx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150610090120.GA17727@blade.nx> X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00169.txt.bz2 Gary Benson wrote: > Pedro Alves wrote: > > 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? > > If the running kernel has namespaces support but GDB and/or glibc > was built on a kernel without. It's an edge case but it's possible. Note that GDB/gdbserver will not attempt to call setns unless the inferior is actually in a different mount namespace. If you're running without namespaces support it won't even start the helper let alone try to setns. Same goes for if you have namespaces support but the inferior is in GDB/gdbserver's mount namespace. Nothing calls setns unless it is 100% necessary. Cheers, Gary -- http://gbenson.net/