Description of problem: We're currently working around the act of downgrading a write lock into a read lock due to the complexity of the implementation (updating data structures with reference counts). After GA, need to revisit and implement rather than working around. Version-Release number of selected component (if applicable): kernel-rt-2.6.24.4-49.el5rt How reproducible: LTP tests make use of sys_remap_file_pages() which triggers this Steps to Reproduce: 1. login to test machine with LTP installed 2. as root start LTP test with 'runltp' script 3. look for traceback on console Actual results: WARNING: at kernel/rtmutex.c:1687 rt_read_fastunlock() Pid: 7370, comm: remap_file_page Not tainted 2.6.24.7-50.el5rt #1 Call Trace: [<ffffffff8105ee4f>] rt_mutex_up_read+0x36/0x201 [<ffffffff8105f8c9>] rt_up_read+0x9/0xb [<ffffffff81091f21>] sys_remap_file_pages+0x359/0x38c [<ffffffff8100c31e>] tracesys+0xdc/0xe1 WARNING: at kernel/rtmutex.c:1688 rt_read_fastunlock() Pid: 7370, comm: remap_file_page Not tainted 2.6.24.7-50.el5rt #1 Call Trace: [<ffffffff8105ee7b>] rt_mutex_up_read+0x62/0x201 [<ffffffff8105f8c9>] rt_up_read+0x9/0xb [<ffffffff81091f21>] sys_remap_file_pages+0x359/0x38c [<ffffffff8100c31e>] tracesys+0xdc/0xe1 Expected results: no traceback on console
Created attachment 304981 [details] Patch to workaround lack of rt_downgrade_write This patch is a workaround to deal with the lack of a true downgrade mechanism for write-locks.
Created attachment 306254 [details] patch to implement downgrade write This patch implements the downgrade write. It is a bit complex and not trivial so I would suggest keeping the work around (avoiding the call to downgrade_write). I will continue to run rwlock torture tests to test all this code. When I am satisfied with the results, I will notify Clark to remove the work around. This BZ should remain open until that time. (otherwise I might forget ;-)
pulling downgrade workaround in upcoming -70 kernel build for testing
Fixed a long time ago...