Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR
From: Dave Jones
Date: Mon Dec 14 2015 - 13:34:40 EST
On Sat, Dec 12, 2015 at 07:07:46PM -0500, Chris Mason wrote:
> On Sat, Dec 12, 2015 at 11:41:26AM -0800, Linus Torvalds wrote:
> > On Sat, Dec 12, 2015 at 10:33 AM, Linus Torvalds
> > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > Peter, did that patch also handle just plain "lock_page()" case?
> >
> > Looking more at it, I think this all goes back to commit 743162013d40
> > ("sched: Remove proliferation of wait_on_bit() action functions").
> >
> > It looks like PeterZ's pending patch should fix this, by passing in
> > the proper TASK_UNINTERRUPTIBLE to the bit_wait_io function, and going
> > back to signal_pending_state(). PeterZ, did I follow the history of
> > this correctly?
>
> Looks right to me, I found Peter's patch and have it running now. After
> about 6 hours my patch did eventually crash again under trinity. Btrfs has a
> very old (from 2011) bug in the error handling path that trinity is
> banging on.
Is the other bug this one ? I've hit this quite a lot over the last 12 months,
and now that the lock_page bug is fixed this is showing up again.
page:ffffea00110d2700 count:4 mapcount:0 mapping:ffff88045b5160a0 index:0x0
flags: 0x8000000000000806(error|referenced|private)
page dumped because: VM_BUG_ON_PAGE(!PageLocked(page))
------------[ cut here ]------------
kernel BUG at mm/filemap.c:812!
invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
CPU: 1 PID: 22062 Comm: trinity-c4 Tainted: G W 4.4.0-rc5-think+ #1
task: ffff8800bce51b80 ti: ffff8803f7210000 task.ti: ffff8803f7210000
RIP: 0010:[<ffffffffad25e3c7>] [<ffffffffad25e3c7>] unlock_page+0xa7/0xb0
RSP: 0018:ffff8803f72176b8 EFLAGS: 00010292
RAX: fffff9400221a4e0 RBX: 0000000000001000 RCX: 0000000000000000
RDX: dffffc0000000000 RSI: ffffffffad144aee RDI: ffffea00110d2700
RBP: ffff8803f72176d8 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000001 R12: ffffea00110d2700
R13: 0000000000000000 R14: ffffea00110d2700 R15: 0000000000000000
FS: 00007f82b1f73700(0000) GS:ffff880468a00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000389120 CR3: 000000040bc54000 CR4: 00000000001406e0
Stack:
0000000000001000 0000000000000000 0000000000000000 ffffea00110d2700
ffff8803f7217898 ffffffffc010b777 0000000000000000 ffff880302400040
0000000000000000 ffff8803f7217728 ffff8803f7217728 ffff8803f7217760
Call Trace:
[<ffffffffc010b777>] __do_readpage+0xa97/0xd80 [btrfs]
[<ffffffffad13351f>] ? mark_lock+0x6f/0x8a0
[<ffffffffadcea0ac>] ? _raw_spin_unlock_irq+0x2c/0x50
[<ffffffffc00db310>] ? btrfs_real_readdir+0x8d0/0x8d0 [btrfs]
[<ffffffffc010ace0>] ? extent_write_cache_pages.isra.37.constprop.54+0x540/0x540 [btrfs]
[<ffffffffad153fea>] ? rcu_read_lock_sched_held+0x8a/0xa0
[<ffffffffad25e9c4>] ? __add_to_page_cache_locked+0x464/0x500
[<ffffffffc010bb66>] __extent_read_full_page+0x106/0x120 [btrfs]
[<ffffffffc00db310>] ? btrfs_real_readdir+0x8d0/0x8d0 [btrfs]
[<ffffffffc010c09d>] extent_read_full_page+0xad/0x110 [btrfs]
[<ffffffffc010bff0>] ? set_page_extent_mapped+0x30/0x30 [btrfs]
[<ffffffffad122f70>] ? __wake_up_locked_key+0x20/0x20
[<ffffffffad25ea80>] ? add_to_page_cache_locked+0x20/0x20
[<ffffffffad25f4fb>] ? find_get_entry+0x14b/0x270
[<ffffffffad25f3b5>] ? find_get_entry+0x5/0x270
[<ffffffffc00d7a00>] btrfs_readpage+0x40/0x50 [btrfs]
[<ffffffffc00f17f9>] prepare_uptodate_page+0x39/0x80 [btrfs]
[<ffffffffc00f19de>] prepare_pages+0x19e/0x210 [btrfs]
[<ffffffffc00f2d21>] __btrfs_buffered_write+0x351/0x8a0 [btrfs]
[<ffffffffc00f29d0>] ? btrfs_dirty_pages+0xf0/0xf0 [btrfs]
[<ffffffffad2619aa>] ? generic_file_direct_write+0x1aa/0x2c0
[<ffffffffad261800>] ? generic_file_read_iter+0xa00/0xa00
[<ffffffffc00f866d>] btrfs_file_write_iter+0x6dd/0x800 [btrfs]
[<ffffffffad2f694d>] __vfs_write+0x21d/0x260
[<ffffffffad2f6730>] ? __vfs_read+0x260/0x260
[<ffffffffad12ed32>] ? __lock_is_held+0x92/0xd0
[<ffffffffad0ee3b1>] ? preempt_count_sub+0xc1/0x120
[<ffffffffad12cd17>] ? percpu_down_read+0x57/0xa0
[<ffffffffad2fbd24>] ? __sb_start_write+0xb4/0xf0
[<ffffffffad2f7736>] vfs_write+0xf6/0x260
[<ffffffffad2f8d4f>] SyS_write+0xbf/0x160
[<ffffffffad2f8c90>] ? SyS_read+0x160/0x160
[<ffffffffad002017>] ? trace_hardirqs_on_thunk+0x17/0x19
[<ffffffffadceab17>] entry_SYSCALL_64_fastpath+0x12/0x6b
Code: 48 8d 14 80 48 8d 04 50 31 d2 49 8d 3c c6 e8 c1 4b ec ff 5b 41 5c 41 5d 41 5e 5d c3 48 c7 c6 e0 3a ec ad 4c 89 e7 e8 49 22 04 00 <0f> 0b 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 48 89
RIP [<ffffffffad25e3c7>] unlock_page+0xa7/0xb0
RSP <ffff8803f72176b8>
---[ end trace 5d1ded6801ca2e6c ]---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/