On Mon, 16 Nov 2015 15:24:40 +0100 Jesper Dangaard Brouer <brouer@xxxxxxxxxx> wrote: > 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... I did manage to provoke/test the error path in kmem_cache_alloc_bulk(), by using fault-injection framework "fail_page_alloc". But was a little hard to trigger SLUB errors with this, because SLUB retries after a failure, and second call to alloc_pages() is done with lower order. If order is lowered to zero, then should_fail_alloc_page() will skip it. And just lowering /sys/kernel/debug/fail_page_alloc/min-order=0 is not feasible as even fork starts to fail. I managed to work-around this by using "space" setting. Created a script to ease this tricky invocation: https://github.com/netoptimizer/prototype-kernel/blob/master/tests/fault-inject/fail01_kmem_cache_alloc_bulk.sh -- 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 -- 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>