Date:	Fri, 29 Jan 2016 19:43:19 -0700
From:	Jeffrey Merkey <jeffmerkey@...il.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	Thomas Gleixner <tglx@...utronix.de>, 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,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 01/31] Add hard/soft lockup debugger entry points

On 1/29/16, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Jeffrey Merkey <jeffmerkey@...il.com> wrote:
>
>> 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. [...]
>
> He provided specific technical arguments:
>
>> > AFAICT, debuggers can set breakpoints on arbitrary code lines without
>> > grepping
>> > through assembly language.
>
> Thomas's argument is that live kernel debuggers are already able to insert
> breakpoints just fine, without us having to artificially uglify the source
> code
> like your patch series does.
>

I agree that this patch series is less than ideal.

> ... but instead of addressing his technical point (which is perfectly
> valid), you
> replied with a condescending tone. You are quickly establishing yourself as
> a
> contributor who is difficult to work with.
>

Well, Ingo, I guess we both have articles smeared all over the internet about
how we are hard to deal with.  You have a few, I have a few.  Other people have
them to.  People who make a difference ruffle feathers.  It's the
nature of change.
The only person that likes change is a wet baby.

> As to Thomas's point: on typical distro kernels we at minimum have the
> kallsyms
> data, but also the System.map in general on packaged kernels. Having
> function
> symbols is more than enough to start a disassembly from, and the breakpoint
> can be
> set from there.
>

Well, I can certainly do all that, all I was suggesting was let linux
find the bugs
for you and pop into a debugger if one is active.

> If you intentionally and completely throw away all symbol data then
> debuggability
> decreases drastically. That's nothing new - don't do that. Note that
> disassembly
> from a live debugger is generally _still_ possible: as function entries are
>
> usually pretty easy to recognize signatures - and generally there's enough
> padding
> for cache alignment reasons for even a 'blind' disassembly starting say 1KB
> before
> the intended breakpoint to actually show correct disassembly.
>
> So I don't see any technical reason to apply your patch-set in that form.
>

I would agree that something more elegant is needed.

>> [...]  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. [...]
>
> Given that at least in the x86 space most systems have a real or an emulated
>
> serial line (the latter via management interfaces), this isn't a big
> limitation in
> practice.
>

A live debugger on actual hardware is a far cry from a simulated UML/KVM/QEMU
style environment.  It's just not the same thing.  And I use kgdb with
a virtual
serial connection, but GDB has got to be one of the most user hostile interfaces
on the planet.  It's plain hard to use with long commands and piss
poor command recall.

>> [...] 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.
>
> Just for the record, I don't see the point of the many artificial and ugly
> breakpoints either that your series adds, so I'm NAK-ing this intrusive
> form,
> until better justification is given:

How about I go off and refine this idea and submit something later.

>
>   NAKed-by: Ingo Molnar <mingo@...nel.org>
>
>> 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.
>
> Non sequitur: uglifying kernel source code (which has a very real cost for
> only
> marginal benefit - making it a net negative) has very little to do with the
>
> utility of Git (which has small cost for a big benefit, which makes it a net
>
> positive).

There are thousands of BUG(), WARN(), BUG_ON() macros uglifying the code
already.    BFD.

Jeff

>
> Thanks,
>
> 	Ingo
>

Powered by blists - more mailing lists