linux-kernel - Re: [patch 7/7] stacktrace filtering for fault-injection capabilities

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] [day] [month] [year] [list]

Date:	Fri, 13 Oct 2006 12:06:39 -0700
From:	Andrew Morton <akpm@...l.org>
To:	"Akinobu Mita" <akinobu.mita@...il.com>
Cc:	linux-kernel@...r.kernel.org, ak@...e.de,
	"Don Mullis" <dwm@...r.net>, Valdis.Kletnieks@...edu
Subject: Re: [patch 7/7] stacktrace filtering for fault-injection
 capabilities

On Sat, 14 Oct 2006 03:12:23 +0900
"Akinobu Mita" <akinobu.mita@...il.com> wrote:

> 2006/10/14, Akinobu Mita <akinobu.mita@...il.com>:
> 
> > > > --- work-fault-inject.orig/lib/Kconfig.debug
> > > > +++ work-fault-inject/lib/Kconfig.debug
> > > > @@ -472,6 +472,8 @@ config LKDTM
> > > >
> > > >  config FAULT_INJECTION
> > > >     bool
> > > > +   select STACKTRACE
> > > > +   select FRAME_POINTER
> > > >
> > > >  config FAILSLAB
> > > >     bool "fault-injection capabilitiy for kmalloc"
> > > >
> > >
> > > Is the selection of FRAME_POINTER really needed?  The fancy new unwinder
> > > is supposed to be able to handle frame-pointerless unwinding?
> >
> > As I wrote in another reply, There are two type of implementation of
> > this stacktrace filter.
> >
> > - using STACKTRACE + FRAME_POINTER
> > - using new unwinder (STACK_UNWIND)
> >
> > The stacktrace with using new unwinder without FRAME_POINTER is much
> > slower than STACKTRACE + FRAME_POINTER.
> >
> 
> Maybe I should drop new unwinder support for now.

I'd say it should stay.  It'll be a lot more accurate once everything is
sorted out.  And hopefully the new unwinder will get sped up.

Plus I don't think performance matters a lot here: if you want to test the
e100 driver with fault injection, the whole test would take about three
seconds.  After that, you've exercised every code path in the driver.  So
if enabling range-based fault injection increases that to 300 seconds, it is
still practical.
-
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/