Messages in this thread | | | Date | Sat, 14 Oct 2006 03:00:39 +0900 | From | Akinobu Mita <> | Subject | Re: [patch 7/7] stacktrace filtering for fault-injection capabilities |
| |
On Thu, Oct 12, 2006 at 02:20:04PM -0700, Andrew Morton wrote:
> I read the documentation but I still don't understand this feature. What > does the stacktrace actually do? It gets stored somewhere and displayed > later? What's it all for?
For example someone may want to inject kmalloc()/kmem_cache_alloc() failures into only e100 module. they want to inject not only direct kmalloc() call, but also indirect allocation, too.
- e100_poll --> netif_receive_skb --> packet_rcv_spkt --> skb_clone --> kmem_cache_alloc
This patch enables to detect function calls like this by stacktrace and inject failures. The script Documentaion/fault-injection/failmodule.sh helps it.
The range of text section of loaded e100 is expected to be [/sys/module/e100/sections/.text, /sys/module/e100/sections/.exit.text)
So failmodule.sh stores these values into /debug/failslab/address-start and /debug/failslab/address-end.
> > --- 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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |