From patchwork Sun Apr 10 20:06:22 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sergei Trofimovich X-Patchwork-Id: 696971 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter1.kernel.org (8.14.4/8.14.3) with ESMTP id p3AK4Bhp018512 for ; Sun, 10 Apr 2011 20:04:11 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752616Ab1DJUDz (ORCPT ); Sun, 10 Apr 2011 16:03:55 -0400 Received: from mail-fx0-f46.google.com ([209.85.161.46]:46131 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751769Ab1DJUDy (ORCPT ); Sun, 10 Apr 2011 16:03:54 -0400 Received: by fxm17 with SMTP id 17so3190797fxm.19 for ; Sun, 10 Apr 2011 13:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type; bh=sQ/hFSVrPr8wpkSirejudnCQ/6kMIAlIaIvto7zJGBk=; b=yHEwaoegiR9LTZJ+vTmcOaOtw1VYfcfpmvlNc76Je1OyD73mNLQJqwO+IQIhcn2iFI wgWTnBqEzLpOCTI+UADoRYaNVC6yUvnviWoo7+bnKD8XhdOhWcb3zbD2xgu2RJIfAi/8 lVjE5IMfTY0VsMPRB4UqPCXu7Xy/JXHEajxNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=k1P5BrXyI0PCxSQQzJPtuyokPe+et+sL0faoB1qH7g94FmVADUV9mslWGrxlIK3lAx gafVsp3c9DKCyUy6pNEit5k3pHLWHxVCaBQpqsK/Z4fAEDze6ZgLEMQMCUkvp72hNP0Q VoqkTz0jnSwO3U9VJbfi/GFalAZbctPE6T//Y= Received: by 10.223.55.201 with SMTP id v9mr161193fag.76.1302465832877; Sun, 10 Apr 2011 13:03:52 -0700 (PDT) Received: from sf ([178.125.152.109]) by mx.google.com with ESMTPS id 21sm1432399fav.41.2011.04.10.13.03.51 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2011 13:03:52 -0700 (PDT) Date: Sun, 10 Apr 2011 23:06:22 +0300 From: Sergei Trofimovich To: Sergei Trofimovich , chris.mason@oracle.com Cc: linux-btrfs@vger.kernel.org, cwillu Subject: Re: btrfs does not work on usermode linux Message-ID: <20110410230622.09e965ae@sf> In-Reply-To: <20110410184249.483d8d67@sf> References: <20110410133710.0ef34cb6@sf> <20110410184249.483d8d67@sf> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Sun, 10 Apr 2011 20:04:11 +0000 (UTC) > > According to https://btrfs.wiki.kernel.org/index.php/Debugging_Btrfs_with_GDB > > UML did work once. > > > > Now it corrupts data and triggers BUG_ON once you > > start to use it. I tried both 2.6.38 and 2.6.39-rc2 (x86_64) > > I need some help to track it down. > > > > doing 'touch `seq 1 11`; rm 11' kills the kernel: > > 2.6.36 works 2.6.37 doesn't. bsecting Bisected down to: commit 59daa706fbec745684702741b9f5373142dd9fdc (v2.6.36-rc2-2-g59daa70) Author: Ma Ling Date: Tue Jun 29 03:24:25 2010 +0800 x86, mem: Optimize memcpy by avoiding memory false dependece Which means btrfs passes overlapping areas to memcpy. I've added some debug info and found out rough place: touching files 1 .. 11 #run> touch 1 2 3 4 5 6 7 8 9 10 11 [ 2.270000] memcpy overlap detected: memcpy(dst=0000000070654e8a, src=0000000070654ea9, size=171) [delta=31] [ 2.270000] ------------[ cut here ]------------ [ 2.270000] WARNING: at /home/slyfox/linux-2.6/fs/btrfs/memcpy_debug.c:18 btrfs_memcpy+0x52/0x68() [ 2.270000] Call Trace: [ 2.270000] 7064b748: [<600eff46>] map_extent_buffer+0x62/0x9e [ 2.270000] 7064b758: [<60029ad9>] warn_slowpath_common+0x59/0x70 [ 2.270000] 7064b798: [<60029b05>] warn_slowpath_null+0x15/0x17 [ 2.270000] 7064b7a8: [<6011129e>] btrfs_memcpy+0x52/0x68 [ 2.270000] 7064b7d8: [<600efa01>] memcpy_extent_buffer+0x18d/0x1da [ 2.270000] 7064b858: [<600efae2>] memmove_extent_buffer+0x94/0x208 [ 2.270000] 7064b8d8: [<600bc4b0>] setup_items_for_insert+0x2b8/0x426 [ 2.270000] 7064b8e8: [<600bb25a>] btrfs_leaf_free_space+0x62/0xa6 [ 2.270000] 7064b9c8: [<600c13f3>] btrfs_insert_empty_items+0xa3/0xb5 [ 2.270000] 7064ba38: [<600ce690>] insert_with_overflow+0x33/0xf1 [ 2.270000] 7064ba88: [<600ce7d4>] btrfs_insert_dir_item+0x86/0x268 [ 2.270000] 7064bae8: [<601b498b>] _raw_spin_unlock+0x9/0xb [ 2.270000] 7064bb48: [<600ddef1>] btrfs_add_link+0x10d/0x170 [ 2.270000] 7064bbc8: [<600ddf7a>] btrfs_add_nondir+0x26/0x52 [ 2.270000] 7064bc08: [<600de73f>] btrfs_create+0xf2/0x1c0 [ 2.270000] 7064bc18: [<6007ccff>] generic_permission+0x57/0x9d [ 2.270000] 7064bc68: [<6007cf60>] vfs_create+0x6a/0x75 which is in extent_io:copy_pages. I haven't dig further only made sure the following patch below (practically converts copy_pages to move_pages). It certainly does not look the right thing, but I don't understand extent_io contents yet to understand what actually happened. diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 20ddb28..4cab7db 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -3893,14 +3893,17 @@ static void copy_pages(struct page *dst_page, struct page *src_page, char *src_kaddr; if (dst_page != src_page) + { src_kaddr = kmap_atomic(src_page, KM_USER1); + memcpy(dst_kaddr + dst_off, src_kaddr + src_off, len); + kunmap_atomic(src_kaddr, KM_USER1); + } else + { src_kaddr = dst_kaddr; - - memcpy(dst_kaddr + dst_off, src_kaddr + src_off, len); + memmove(dst_kaddr + dst_off, src_kaddr + src_off, len); + } kunmap_atomic(dst_kaddr, KM_USER0); - if (dst_page != src_page) - kunmap_atomic(src_kaddr, KM_USER1); } void memcpy_extent_buffer(struct extent_buffer *dst, unsigned long dst_offset,