This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 8/9 v2] Implement vFile:setfs in gdbserver
- From: Pedro Alves <palves at redhat dot com>
- To: Gary Benson <gbenson at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Eli Zaretskii <eliz at gnu dot org>, Doug Evans <dje at google dot com>, Iago López Galeiras <iago at endocode dot com>
- Date: Wed, 10 Jun 2015 15:53:51 +0100
- Subject: Re: [PATCH 8/9 v2] Implement vFile:setfs in gdbserver
- Authentication-results: sourceware.org; auth=none
- References: <1429186791-6867-1-git-send-email-gbenson at redhat dot com> <1430395542-16017-9-git-send-email-gbenson at redhat dot com> <555DF2EE dot 2030707 at redhat dot com> <20150609141118 dot GA29533 at blade dot nx> <5576F6DA dot 5030205 at redhat dot com> <20150610090120 dot GA17727 at blade dot nx> <20150610094056 dot GA18107 at blade dot nx>
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