linux-kernel - Re: [PATCH 0/4] workqueue_tracepoint: Add worklet tracepoints for worklet lifecycle tracing

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sun, 26 Apr 2009 22:44:50 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Frederic Weisbecker <fweisbec@...il.com>, zhaolei@...fujitsu.com,
	kosaki.motohiro@...fujitsu.com, rostedt@...dmis.org,
	tzanussi@...il.com, linux-kernel@...r.kernel.org, oleg@...hat.com
Subject: Re: [PATCH 0/4] workqueue_tracepoint: Add worklet tracepoints for
 worklet lifecycle tracing

On Sun, 26 Apr 2009 12:47:47 +0200 Ingo Molnar <mingo@...e.hu> wrote:

> 
> * Andrew Morton <akpm@...ux-foundation.org> wrote:
> 
> > On Sat, 25 Apr 2009 02:37:03 +0200
> > Frederic Weisbecker <fweisbec@...il.com> wrote:
> > 
> > > I discovered it with this tracer. Then it brought me to
> > > write this patch:
> > > 
> > > http://lkml.org/lkml/2009/1/31/184
> > > 
> > > ...
> > > 
> > > Still with these same observations, I wrote this another one:
> > > 
> > > http://lkml.org/lkml/2009/1/26/363
> > 
> > OK, it's great that you're working to improve the workqueue code.  
> > But does this justify permanently adding debug code to the core 
> > workqueue code? [...]
> 
> Andrew - but this is not what you asked originally. Here's the 
> exchange, not cropped:
> 
> > > > So this latest patchset provides all these required 
> > > > informations on the events tracing level.
> > >  Well.. required by who?
> > >
> > > I don't recall ever seeing any problems of this nature, nor 
> > > patches to solve any such problems.
> 
> And Frederic replied that there's three recent examples of various 
> patches and problem reports resulting out of the workqueue 
> tracepoints.
> 
> Now you argue 'yes, there might have been an advantage but it's not 
> permanent' - which appears to be a somewhat shifting position 
> really. I dont think _our_ position has shifted in any way - please 
> correct me if i'm wrong ;-)

My point, as I'm sure you fully understand, is that this feature is
unlikely to see sufficient use as to warrant its inclusion.

> And i'm, as the original author of the kernel/workqueue.c code 
> (heck, i even coined the 'workqueue' term - if that matters)

Most workqueue work lately has come from Oleg.  I'm unaware that he has
expressed an interest in this feature?  Oleg, would it have been useful
in any of the work you've done?

> And the thing is, the workqueue code has been pretty problematic 
> lately - with lockups and other regressions. It's a pretty 'opaque' 
> facility that _hides_ what goes on in it - so more transparency 
> might be a good answer just on that basis alone.

OK, so there's a test case.  How many of the problems which we've
recently found and fixed in the workqueue would have been more easily
found and fixed had this feature been available?

Zero, methinks.

> Secondly, if we discount the (fairly standard) off-site tracepoints, 
> is not "large amount of debug code" - the tracepoints are completely 
> off site and are not a worry as long as the tracepoint arguments are 
> kept intact. The bits in kernel/workqueue.c are on the 26 lines flux 
> range:

Multiplied by gawd-knows-how-many other such subsystems.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/