Message-ID: <CA+ekxPX10tA_GskTsUw8VronS0mf_yTMhR__PdV3bP93D86mbA@mail.gmail.com>
Date:	Fri, 29 Jan 2016 10:19:46 -0700
From:	Jeffrey Merkey <jeffmerkey@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Thomas Gleixner <tglx@...utronix.de>, 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/29/16, Jeffrey Merkey <jeffmerkey@...il.com> wrote:
> 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.
>>
>> ... 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.
>>
>> 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.
>>
>> 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.
>>
>>> [...]  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.
>>
>>> [...] 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:
>>
>>   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).
>>
>> Thanks,
>>
>> 	Ingo
>>
>
> It's not intrusive to use the BUG() macro to insert a breakpoint
> instead of the ud2a instruction to trigger a breakpoint.    All of
> thomas technical arguments were addressed to the extent he
> communicated any other than political banter.
>
> Jeff
>


Sending version 3 with use of the BUG() macro.  Then I don;t have to
touch all these arches and it's totally non-intrusive.

Jeff

Powered by blists - more mailing lists