Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932388AbaJVCBj (ORCPT ); Tue, 21 Oct 2014 22:01:39 -0400 Received: from resqmta-ch2-05v.sys.comcast.net ([69.252.207.37]:60132 "EHLO resqmta-ch2-05v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753763AbaJVCBh (ORCPT ); Tue, 21 Oct 2014 22:01:37 -0400 X-Greylist: delayed 367 seconds by postgrey-1.27 at vger.kernel.org; Tue, 21 Oct 2014 22:01:37 EDT Message-ID: <54470F65.6010703@pobox.com> Date: Tue, 21 Oct 2014 18:59:01 -0700 From: Robert White User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Qu Wenruo , Dave Jones , Linux Kernel , clm@fb.com, jbacik@fb.com, linux-btrfs@vger.kernel.org Subject: Re: [3.18rc1] btrfs triggering vm bug_on References: <20141021215731.GA10296@redhat.com> <5446FF71.7000606@cn.fujitsu.com> <54470E8F.6060409@pobox.com> In-Reply-To: <54470E8F.6060409@pobox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pre-Script :: this is not an 3.18 problem. I traced it out in 3.16. On 10/21/2014 06:55 PM, Robert White wrote: > It _looks_ like a hard out-of-ram event and not necessarily a filesystem > implementation problem. > > One of the systems I work with has zero swap but still allows overcommit > in the VM. It would do things like this all the time back in development > (and I suspect it still does but the developers got rid of those pesky > logs). Not necessarily this exact error, but lots of them with the same > "feel". > > You are actually triggering two bugs, only the second being in btrfs code. > > The VM_BUG_ON_PAGE() in cleancache_get_page() (mm/cleancache.c) is going > off first. This is presumably the ram exhaustion event, which is an > outer problem taking place in your system (e.g. the real cause). > > > > This floats back to the __do_readpage() which doesn't (and almost > cannot) figure out how the page validation failed > > if (!PageUptodate(page)) { > if (cleancache_get_page(page) == 0) { > BUG_ON(blocksize != PAGE_SIZE); > unlock_extent(tree, start, end); > goto out; > } > } > > > > Which (improperly) ends with this suspect bit from the out: in > __do_readpage() where the unlock_page() is called unconditionally. > > out: > if (!nr) { > if (!PageError(page)) > SetPageUptodate(page); > unlock_page(page); > } > > I _think_ the call to unlock_page() _should_ have an if > (PageLocked(page)) in front of it. > > --- extent_io.c 2014-09-19 03:26:21.058266026 -0700 > +++ extent_io.c 2014-10-21 18:52:45.127713115 -0700 > @@ -2960,7 +2960,8 @@ > if (!nr) { > if (!PageError(page)) > SetPageUptodate(page); > - unlock_page(page); > + if (PageLocked(page)) > + unlock_page(page); > } > return 0; > } > > That said, the question of what your system is going to do with the VM > memory exhausted is a bigger problem. > > -- Rob. > > On 10/21/2014 05:50 PM, Qu Wenruo wrote: >> Any reproducer? >> >> Thanks, >> Qu >> -------- Original Message -------- >> Subject: [3.18rc1] btrfs triggering vm bug_on >> From: Dave Jones >> To: Linux Kernel >> Date: 2014年10月22日 05:57 >>> page:ffffea00088aa1c0 count:4 mapcount:0 mapping:ffff88009901e2d8 >>> index:0x0 >>> flags: 0x2ffc0000000806(error|referenced|private) >>> page dumped because: VM_BUG_ON_PAGE(!PageLocked(page)) >>> ------------[ cut here ]------------ >>> kernel BUG at mm/filemap.c:747! >>> invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC >>> Modules linked in: fuse snd_seq_dummy tun binfmt_misc usb_debug bnep >>> rfcomm nfnetlink scsi_transport_iscsi hidp af_key llc2 can_bcm can_raw >>> nfc caif_socket caif >>> af_802154 ieee802154 phonet af_rxrpc bluetooth can pppoe pppox >>> ppp_generic slhc irda crc_ccitt rds rose sctp libcrc32c x25 atm netrom >>> appletalk ipx p8023 psnap p8022 llc ax25 c >>> fg80211 rfkill btrfs xor coretemp hwmon x86_pkg_temp_thermal kvm_intel >>> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi kvm >>> snd_hda_intel snd_hda_controller snd_h >>> da_codec snd_hwdep crct10dif_pclmul snd_seq crc32c_intel >>> ghash_clmulni_intel e1000e snd_seq_device raid6_pq snd_pcm microcode >>> snd_timer serio_raw snd pcspkr ptp pps_core shpchp >>> soundcore nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc >>> CPU: 3 PID: 6466 Comm: trinity-c402 Not tainted 3.18.0-rc1+ #72 >>> task: ffff88003ec22f00 ti: ffff88006f3ac000 task.ti: ffff88006f3ac000 >>> RIP: 0010:[] [] >>> unlock_page+0x7f/0x90 >>> RSP: 0018:ffff88006f3afa08 EFLAGS: 00010292 >>> RAX: 0000000000000036 RBX: 0000000000001000 RCX: 0000000000000006 >>> RDX: 0000000000000000 RSI: ffffffffbb843c53 RDI: ffffffffbb0e399e >>> RBP: ffff88006f3afa08 R08: 0000000000000001 R09: 0000000000000001 >>> R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000c2b >>> R13: 0000000000000000 R14: ffffea00088aa1c0 R15: 0000000000000000 >>> FS: 00007f7e30942740(0000) GS:ffff880244e00000(0000) >>> knlGS:0000000000000000 >>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>> CR2: 00007f7e2d8b8000 CR3: 0000000098e56000 CR4: 00000000001407e0 >>> DR0: 000000000219e000 DR1: 0000000000de8000 DR2: 0000000000000000 >>> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 >>> Stack: >>> ffff88006f3afb28 ffffffffc05adf78 ffffffffc05ae375 ffff88006f3afa70 >>> ffffffffbb03d193 ffffffffbb0b25c5 ffffffffc05adb10 0000000000000000 >>> 00000000211ce98b 0000000000000000 ffff88006f3afbd0 ffff880222a87000 >>> Call Trace: >>> [] __do_readpage+0x468/0x7a0 [btrfs] >>> [] ? __extent_read_full_page+0xc5/0xe0 [btrfs] >>> [] ? prepare_ftrace_return+0x73/0xe0 >>> [] ? preempt_count_sub+0x5/0x100 >>> [] ? >>> extent_write_cache_pages.isra.30.constprop.48+0x440/0x440 [btrfs] >>> [] ? btrfs_writepage_end_io_hook+0x360/0x360 [btrfs] >>> [] ? preempt_count_sub+0x7b/0x100 >>> [] ? ftrace_graph_caller+0x5a/0x85 >>> [] __extent_read_full_page+0xc5/0xe0 [btrfs] >>> [] ? btrfs_writepage_end_io_hook+0x360/0x360 [btrfs] >>> [] ? ftrace_graph_caller+0x5a/0x85 >>> [] extent_read_full_page+0x46/0x80 [btrfs] >>> [] btrfs_readpage+0x25/0x30 [btrfs] >>> [] prepare_uptodate_page+0x38/0xa0 [btrfs] >>> [] prepare_pages.isra.19+0x10c/0x1a0 [btrfs] >>> [] __btrfs_buffered_write+0x1e4/0x5f0 [btrfs] >>> [] ? ftrace_graph_caller+0x5a/0x85 >>> [] btrfs_file_write_iter+0x3ce/0x550 [btrfs] >>> [] ? cap_inode_getsecid+0x20/0x20 >>> [] ? new_sync_read+0xd0/0xd0 >>> [] new_sync_write+0x8e/0xd0 >>> [] ? ftrace_graph_caller+0x5a/0x85 >>> [] vfs_write+0xba/0x1f0 >>> [] SyS_write+0x58/0xd0 >>> [] tracesys_phase2+0xd4/0xd9 >>> Code: 48 8d 0c 92 48 8d 0c 4a 48 8b 96 98 00 00 00 48 89 c6 48 8d 3c >>> ca 31 d2 e8 df d5 f2 ff 5d c3 48 c7 c6 38 81 c7 bb e8 01 ff 02 00 <0f> >>> 0b 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 e8 6b 60 6b >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe >>> linux-btrfs" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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/