Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The mystery of the fifteen-millisecond breakpoint instruction

blog.jwhitham.org

Post reply on HN
Print view View original

1–10 of 50 posts

Re: The mystery of the fifteen-millisecond breakpoint instruction

#4

Post by raverbashing »

caf wrote: post #2

I'm surprised the author didn't submit this patch back to the Linux ARM architecture maintainers - it seems entirely apropos.

Yes, or at least a discussion on why this instruction is not supported (might be just a slip-up or have a bigger underlying reason)

Re: The mystery of the fifteen-millisecond breakpoint instruction

#5

Post by userbinator »

What exactly is the purpose of logging all unhandled breakpoint instructions encountered in user-mode code to the syslog, and then continuing...? On Windows, a breakpoint instruction encountered outside of a debugger causes the standard error dialog to appear, and if you choose not to attach a debugger, the process terminates. IMHO that's more reasonable behaviour, as breakpoint instructions shouldn't appear in code that's not being debugged (either by a debugger or itself, as is sometimes the case like the author does here.)

because unprivileged user-space code is able to force the kernel to waste a lot of time printing messages, slowing the whole system down

User code can do that already, or even just run in an infinite loop.

Re: The mystery of the fifteen-millisecond breakpoint instruction

#6

Post by dezgeg »

userbinator wrote: post #5

What exactly is the purpose of logging all unhandled breakpoint instructions encountered in user-mode code to the syslog, and then continuing...? On Windows, a breakpoint instruction encountered outside of a debugger causes the standard error dialog to appear, and if you choose not to attach a debugger, the process terminates. IMHO that's more reasonable behaviour, as breakpoint instructions shouldn't appear in code…

    >>because unprivileged user-space code is able to force
    >>the kernel to waste a lot of time printing messages,
    >>slowing the whole system down
    >User code can do that already[...]
I'm pretty sure that'd be considered a kernel bug. After all, there already is a a function (printk_ratelimited) which is supposed to be used in situations where userspace can trigger a kernel print.

Re: The mystery of the fifteen-millisecond breakpoint instruction

#7

Post by userbinator »

dezgeg wrote: post #6
userbinator wrote: post #5

What exactly is the purpose of logging all unhandled breakpoint instructions encountered in user-mode code to the syslog, and then continuing...? On Windows, a breakpoint instruction encountered outside of a debugger causes the standard error dialog to appear, and if you choose not to attach a debugger, the process terminates. IMHO that's more reasonable behaviour, as breakpoint instructions shouldn't appear in code…

>>because unprivileged user-space code is able to force >>the kernel to waste a lot of time printing messages, >>slowing the whole system down >User code can do that already[...] I'm pretty sure that'd be considered a kernel bug. After all, there already is a a function (printk_ratelimited) which is supposed to be used in situations where userspace can trigger a kernel print.

I meant that you can already do these if you want to consume a lot of CPU time:

    for(;;) printf("Hello world!");

    for(;;) ;

Re: The mystery of the fifteen-millisecond breakpoint instruction

#8

Post by seba_dos1 »

userbinator wrote: post #7
dezgeg wrote: post #6

Earlier quoted context omitted.

>>because unprivileged user-space code is able to force >>the kernel to waste a lot of time printing messages, >>slowing the whole system down >User code can do that already[...] I'm pretty sure that'd be considered a kernel bug. After all, there already is a a function (printk_ratelimited) which is supposed to be used in situations where userspace can trigger a kernel print.

I meant that you can already do these if you want to consume a lot of CPU time: for(;;) printf("Hello world!"); for(;;) ;

Consuming a lot of CPU time and forcing kernel to do that are separate things.

Re: The mystery of the fifteen-millisecond breakpoint instruction

#9

Post by madez »

userbinator wrote: post #7
dezgeg wrote: post #6

Earlier quoted context omitted.

>>because unprivileged user-space code is able to force >>the kernel to waste a lot of time printing messages, >>slowing the whole system down >User code can do that already[...] I'm pretty sure that'd be considered a kernel bug. After all, there already is a a function (printk_ratelimited) which is supposed to be used in situations where userspace can trigger a kernel print.

I meant that you can already do these if you want to consume a lot of CPU time: for(;;) printf("Hello world!"); for(;;) ;

But that won't slow down the whole system, if you didn't mess with the process priorities.

Re: The mystery of the fifteen-millisecond breakpoint instruction

#10

Post by caf »

userbinator wrote: post #5

What exactly is the purpose of logging all unhandled breakpoint instructions encountered in user-mode code to the syslog, and then continuing...? On Windows, a breakpoint instruction encountered outside of a debugger causes the standard error dialog to appear, and if you choose not to attach a debugger, the process terminates. IMHO that's more reasonable behaviour, as breakpoint instructions shouldn't appear in code…

It doesn't continue, it delivers a SIGTRAP to the process and the default disposition of that signal (if the process isn't being debugged or has otherwise arranged to handle the signal differently) is to have the process dump core and exit.
Post reply on HN