Re: [PATCH 1/1] ptrace: Get tracer PID without reliance on the proc FS

[Roman Kisel]

On 9/6/2024 1:55 PM, Oleg Nesterov wrote:
> Well, I leave this to you and Linus (and other reviewers), but if it was not
> clear I too do not really like this feature, that is why I added cc's.
Appreciate you time and help in understanding the Linux kernel code
better!

> Perhaps it makes sense to discuss the alternatives? Say, a process can have a
> please_insert_the_breakpoint_here() function implemented in asm which just does
> asm(ret).
>
> Then something like
>
> 	#define breakpoint_if_debugging()	\
> 		asm volatile ("call please_insert_the_breakpoint_here" : ASM_CALL_CONSTRAINT);
>
> if the process is ptraced, debugger can insert the breakoint into
> please_insert_the_breakpoint_here(). Otherwise breakpoint_if_debugging()
> is a cheap nop.
>
> 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.

> Oleg.
>
> On 09/06, Roman Kisel wrote:
> > All told, let me know if I may proceed with fixing the code as Oleg
> > suggested, or this piece should go into the waste basket. I could make
> > an argument that providing the way to get the tracer PID only via
> > proc FS through parsing text is more like shell/Perl/Python interface
> > to the kernel, and for compiled languages could have what's easier in
> > that setting (there is an easy syscall for getting PID, and there could
> > be code changing the logic on the PID being odd or even for the sake
> > of argument).
> >
> > >                 Linus
> >
> > --
> > Thank you,
> > Roman

--
Thank you,
Roman