[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240908140838.GB21236@redhat.com>
Date: Sun, 8 Sep 2024 16:08:38 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Roman Kisel <romank@...ux.microsoft.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, apais@...rosoft.com,
benhill@...rosoft.com, ssengar@...rosoft.com,
sunilmut@...rosoft.com, vdso@...bites.dev
Subject: Re: [PATCH 1/1] ptrace: Get tracer PID without reliance on the proc
FS
On 09/06, Roman Kisel wrote:
>
> On 9/6/2024 1:55 PM, Oleg Nesterov wrote:
> >
> >Not that I think this is a good idea, but std::breakpoint_if_debugging()
> >looks even more strange to me...
> Can't speak for everyone obviously, I've found that convenient
> when making sense of large (unknown) codebases instead of setting
> up breakpoints and adding prints/logs, and when the process
> can't/doesn't fault when it encounters a fatal error.
Sorry, I don't understand.
I fail to understand how/why people can use std::breakpoint_if_debugging().
To me it doesn't look useful at all.
But you can safely ignore me, I do not pretend I understand the userspace's
needs.
And I guess people will use it anyway, so I won't argue with, say, a trivial
patch which just adds
case PR_GET_PTRACED:
error = !!current->ptrace;
break;
into sys_prctl(), even if I agree that this probably just makes bad behavior
easier.
But you need to convince Linus.
Oleg.
Powered by blists - more mailing lists