On Fri, 13 Nov 2015 14:54:37 -0800 (PST) David Rientjes <rientjes@xxxxxxxxxx> wrote: > [...] This is why > failslab had been used in the past, and does a good job at runtime > testing. Thanks for mentioning CONFIG_FAILSLAB. First I disregarded "failslab" (I did notice it in the slub code) because it didn't exercised the code path I wanted in kmem_cache_alloc_bulk(). But went to looking up the config setting I notice that we do have a hole section for "Fault-injection". Which is great, and what I was looking for. Menu config Location: -> Kernel hacking -> Fault-injection framework (FAULT_INJECTION [=y]) I think what I need can be covered by FAIL_PAGE_ALLOC, or should_fail_alloc_page(). I'll try and play a bit with it... - - Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer [*] Fault-injection framework [*] Fault-injection capability for kmalloc [*] Fault-injection capabilitiy for alloc_pages() [ ] Fault-injection capability for disk IO [ ] Fault-injection capability for faking disk interrupts [ ] Fault-injection capability for futexes [*] Debugfs entries for fault-injection capabilities -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>