Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1291520
| From | Chris Mason <clm@fb.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR |
| Date | 2015-12-14 21:10 +0100 |
| Message-ID | <qFHBw-2sR-7@gated-at.bofh.it> (permalink) |
| References | <qEVdw-4sK-11@gated-at.bofh.it> <qEXfj-5Kv-5@gated-at.bofh.it> <qEYl5-6qE-49@gated-at.bofh.it> <qF2oG-SX-13@gated-at.bofh.it> <qFGcq-1pc-29@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
> > > <torvalds@linux-foundation.org> 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 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/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR Chris Mason <clm@fb.com> - 2015-12-12 17:30 +0100
Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-12 19:40 +0100
Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-12 20:50 +0100
Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR Chris Mason <clm@fb.com> - 2015-12-13 01:10 +0100
Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR Dave Jones <dsj@fb.com> - 2015-12-14 19:40 +0100
Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR Chris Mason <clm@fb.com> - 2015-12-14 21:10 +0100
Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR Chris Mason <clm@fb.com> - 2015-12-15 01:10 +0100
Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR Peter Zijlstra <peterz@infradead.org> - 2015-12-13 11:00 +0100
Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR Chris Mason <clm@fb.com> - 2015-12-13 17:00 +0100
Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-13 22:00 +0100
Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR Peter Zijlstra <peterz@infradead.org> - 2015-12-13 22:20 +0100
csiph-web