[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m135wj0xj8.fsf@fess.ebiederm.org>
Date: Thu, 25 Mar 2021 15:48:59 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@...hat.com>
Cc: Jens Axboe <axboe@...nel.dk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
io-uring <io-uring@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Stefan Metzmacher <metze@...ba.org>
Subject: Re: [PATCH 0/2] Don't show PF_IO_WORKER in /proc/<pid>/task/
Oleg Nesterov <oleg@...hat.com> writes:
> On 03/25, Eric W. Biederman wrote:
>>
>> So looking quickly the flip side of the coin is gdb (and other
>> debuggers) needs a way to know these threads are special, so it can know
>> not to attach.
>
> may be,
>
>> I suspect getting -EPERM (or possibly a different error code) when
>> attempting attach is the right was to know that a thread is not
>> available to be debugged.
>
> may be.
>
> But I don't think we can blame gdb. The kernel changed the rules, and this
> broke gdb. IOW, I don't agree this is gdb bug.
My point would be it is not strictly a regression either. It is gdb not
handling new functionality.
If we can be backwards compatible and make ptrace_attach work that is
preferable. If we can't saying the handful of ptrace using applications
need an upgrade to support processes that use io_uring may be
acceptable.
I don't see any easy to implement path that is guaranteed to work.
Eric
Powered by blists - more mailing lists