Re: [LTP] futex syscall tests

[Darren Hart <dvhltc@us.ibm.com>]

Mike Frysinger wrote:
> are there any futex syscall tests already in ltp that i cant seem to locate ?  
> if not, i can adapt the few that already exist in the libfutex code ...
> -mike

Mike,

I recently done a lot of cleanup and a couple feature additions to the
kernel futex code.  In doing so I was noticing the lack of a good futex
system call test suite.  I had started a writeup of what such a test
suite should accomplish.  I hadn't decided if I wanted to push it to LTP
eventually or not.  As it sounds like you may have similar interests in
this test, please find my very early, very incomplete, initial thoughts
on such a testsuite.

I'd welcome your thoughts on approach, direction, etc.

-------------------------------------------------------------------------------

The following is a start at what I hope to be a design document for a new
exhaustive futex functional/performance/stress benchmark. Before I flesh it
out any further, I'd really appreciate some feedback on what I have so far.

Given the number of permutations each test seems to require, I think some kind
of "test generator" is needed. We will have to describe the permutations and
pass them to the test generator so it can create the various versions of the
tests.

HAVOC FUTEX
===========

Havoc Futex is intended to thoroughly test the Linux kernel futex system call
API. To the extent possible, each test is implemented using raw system calls
as well as the glibc pthread library.

Futex Op Codes
--------------
FUTEX_WAIT
FUTEX_WAKE
FUTEX_FD
FUTEX_REQUEUE
FUTEX_CMP_REQUEUE
FUTEX_WAKE_OP
FUTEX_LOCK_PI
FUTEX_UNLOCK_PI
FUTEX_TRYLOCK_PI
FUTEX_WAIT_BITSET
FUTEX_WAKE_BITSET
FUTEX_WAIT_REQUEUE_PI
FUTEX_CMP_REQUEUE_PI

Syscalls to Test
----------------
futex_wake
futex_wake_op
futex_requeue
futex_wait
futex_lock_pi
futex_unlock_pi
futex_wait_requeue_pi

Functional Tests
----------------
requeue_pi/*
	Exercise the FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI op codes,
	under every possible combination of the following scenarios:

	o shared and private futexes
	o CLOCK_MONOTONIC and CLOCK_REALTIME timeouts (and none)
	o Signal handling prior to and post requeue
	o correct and incorrect settings for val
	o target futex owned by waker, owned by third party, unowned
	o OWNERDIED reclaim of mutex
	o ensure priority ordered wakeup of waiters

	Error and Misuse Cases
	----------------------
	o mixed shared and private futexes (should fail)
	o pi source futex
	o non-pi target futex
	o unmapped shared futex fault handling
	o bogus uaddrs
	o invalid nr_wake and nr_requeue values
	o mismatched wait_requeue and futex_requeue target futexes
	o incorrect pairing of futex_wait_requeue_pi with futex_wake

	Syscalls Exercised
	------------------
	futex_wait_requeue_pi
	futex_requeue
	futex_lock_pi
	futex_unlock_pi

pi_lock/*
	Exercise the FUTEX_LOCK_PI and FUTEX_UNLOCK_PI op codes, under every
	possible combination of the following scenarious:

	o shared and private futexes
	o CLOCK_MONOTONIC and CLOCK_REALTIME timeouts (and none)
	o Signal handling
	o correct and incorrect settings for val
	o bogus uaddrs
	o contended and uncontended cases
	o OWNERDIED reclaim of mutex

	Error and Misuse Cases
	----------------------
	o pi_unlock of a non-pi-locked futex
	o pi_lock of an owned non-pi futex
	o unmapped shared futex fault handling
	o mismatched futex_lock_pi and futex_wake(_op)? calls
	o mismatched futex_wait and futex_unlock_pi calls

	Syscalls Exercised
	------------------
	futex_lock_pi
	futex_unlock_pi
	futex_wait
	futex_wake
	futex_wake_op

requeue/*
	Exercise the FUTEX_WAIT and the FUTEX_CMP_REQUEUE op codes.  Perform
	basic testing for FUTEX_REQUEUE, purposefully avoiding its known
	flaws.

	Error and Misuse Cases
	----------------------

	Syscalls Exercised
	------------------
	futex_wait
	futex_requeue

wait/*
	Exercise the FUTEX_WAIT and FUTEX_WAKE op codes.

	Error and Misuse Cases
	----------------------

	Syscalls Exercised
	------------------
	futex_wait
	futex_wake
	futex_wake_op



Performance Tests
-----------------
	o attempt to expose lock contention issues, such as those exposed by
	  calling futex_wait on an unowned futex
	o rapid lock and unlock of an uncontended futex
	o rapid lock and unlock of a heavily conteded futex
	o attempt to expose bottlenecks imposed by the shared hash-bucket
	  implementation
	o attempt to expose real-time scheduling overhead

Stress Tests
------------
	o thousands of threads/processes contending on a single futex
	o thousands of threads/processes on thousands of futexes

Other Thoughts
--------------
kernel-side futex fault injection
	There are a lot of places in futex.c that have to handle faults.  I
	think some kind of a fault injection system is needed.  This could be
	enabled via a sysctl or perhaps just configured in to a debug kernel.
	Running this test suite in a loop would allow us to achieve some
	statistical confidence in these numerous fault paths.

FUTEX_REQUEUE
	This op code is deprecated in favor of FUTEX_CMP_REQUEUE.  Do to the
	unreliable nature of the op code, only very limited testing can be
	performed.

-- 
Darren Hart
IBM Linux Technology Center
Real-Time Linux Team

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list