Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753407AbbLNSeg (ORCPT ); Mon, 14 Dec 2015 13:34:36 -0500 Received: from mx0a-00082601.pphosted.com ([67.231.145.42]:24991 "EHLO mx0a-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752082AbbLNSee (ORCPT ); Mon, 14 Dec 2015 13:34:34 -0500 Date: Mon, 14 Dec 2015 13:33:56 -0500 From: Dave Jones To: Chris Mason , Linus Torvalds , Peter Zijlstra , LKML , Jon Christopherson , NeilBrown , Ingo Molnar , David Howells , Steven Whitehouse Subject: Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR Message-ID: <20151214183356.GA5251@fb.com> Mail-Followup-To: Dave Jones , Chris Mason , Linus Torvalds , Peter Zijlstra , LKML , Jon Christopherson , NeilBrown , Ingo Molnar , David Howells , Steven Whitehouse References: <20151212162342.GF11257@ret.masoncoding.com>

<20151213000746.GA26204@clm-mbp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20151213000746.GA26204@clm-mbp.thefacebook.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2015-12-14_12:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4917 Lines: 90 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 > > 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:[] [] 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: [] __do_readpage+0xa97/0xd80 [btrfs] [] ? mark_lock+0x6f/0x8a0 [] ? _raw_spin_unlock_irq+0x2c/0x50 [] ? btrfs_real_readdir+0x8d0/0x8d0 [btrfs] [] ? extent_write_cache_pages.isra.37.constprop.54+0x540/0x540 [btrfs] [] ? rcu_read_lock_sched_held+0x8a/0xa0 [] ? __add_to_page_cache_locked+0x464/0x500 [] __extent_read_full_page+0x106/0x120 [btrfs] [] ? btrfs_real_readdir+0x8d0/0x8d0 [btrfs] [] extent_read_full_page+0xad/0x110 [btrfs] [] ? set_page_extent_mapped+0x30/0x30 [btrfs] [] ? __wake_up_locked_key+0x20/0x20 [] ? add_to_page_cache_locked+0x20/0x20 [] ? find_get_entry+0x14b/0x270 [] ? find_get_entry+0x5/0x270 [] btrfs_readpage+0x40/0x50 [btrfs] [] prepare_uptodate_page+0x39/0x80 [btrfs] [] prepare_pages+0x19e/0x210 [btrfs] [] __btrfs_buffered_write+0x351/0x8a0 [btrfs] [] ? btrfs_dirty_pages+0xf0/0xf0 [btrfs] [] ? generic_file_direct_write+0x1aa/0x2c0 [] ? generic_file_read_iter+0xa00/0xa00 [] btrfs_file_write_iter+0x6dd/0x800 [btrfs] [] __vfs_write+0x21d/0x260 [] ? __vfs_read+0x260/0x260 [] ? __lock_is_held+0x92/0xd0 [] ? preempt_count_sub+0xc1/0x120 [] ? percpu_down_read+0x57/0xa0 [] ? __sb_start_write+0xb4/0xf0 [] vfs_write+0xf6/0x260 [] SyS_write+0xbf/0x160 [] ? SyS_read+0x160/0x160 [] ? trace_hardirqs_on_thunk+0x17/0x19 [] 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 [] unlock_page+0xa7/0xb0 RSP ---[ end trace 5d1ded6801ca2e6c ]--- -- 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/