linux-kernel - Re: [PATCH 01/31] Add hard/soft lockup debugger entry points

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Jan 2016 13:58:46 -0700
From:	Jeffrey Merkey <jeffmerkey@...il.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	dzickus@...hat.com, uobergfe@...hat.com, atomlin@...hat.com,
	mhocko@...e.cz, fweisbec@...il.com, tj@...nel.org,
	hidehiro.kawai.ez@...achi.com, cmetcalf@...hip.com
Subject: Re: [PATCH 01/31] Add hard/soft lockup debugger entry points

On 1/28/16, Thomas Gleixner <tglx@...utronix.de> wrote:
> On Thu, 28 Jan 2016, Jeffrey Merkey wrote:
>> On 1/28/16, Thomas Gleixner <tglx@...utronix.de> wrote:
>> > I'm probably missing something obvious here.
>>
>> It's a pain in the butt to grep around through assembly language in a
>> function in watchdog.c that has everything declared static with no
>> symbols.  It's a lot easier just to insert an INT3 in the section of
>> code that has the mouse caught in the trap (inside a function that
>> triggers the hard lockup) -- after all -- that's what the instruction
>> is for.
>
> AFAICT, debuggers can set breakpoints on arbitrary code lines without
> grepping
> through assembly language. If you don't have the debug information
> available,
> then using a debugger is pointless anyway.
>
> This is beyond silly. If we follow your argumentation we need another
> gazillion of conditional breakpoints in the kernel. Definitely not.
>
> Thanks,
>
> 	tglx
>
>
>

If you don't get it Thomas, I don't know what else to say.  Right now
the only debugger that provides disassembly on a single running live
Linux system is the one I use unless you want to use a serial
connection with kgdb.  All you are convincing me of is that you don't
use a debugger or sit around looking at dissassembly all day long on
live linux systems looking for bugs or you would understand why this
is so helpful.  So I totally understand why you don't get this.

Think of it like git.  Before git was around, everything was done with
manual patches.  Now we have git, and everything can be automated.
Same thing here.  Why do I want to grep around looking for a bug when
I can have linux find it for me.

Jeff