lkml.org 
[lkml]   [2006]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subject-rt patch scheduler w/ BKL
From
Date

The current -rt patch changes the scheduler so that the BKL is no longer
properly reacquired. If SPINLOCK_BKL is selected it's possible for
reacquire_kernel_lock() to return without acquiring the BKL, in vanilla
linux the return value of that function is evaluated, but in -rt that
code is removed. The result is that if __schedule gets recalled on
TIF_NEED_RESCHED the BKL will be released unconditionally ..

The following error is an example of the issue with spinlock debugging.
It happens pretty quickly when using NFS root ..

BUG: spinlock wrong owner on CPU#0, hotplug/699
lock: 803c5840, .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1
Call Trace:
[<8033e964>] _raw_spin_unlock+0xb8/0xd0
[<8033e964>] _raw_spin_unlock+0xb8/0xd0
[<8033c134>] schedule+0x48/0x128
[<8033c134>] schedule+0x48/0x128
[<8033ba90>] __schedule+0x7fc/0xcc4
[<803278f8>] xprt_timer+0x0/0xb0
[<8033e3dc>] __spin_lock_irqsave+0x30/0x44
[<802adad0>] kernel_sendmsg+0x24/0x38
[<8033e64c>] __spin_unlock_irqrestore+0x14/0x48
[<8032c468>] rpc_wait_bit_interruptible+0x2c/0x40
[<8032c43c>] rpc_wait_bit_interruptible+0x0/0x40
[<8033c134>] schedule+0x48/0x128
[<80141324>] prepare_to_wait+0x34/0x90
[<8032c468>] rpc_wait_bit_interruptible+0x2c/0x40
[<8032755c>] __xprt_lock_write_next_cong+0xac/0xcc
[<8032ba00>] rpc_sleep_on+0x40/0x60
[<8033cf50>] __wait_on_bit+0xbc/0x128
[<8033cf14>] __wait_on_bit+0x80/0x128
[<80327494>] xprt_end_transmit+0x40/0x5c
[<80327494>] xprt_end_transmit+0x40/0x5c
[<8032c43c>] rpc_wait_bit_interruptible+0x0/0x40
[<8033d038>] out_of_line_wait_on_bit+0x7c/0x98
[<80324fe0>] call_transmit_status+0x30/0x48
[<801fe370>] nfs_xdr_fhandle+0x0/0x54
[<80141178>] wake_bit_function+0x0/0x5c
[<8032c7b0>] __rpc_execute+0x168/0x2bc
[<8032c6e0>] __rpc_execute+0x98/0x2bc
[<80325374>] rpc_call_setup+0x90/0x98
[<803254c0>] rpc_call_sync+0xf4/0x110
[<801fa568>] nfs_wait_schedule+0x0/0x40
[<801ffef8>] nfs_proc_getattr+0x6c/0xc4
[<80135b94>] sigprocmask+0x180/0x220
[<80141178>] wake_bit_function+0x0/0x5c
[<801fa730>] __nfs_revalidate_inode+0x188/0x320
[<8015a6ac>] __generic_file_aio_read+0x108/0x2f4
[<80181124>] do_sync_read+0xdc/0x16c
[<801f9478>] nfs_file_open+0x0/0x9c
[<80204878>] nfs_sync_inode_wait+0x90/0x230
[<801fb424>] nfs_getattr+0xd0/0xd8
[<8017f400>] do_filp_open+0x5c/0x78
[<8018ee88>] vfs_fstat+0x34/0x58
[<8018ee6c>] vfs_fstat+0x18/0x58
[<8018eecc>] sys_fstat64+0x20/0x48
[<80181e14>] vfs_read+0x11c/0x1a0
[<801822e4>] remote_llseek+0x94/0x18c
[<8017bbb0>] kmem_cache_free+0x80/0xd4
[<80182680>] sys_read+0x7c/0x110
[<80182634>] sys_read+0x30/0x110
[<8017f4fc>] do_sys_open+0xe0/0x138
[<8010bcdc>] syscall_trace_entry+0x70/0x90
[<8010bcdc>] syscall_trace_entry+0x70/0x90


So I would imagine the solution is to put back the code that is in
vanilla linux which uses a "goto" to essentially reschedule avoided this
issue. However, I have no idea why the scheduler was changed to
schedule() --> __schedule() and the BKL checks removed, which is the
reason for this email ..

So anyone have thoughts on this?

Daniel

-
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/

\
 
 \ /
  Last update: 2006-11-15 03:29    [W:0.038 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site