This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 8/9 v2] Implement vFile:setfs in gdbserver


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]