| To: | Christoph Hellwig <hch@xxxxxx> |
|---|---|
| Subject: | Re: [PATCH] kill superflous buffer locking |
| From: | Lachlan McIlroy <lachlan@xxxxxxx> |
| Date: | Thu, 18 Oct 2007 14:13:45 +1000 |
| Cc: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20070924184926.GA20661@lst.de> |
| References: | <20070924184926.GA20661@lst.de> |
| Reply-to: | lachlan@xxxxxxx |
| Sender: | xfs-bounce@xxxxxxxxxxx |
| User-agent: | Thunderbird 2.0.0.4 (X11/20070604) |
Christoph, We've had to reverse this change because it's caused a regression. We haven't been able to identify why we see the following assertion trigger with these changes but the assertion goes away without the changes. Until we figure out why we'll have to leave the buffer locking in. <5>XFS mounting filesystem hdb2 <5>Starting XFS recovery on filesystem: hdb2 (logdev: internal) <4>XFS: xlog_recover_process_data: bad clientid <4>Assertion failed: 0, file: fs/xfs/xfs_log_recover.c, line: 2912 <0>------------[ cut here ]------------ <2>kernel BUG at fs/xfs/support/debug.c:81! <0>invalid opcode: 0000 [#1] <0>SMP <4>Modules linked in: <0>CPU: 2 <0>EIP: 0060:[<c028a125>] Not tainted VLI <0>EFLAGS: 00010286 (2.6.23-kali-26_xfs-debug #1) <0>EIP is at assfail+0x1e/0x22 <0>eax: 00000043 ebx: f3002a50 ecx: 00000001 edx: 00000086 <0>esi: f56e2300 edi: f8fa5c28 ebp: efa67ae4 esp: efa67ad4 <0>ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 <0>Process mount (pid: 15191, ti=efa66000 task=f7b43570 task.ti=efa66000) <0>Stack: c05c8bda c05c6762 c05c4750 00000b60 efa67b1c c0269a35 00000004 c05c5903 <0> f3a14000 efa67ba8 f7e458c0 f8fa5c34 efa67bb8 f8fa6a38 0000000d 00001e00 <0> f8fa4000 00000000 efa67bf4 c026a566 f8fa4000 00000001 00000651 00000000 <0>Call Trace: <0> [<c0105eb6>] show_trace_log_lvl+0x1a/0x2f <0> [<c0105f66>] show_stack_log_lvl+0x9b/0xa3 <0> [<c0106127>] show_registers+0x1b9/0x28b <0> [<c0106312>] die+0x119/0x27b <0> [<c04d5748>] do_trap+0x8a/0xa3 <0> [<c0106733>] do_invalid_op+0x88/0x92 <0> [<c04d551a>] error_code+0x72/0x78 <0> [<c0269a35>] xlog_recover_process_data+0x6a/0x1ff <0> [<c026a566>] xlog_do_recovery_pass+0x810/0x9f3 <0> [<c026a7ab>] xlog_do_log_recovery+0x62/0xe2 <0> [<c026a848>] xlog_do_recover+0x1d/0x187 <0> [<c026bd17>] xlog_recover+0x88/0x95 <0> [<c0264d9d>] xfs_log_mount+0x100/0x144 <0> [<c026ea6f>] xfs_mountfs+0x278/0x639 <0> [<c0277917>] xfs_mount+0x25c/0x2f7 <0> [<c0289952>] xfs_fs_fill_super+0xab/0x1fd <0> [<c0164677>] get_sb_bdev+0xd6/0x114 <0> [<c0288c38>] xfs_fs_get_sb+0x21/0x27 <0> [<c0164181>] vfs_kern_mount+0x41/0x7a <0> [<c0164209>] do_kern_mount+0x37/0xbd <0> [<c0175abe>] do_mount+0x566/0x5c0 <0> [<c0175b87>] sys_mount+0x6f/0xa9 <0> [<c0104e7e>] sysenter_past_esp+0x5f/0x85 <0> ======================= <0>Code: 04 24 10 00 00 00 e8 2a e7 03 00 c9 c3 55 89 e5 83 ec 10 89 4c 24 0c 89 54 24 08 89 44 24 04 c7 04 24 da 8b 5c c0 e8 07 bf e9 ff <0f> 0b eb fe 55 83 e0 07 89 e5 57 bf 07 00 00 00 56 89 d6 53 89 <0>EIP: [<c028a125>] assfail+0x1e/0x22 SS:ESP 0068:efa67ad4 Lachlan Christoph Hellwig wrote: There is no need to lock any page in xfs_buf.c because we operate on our own address_space and all locking is covered by the buffer semaphore. If we ever switch back to main blockdeive address_space as suggested e.g. for fsblock with a similar scheme the locking will have to be totally revised anyway because the current scheme is neither correct nor coherent with itself. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | 971596 971186 - Undo mod xfs-linux-melb:xfs-kern:29845a due to a regression, Lachlan McIlroy |
|---|---|
| Next by Date: | Re: [PATCH] flush inode when changing atime., David Chinner |
| Previous by Thread: | 971596 971186 - Undo mod xfs-linux-melb:xfs-kern:29845a due to a regression, Lachlan McIlroy |
| Next by Thread: | TAKE 969769 - Fix dbflush panic in xfs_qm_sync, donaldd |
| Indexes: | [Date] [Thread] [Top] [All Lists] |