linux-kernel - Re: [PATCH] lock_page() doesn't lock if __wait_on_bit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151214183356.GA5251@fb.com>
Date:	Mon, 14 Dec 2015 13:33:56 -0500
From:	Dave Jones <dsj@...com>
To:	Chris Mason <clm@...com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Jon Christopherson <jon@...s.org>, NeilBrown <neilb@...e.de>,
	Ingo Molnar <mingo@...nel.org>,
	David Howells <dhowells@...hat.com>,
	Steven Whitehouse <swhiteho@...hat.com>
Subject: Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns
 -EINTR

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@...ux-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))
------------[ 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/