On Mon, Dec 14, 2015 at 01:33:56PM -0500, Dave Jones wrote: > 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 > > > <[email protected]> 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))
[ snip ] > [<ffffffffc00f17f9>] prepare_uptodate_page+0x39/0x80 [btrfs] > [<ffffffffc00f19de>] prepare_pages+0x19e/0x210 [btrfs] This should be the second call to prepare_uptodate_page() in prepare_pages(). If we get an error on the first call, and the write only spans a single page, we'll call prepare_uptodate_page a second time on an unlocked page. I'll send out the patch a little later this afternoon. > [<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 -chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
