Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1291520

Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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