From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57790 invoked by alias); 10 Jun 2015 14:53:57 -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 57778 invoked by uid 89); 10 Jun 2015 14:53:56 -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; Wed, 10 Jun 2015 14:53:55 +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 6FB62293205; Wed, 10 Jun 2015 14:53:54 +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 t5AErq7l027815; Wed, 10 Jun 2015 10:53:52 -0400 Message-ID: <55784F7F.7000808@redhat.com> Date: Wed, 10 Jun 2015 14:53: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> <5576F6DA.5030205@redhat.com> <20150610090120.GA17727@blade.nx> <20150610094056.GA18107@blade.nx> In-Reply-To: <20150610094056.GA18107@blade.nx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg00187.txt.bz2 On 06/10/2015 10:40 AM, Gary Benson wrote: > 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. I see. > > 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. To probe for setns I was thinking would be done by on gdb/gdbserver's pid, by gdb/gdbserver directly. But I agree, when the kernel supports namespaces, and we can tell the inferior is in a different namespace, but then setns doesn't work, it's better to error out than disabling the setfs packet. So I'm happy with the errno translation alone. Thanks, Pedro Alves