kernel bug in file-item.c

kernel bug in file-item.c

[Marc R. O'Connor]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

I have had two 'kernel bug' issues today both referencing file-item.c.
The first oops happened when i was cp'ing from and external HD(ext3) to
and ext3 partition. The second happened during boot up. I have attached
them both.

Im using btrfs that was merged into my kernel yesterday.

-- 

--
Marc R. O'Connor
Information Systems
Camden County Board of Social Services
600 Market St.
Camden, NJ 08102
mroconnor@oel.state.nj.us
856-225-8915 Ofc.
609-206-3458 Blackberry
319D8AF1 BB PIN


[-- Attachment #2: btrfs_bug_1 --]
[-- Type: text/plain, Size: 3628 bytes --]

Apr 28 10:55:10 cosmo2 ------------[ cut here ]------------
Apr 28 10:55:10 cosmo2 kernel BUG at fs/btrfs/file-item.c:494!
Apr 28 10:55:10 cosmo2 invalid opcode: 0000 [#1] PREEMPT SMP
Apr 28 10:55:10 cosmo2 last sysfs file: /sys/devices/platform/hdaps/position
Apr 28 10:55:10 cosmo2 CPU 1
Apr 28 10:55:10 cosmo2 Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss udf isofs berry_charge tun hdaps tp_smapi thinkpad_ac$
Apr 28 10:55:10 cosmo2 Pid: 3144, comm: btrfs-transacti Not tainted 2.6.30-rc3-zen0 #5 4058CTO
Apr 28 10:55:10 cosmo2 RIP: 0010:[<ffffffff80356c0f>]  [<ffffffff80356c0f>] truncate_one_csum+0x116/0x12f
Apr 28 10:55:10 cosmo2 RSP: 0018:ffff8801384a3a90  EFLAGS: 00010286
Apr 28 10:55:10 cosmo2 RAX: 00000000ffffffff RBX: ffff880139d1c000 RCX: fffffffffffffff6
Apr 28 10:55:10 cosmo2 RDX: 0000000000000080 RSI: ffff8800bf5c308f RDI: ffff8801384a3a41
Apr 28 10:55:10 cosmo2 RBP: ffff8801384a3ad0 R08: ffff8801384a38d8 R09: ffff8801384a38d0
Apr 28 10:55:10 cosmo2 R10: 0000000000000005 R11: ffff8801394d6ea0 R12: ffff88003655e090
Apr 28 10:55:10 cosmo2 R13: ffff88003655f000 R14: ffff8801384a3b40 R15: 0000000000c03000
Apr 28 10:55:10 cosmo2 FS:  0000000000000000(0000) GS:ffff88002803b000(0000) knlGS:0000000000000000
Apr 28 10:55:10 cosmo2 CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Apr 28 10:55:10 cosmo2 CR2: 000000000152a280 CR3: 0000000000201000 CR4: 00000000000006a0
Apr 28 10:55:10 cosmo2 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr 28 10:55:10 cosmo2 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Apr 28 10:55:10 cosmo2 Process btrfs-transacti (pid: 3144, threadinfo ffff8801384a2000, task ffff8801384a0040)
Apr 28 10:55:10 cosmo2 Stack:
Apr 28 10:55:10 cosmo2 0000000000c00000 0000000c00000004 ffff8800bf5c3000 ffff88003655e090
Apr 28 10:55:10 cosmo2 0000000000c00000 000000000000000c 0000000000c00000 ffff88013518b7e0
Apr 28 10:55:10 cosmo2 ffff8801384a3b90 ffffffff80356e95 0000000435154538 0000000000c02fff
Apr 28 10:55:10 cosmo2 Call Trace:
Apr 28 10:55:10 cosmo2 [<ffffffff80356e95>] btrfs_del_csums+0x26d/0x2a8
Apr 28 10:55:10 cosmo2 [<ffffffff8035016a>] __btrfs_free_extent+0x6a9/0x726
Apr 28 10:55:10 cosmo2 [<ffffffff80350359>] run_one_delayed_ref+0x172/0x17f
Apr 28 10:55:10 cosmo2 [<ffffffff8034f548>] ? select_delayed_ref+0x1c/0x75
Apr 28 10:55:10 cosmo2 [<ffffffff8035406b>] run_clustered_refs+0xf2/0x167
Apr 28 10:55:10 cosmo2 [<ffffffff803541b3>] btrfs_run_delayed_refs+0xd3/0x1d4
Apr 28 10:55:10 cosmo2 [<ffffffff8035e0ca>] btrfs_commit_transaction+0x8c/0x88e
Apr 28 10:55:10 cosmo2 [<ffffffff80248615>] ? autoremove_wake_function+0x0/0x34
Apr 28 10:55:10 cosmo2 [<ffffffff8035d9b0>] ? start_transaction+0xfa/0x106
Apr 28 10:55:10 cosmo2 [<ffffffff803595de>] transaction_kthread+0x171/0x20f
Apr 28 10:55:10 cosmo2 [<ffffffff8035946d>] ? transaction_kthread+0x0/0x20f
Apr 28 10:55:10 cosmo2 [<ffffffff8035946d>] ? transaction_kthread+0x0/0x20f
Apr 28 10:55:10 cosmo2 [<ffffffff802482ad>] kthread+0x55/0x80
Apr 28 10:55:10 cosmo2 [<ffffffff8020be6a>] child_rip+0xa/0x20
Apr 28 10:55:10 cosmo2 [<ffffffff80248258>] ? kthread+0x0/0x80
Apr 28 10:55:10 cosmo2 [<ffffffff8020be60>] ? child_rip+0x0/0x20
Apr 28 10:55:10 cosmo2 Code: af ce 48 89 de e8 cd bc fe ff 85 c0 74 04 0f 0b eb fe 4d 89 7e 09 4c 89 f1 4c 89 e2 48 89 de 4c 89 ef e8 4a 96 fe ff 85 c0 74 08 <0f> 0b eb fe 0f 0b eb fe 48 83$
Apr 28 10:55:10 cosmo2 RIP  [<ffffffff80356c0f>] truncate_one_csum+0x116/0x12f
Apr 28 10:55:10 cosmo2 RSP <ffff8801384a3a90>
Apr 28 10:55:10 cosmo2 ---[ end trace 2a213e7bc5e1ed02 ]---


[-- Attachment #3: btrfs_bug_2 --]
[-- Type: text/plain, Size: 3761 bytes --]

Apr 28 11:14:43 cosmo2 ------------[ cut here ]------------
Apr 28 11:14:43 cosmo2 kernel BUG at fs/btrfs/file-item.c:494!
Apr 28 11:14:43 cosmo2 invalid opcode: 0000 [#1] PREEMPT SMP
Apr 28 11:14:43 cosmo2 last sysfs file: /sys/module/snd_seq/initstate
Apr 28 11:14:43 cosmo2 CPU 0
Apr 28 11:14:43 cosmo2 Modules linked in: snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss udf isofs berry_charge tun hdaps tp_smapi thinkpad_ac$
Apr 28 11:14:43 cosmo2 Pid: 3200, comm: btrfs-transacti Not tainted 2.6.30-rc3-zen0 #5 4058CTO
Apr 28 11:14:43 cosmo2 RIP: 0010:[<ffffffff80356c0f>]  [<ffffffff80356c0f>] truncate_one_csum+0x116/0x12f
Apr 28 11:14:43 cosmo2 RSP: 0018:ffff880138cb5a90  EFLAGS: 00010286
Apr 28 11:14:43 cosmo2 RAX: 00000000ffffffff RBX: ffff880138dc0000 RCX: fffffffffffffff6
Apr 28 11:14:43 cosmo2 RDX: 0000000000000080 RSI: ffff88013a11f08f RDI: ffff880138cb5a41
Apr 28 11:14:43 cosmo2 RBP: ffff880138cb5ad0 R08: ffff880138cb58d8 R09: ffff880138cb58d0
Apr 28 11:14:43 cosmo2 R10: 0000000000000005 R11: ffff8801388f06e0 R12: ffff880131029090
Apr 28 11:14:43 cosmo2 R13: ffff88013104f000 R14: ffff880138cb5b40 R15: 0000000000c03000
Apr 28 11:14:43 cosmo2 FS:  0000000000000000(0000) GS:ffff880028023000(0000) knlGS:0000000000000000
Apr 28 11:14:43 cosmo2 CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Apr 28 11:14:43 cosmo2 CR2: 00000000015a61a8 CR3: 0000000000201000 CR4: 00000000000006a0
Apr 28 11:14:43 cosmo2 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr 28 11:14:43 cosmo2 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Apr 28 11:14:43 cosmo2 Process btrfs-transacti (pid: 3200, threadinfo ffff880138cb4000, task ffff880138c247c0)
Apr 28 11:14:43 cosmo2 Stack:
Apr 28 11:14:43 cosmo2 0000000000c00000 0000000c00000004 ffff88013a11f000 ffff880131029090
Apr 28 11:14:43 cosmo2 0000000000c00000 000000000000000c 0000000000c00000 ffff88013102eea0
Apr 28 11:14:43 cosmo2 ffff880138cb5b90 ffffffff80356e95 000000043102ee38 0000000000c02fff
Apr 28 11:14:43 cosmo2 Call Trace:
Apr 28 11:14:43 cosmo2 [<ffffffff80356e95>] btrfs_del_csums+0x26d/0x2a8
Apr 28 11:14:43 cosmo2 [<ffffffff8035016a>] __btrfs_free_extent+0x6a9/0x726
Apr 28 11:14:43 cosmo2 [<ffffffff80350359>] run_one_delayed_ref+0x172/0x17f
Apr 28 11:14:43 cosmo2 [<ffffffff8034f548>] ? select_delayed_ref+0x1c/0x75
Apr 28 11:14:43 cosmo2 [<ffffffff8035406b>] run_clustered_refs+0xf2/0x167
Apr 28 11:14:43 cosmo2 [<ffffffff803541b3>] btrfs_run_delayed_refs+0xd3/0x1d4
Apr 28 11:14:43 cosmo2 [<ffffffff802a0156>] ? iput+0x2f/0x65
Apr 28 11:14:43 cosmo2 [<ffffffff8035e0ca>] btrfs_commit_transaction+0x8c/0x88e
Apr 28 11:14:43 cosmo2 [<ffffffff80248615>] ? autoremove_wake_function+0x0/0x34
Apr 28 11:14:43 cosmo2 [<ffffffff8035d9b0>] ? start_transaction+0xfa/0x106
Apr 28 11:14:43 cosmo2 [<ffffffff803595de>] transaction_kthread+0x171/0x20f
Apr 28 11:14:43 cosmo2 [<ffffffff8035946d>] ? transaction_kthread+0x0/0x20f
Apr 28 11:14:43 cosmo2 [<ffffffff8035946d>] ? transaction_kthread+0x0/0x20f
Apr 28 11:14:43 cosmo2 [<ffffffff802482ad>] kthread+0x55/0x80
Apr 28 11:14:43 cosmo2 [<ffffffff8020be6a>] child_rip+0xa/0x20
Apr 28 11:14:43 cosmo2 [<ffffffff80248258>] ? kthread+0x0/0x80
Apr 28 11:14:43 cosmo2 [<ffffffff8020be60>] ? child_rip+0x0/0x20
Apr 28 11:14:43 cosmo2 Code: af ce 48 89 de e8 cd bc fe ff 85 c0 74 04 0f 0b eb fe 4d 89 7e 09 4c 89 f1 4c 89 e2 48 89 de 4c 89 ef e8 4a 96 fe ff 85 c0 74 08 <0f> 0b eb fe 0f 0b eb fe 48 83$
Apr 28 11:14:43 cosmo2 RIP  [<ffffffff80356c0f>] truncate_one_csum+0x116/0x12f
Apr 28 11:14:43 cosmo2 RSP <ffff880138cb5a90>
Apr 28 11:14:43 cosmo2 ---[ end trace 55c51a1dd09bad23 ]---
Apr 28 11:14:43 cosmo2 note: btrfs-transacti[3200] exited with preempt_count 1


[-- Attachment #4: file-item.c.snippet --]
[-- Type: text/plain, Size: 1371 bytes --]

   } else if (key->offset >= bytenr && csum_end > end_byte &&
                   end_byte > key->offset) {
                /*
                 *         [ bytenr - len ]
                 *                 [ ]
                 *                 [csum     ]
                 * we need to truncate from the beginning of the csum
                 */
                u32 new_size = (csum_end - end_byte) >> blocksize_bits;
                new_size *= csum_size;

                ret = btrfs_truncate_item(trans, root, path, new_size, 0);
                BUG_ON(ret);

                key->offset = end_byte;
                ret = btrfs_set_item_key_safe(trans, root, path, key);
                BUG_ON(ret);
        } else {
                BUG(); <-------LINE 494
        }
        return 0;
}

/*
 * deletes the csum items from the csum tree for a given
 * range of bytes.
 */
int btrfs_del_csums(struct btrfs_trans_handle *trans,
                    struct btrfs_root *root, u64 bytenr, u64 len)
{
        struct btrfs_path *path;
        struct btrfs_key key;
        u64 end_byte = bytenr + len;
        u64 csum_end;
        struct extent_buffer *leaf;
        int ret;
        u16 csum_size =
                btrfs_super_csum_size(&root->fs_info->super_copy);
        int blocksize_bits = root->fs_info->sb->s_blocksize_bits;

        root = root->fs_info->csum_root;


[-- Attachment #5: mroconnor.vcf --]
[-- Type: text/x-vcard, Size: 260 bytes --]

begin:vcard
fn:Marc O'Connor
n:O'Connor;Marc
org:Camden County Board of Social Services;Information Technology
adr:;;600 Market St.;Camden;NJ;08102;USA
email;internet:mroconnor@oel.state.nj.us
tel;work:856-225-8915
tel;cell:609-206-3458
version:2.1
end:vcard


[-- Attachment #6: disclaimer.txt --]
[-- Type: Text/Plain, Size: 662 bytes --]

This E-mail, including any attachments, may be intended solely for the personal 
and confidential use of the sender and recipient(s) named above. This message 
may include advisory, consultative and/or deliberative material and, as such, 
would be privileged and confidential and not a public document. Any Information 
in this e-mail identifying a client of the Department of Human Services is 
confidential. If you have received this e-mail in error, you must not review, 
transmit, convert to hard copy, copy, use or disseminate this e-mail or any 
attachments to it and you must delete this message. You are requested to notify 
the sender by return e-mail.

Re: kernel bug in file-item.c

[Chris Mason]

On Tue, 2009-04-28 at 13:39 -0400, Marc R. O'Connor wrote:
> I have had two 'kernel bug' issues today both referencing file-item.c.
> The first oops happened when i was cp'ing from and external HD(ext3) to
> and ext3 partition. The second happened during boot up. I have attached
> them both.
> 
> Im using btrfs that was merged into my kernel yesterday.
> 
> plain text document attachment (btrfs_bug_1)
> Apr 28 10:55:10 cosmo2 ------------[ cut here ]------------
> Apr 28 10:55:10 cosmo2 kernel BUG at fs/btrfs/file-item.c:494!

Well, I think I see the bug.  It looks like we want to do

-        if (key->offset < bytenr && csum_end <= end_byte) {
+        if (key->offset <= bytenr && csum_end <= end_byte) {

in truncate_one_csum.  But I need to test that here for a bit and send
you a patch.

-chris

Re: kernel bug in file-item.c

[Marc R. O'Connor]

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]



Chris Mason wrote:
> On Tue, 2009-04-28 at 13:39 -0400, Marc R. O'Connor wrote:
>> I have had two 'kernel bug' issues today both referencing file-item.c.
>> The first oops happened when i was cp'ing from and external HD(ext3) to
>> and ext3 partition. The second happened during boot up. I have attached
>> them both.
>>
>> Im using btrfs that was merged into my kernel yesterday.
>>
>> plain text document attachment (btrfs_bug_1)
>> Apr 28 10:55:10 cosmo2 ------------[ cut here ]------------
>> Apr 28 10:55:10 cosmo2 kernel BUG at fs/btrfs/file-item.c:494!
> 
> Well, I think I see the bug.  It looks like we want to do
> 
> -        if (key->offset < bytenr && csum_end <= end_byte) {
> +        if (key->offset <= bytenr && csum_end <= end_byte) {
> 
> in truncate_one_csum.  But I need to test that here for a bit and send
> you a patch.
> 
> -chris
> 
> 
> --
> 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


Thanks, I am a patient kind of guy ;)

-- 

--
Marc R. O'Connor
Information Systems
Camden County Board of Social Services
600 Market St.
Camden, NJ 08102
mroconnor@oel.state.nj.us
856-225-8915 Ofc.
609-206-3458 Blackberry
319D8AF1 BB PIN


[-- Attachment #2: mroconnor.vcf --]
[-- Type: text/x-vcard, Size: 260 bytes --]

begin:vcard
fn:Marc O'Connor
n:O'Connor;Marc
org:Camden County Board of Social Services;Information Technology
adr:;;600 Market St.;Camden;NJ;08102;USA
email;internet:mroconnor@oel.state.nj.us
tel;work:856-225-8915
tel;cell:609-206-3458
version:2.1
end:vcard


[-- Attachment #3: disclaimer.txt --]
[-- Type: Text/Plain, Size: 662 bytes --]

This E-mail, including any attachments, may be intended solely for the personal 
and confidential use of the sender and recipient(s) named above. This message 
may include advisory, consultative and/or deliberative material and, as such, 
would be privileged and confidential and not a public document. Any Information 
in this e-mail identifying a client of the Department of Human Services is 
confidential. If you have received this e-mail in error, you must not review, 
transmit, convert to hard copy, copy, use or disseminate this e-mail or any 
attachments to it and you must delete this message. You are requested to notify 
the sender by return e-mail.

Re: kernel bug in file-item.c

[Marc R. O'Connor]

[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

full file-item.c attached

Chris Mason wrote:
> On Tue, 2009-04-28 at 13:39 -0400, Marc R. O'Connor wrote:
>> I have had two 'kernel bug' issues today both referencing file-item.c.
>> The first oops happened when i was cp'ing from and external HD(ext3) to
>> and ext3 partition. The second happened during boot up. I have attached
>> them both.
>>
>> Im using btrfs that was merged into my kernel yesterday.
>>
>> plain text document attachment (btrfs_bug_1)
>> Apr 28 10:55:10 cosmo2 ------------[ cut here ]------------
>> Apr 28 10:55:10 cosmo2 kernel BUG at fs/btrfs/file-item.c:494!
> 
> Well, I think I see the bug.  It looks like we want to do
> 
> -        if (key->offset < bytenr && csum_end <= end_byte) {
> +        if (key->offset <= bytenr && csum_end <= end_byte) {
> 
> in truncate_one_csum.  But I need to test that here for a bit and send
> you a patch.
> 
> -chris
> 
> 
> --
> 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

- --

- --
Marc R. O'Connor
Information Systems
Camden County Board of Social Services
600 Market St.
Camden, NJ 08102
mroconnor@oel.state.nj.us
856-225-8915 Ofc.
609-206-3458 Blackberry
319D8AF1 BB PIN

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn4en0ACgkQd+xzezvVnBzEDwCfVK0fXZ8aeYJJWJLqSLGiQRu3
MpIAoIPQatlYj8dtyhECz/LT8AKCoHjT
=UHoN
-----END PGP SIGNATURE-----

[-- Attachment #2: file-item.c --]
[-- Type: text/x-csrc, Size: 22448 bytes --]

/*
 * Copyright (C) 2007 Oracle.  All rights reserved.
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public
 * License v2 as published by the Free Software Foundation.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 *
 * You should have received a copy of the GNU General Public
 * License along with this program; if not, write to the
 * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 * Boston, MA 021110-1307, USA.
 */

#include <linux/bio.h>
#include <linux/pagemap.h>
#include <linux/highmem.h>
#include "ctree.h"
#include "disk-io.h"
#include "transaction.h"
#include "print-tree.h"

#define MAX_CSUM_ITEMS(r, size) ((((BTRFS_LEAF_DATA_SIZE(r) - \
				   sizeof(struct btrfs_item) * 2) / \
				  size) - 1))

#define MAX_ORDERED_SUM_BYTES(r) ((PAGE_SIZE - \
				   sizeof(struct btrfs_ordered_sum)) / \
				   sizeof(struct btrfs_sector_sum) * \
				   (r)->sectorsize - (r)->sectorsize)

int btrfs_insert_file_extent(struct btrfs_trans_handle *trans,
			     struct btrfs_root *root,
			     u64 objectid, u64 pos,
			     u64 disk_offset, u64 disk_num_bytes,
			     u64 num_bytes, u64 offset, u64 ram_bytes,
			     u8 compression, u8 encryption, u16 other_encoding)
{
	int ret = 0;
	struct btrfs_file_extent_item *item;
	struct btrfs_key file_key;
	struct btrfs_path *path;
	struct extent_buffer *leaf;

	path = btrfs_alloc_path();
	BUG_ON(!path);
	file_key.objectid = objectid;
	file_key.offset = pos;
	btrfs_set_key_type(&file_key, BTRFS_EXTENT_DATA_KEY);

	path->leave_spinning = 1;
	ret = btrfs_insert_empty_item(trans, root, path, &file_key,
				      sizeof(*item));
	if (ret < 0)
		goto out;
	BUG_ON(ret);
	leaf = path->nodes[0];
	item = btrfs_item_ptr(leaf, path->slots[0],
			      struct btrfs_file_extent_item);
	btrfs_set_file_extent_disk_bytenr(leaf, item, disk_offset);
	btrfs_set_file_extent_disk_num_bytes(leaf, item, disk_num_bytes);
	btrfs_set_file_extent_offset(leaf, item, offset);
	btrfs_set_file_extent_num_bytes(leaf, item, num_bytes);
	btrfs_set_file_extent_ram_bytes(leaf, item, ram_bytes);
	btrfs_set_file_extent_generation(leaf, item, trans->transid);
	btrfs_set_file_extent_type(leaf, item, BTRFS_FILE_EXTENT_REG);
	btrfs_set_file_extent_compression(leaf, item, compression);
	btrfs_set_file_extent_encryption(leaf, item, encryption);
	btrfs_set_file_extent_other_encoding(leaf, item, other_encoding);

	btrfs_mark_buffer_dirty(leaf);
out:
	btrfs_free_path(path);
	return ret;
}

struct btrfs_csum_item *btrfs_lookup_csum(struct btrfs_trans_handle *trans,
					  struct btrfs_root *root,
					  struct btrfs_path *path,
					  u64 bytenr, int cow)
{
	int ret;
	struct btrfs_key file_key;
	struct btrfs_key found_key;
	struct btrfs_csum_item *item;
	struct extent_buffer *leaf;
	u64 csum_offset = 0;
	u16 csum_size =
		btrfs_super_csum_size(&root->fs_info->super_copy);
	int csums_in_item;

	file_key.objectid = BTRFS_EXTENT_CSUM_OBJECTID;
	file_key.offset = bytenr;
	btrfs_set_key_type(&file_key, BTRFS_EXTENT_CSUM_KEY);
	ret = btrfs_search_slot(trans, root, &file_key, path, 0, cow);
	if (ret < 0)
		goto fail;
	leaf = path->nodes[0];
	if (ret > 0) {
		ret = 1;
		if (path->slots[0] == 0)
			goto fail;
		path->slots[0]--;
		btrfs_item_key_to_cpu(leaf, &found_key, path->slots[0]);
		if (btrfs_key_type(&found_key) != BTRFS_EXTENT_CSUM_KEY)
			goto fail;

		csum_offset = (bytenr - found_key.offset) >>
				root->fs_info->sb->s_blocksize_bits;
		csums_in_item = btrfs_item_size_nr(leaf, path->slots[0]);
		csums_in_item /= csum_size;

		if (csum_offset >= csums_in_item) {
			ret = -EFBIG;
			goto fail;
		}
	}
	item = btrfs_item_ptr(leaf, path->slots[0], struct btrfs_csum_item);
	item = (struct btrfs_csum_item *)((unsigned char *)item +
					  csum_offset * csum_size);
	return item;
fail:
	if (ret > 0)
		ret = -ENOENT;
	return ERR_PTR(ret);
}


int btrfs_lookup_file_extent(struct btrfs_trans_handle *trans,
			     struct btrfs_root *root,
			     struct btrfs_path *path, u64 objectid,
			     u64 offset, int mod)
{
	int ret;
	struct btrfs_key file_key;
	int ins_len = mod < 0 ? -1 : 0;
	int cow = mod != 0;

	file_key.objectid = objectid;
	file_key.offset = offset;
	btrfs_set_key_type(&file_key, BTRFS_EXTENT_DATA_KEY);
	ret = btrfs_search_slot(trans, root, &file_key, path, ins_len, cow);
	return ret;
}


int btrfs_lookup_bio_sums(struct btrfs_root *root, struct inode *inode,
			  struct bio *bio, u32 *dst)
{
	u32 sum;
	struct bio_vec *bvec = bio->bi_io_vec;
	int bio_index = 0;
	u64 offset;
	u64 item_start_offset = 0;
	u64 item_last_offset = 0;
	u64 disk_bytenr;
	u32 diff;
	u16 csum_size =
		btrfs_super_csum_size(&root->fs_info->super_copy);
	int ret;
	struct btrfs_path *path;
	struct btrfs_csum_item *item = NULL;
	struct extent_io_tree *io_tree = &BTRFS_I(inode)->io_tree;

	path = btrfs_alloc_path();
	if (bio->bi_size > PAGE_CACHE_SIZE * 8)
		path->reada = 2;

	WARN_ON(bio->bi_vcnt <= 0);

	disk_bytenr = (u64)bio->bi_sector << 9;
	while (bio_index < bio->bi_vcnt) {
		offset = page_offset(bvec->bv_page) + bvec->bv_offset;
		ret = btrfs_find_ordered_sum(inode, offset, disk_bytenr, &sum);
		if (ret == 0)
			goto found;

		if (!item || disk_bytenr < item_start_offset ||
		    disk_bytenr >= item_last_offset) {
			struct btrfs_key found_key;
			u32 item_size;

			if (item)
				btrfs_release_path(root, path);
			item = btrfs_lookup_csum(NULL, root->fs_info->csum_root,
						 path, disk_bytenr, 0);
			if (IS_ERR(item)) {
				ret = PTR_ERR(item);
				if (ret == -ENOENT || ret == -EFBIG)
					ret = 0;
				sum = 0;
				if (BTRFS_I(inode)->root->root_key.objectid ==
				    BTRFS_DATA_RELOC_TREE_OBJECTID) {
					set_extent_bits(io_tree, offset,
						offset + bvec->bv_len - 1,
						EXTENT_NODATASUM, GFP_NOFS);
				} else {
					printk(KERN_INFO "btrfs no csum found "
					       "for inode %lu start %llu\n",
					       inode->i_ino,
					       (unsigned long long)offset);
				}
				item = NULL;
				btrfs_release_path(root, path);
				goto found;
			}
			btrfs_item_key_to_cpu(path->nodes[0], &found_key,
					      path->slots[0]);

			item_start_offset = found_key.offset;
			item_size = btrfs_item_size_nr(path->nodes[0],
						       path->slots[0]);
			item_last_offset = item_start_offset +
				(item_size / csum_size) *
				root->sectorsize;
			item = btrfs_item_ptr(path->nodes[0], path->slots[0],
					      struct btrfs_csum_item);
		}
		/*
		 * this byte range must be able to fit inside
		 * a single leaf so it will also fit inside a u32
		 */
		diff = disk_bytenr - item_start_offset;
		diff = diff / root->sectorsize;
		diff = diff * csum_size;

		read_extent_buffer(path->nodes[0], &sum,
				   ((unsigned long)item) + diff,
				   csum_size);
found:
		if (dst)
			*dst++ = sum;
		else
			set_state_private(io_tree, offset, sum);
		disk_bytenr += bvec->bv_len;
		bio_index++;
		bvec++;
	}
	btrfs_free_path(path);
	return 0;
}

int btrfs_lookup_csums_range(struct btrfs_root *root, u64 start, u64 end,
			     struct list_head *list)
{
	struct btrfs_key key;
	struct btrfs_path *path;
	struct extent_buffer *leaf;
	struct btrfs_ordered_sum *sums;
	struct btrfs_sector_sum *sector_sum;
	struct btrfs_csum_item *item;
	unsigned long offset;
	int ret;
	size_t size;
	u64 csum_end;
	u16 csum_size = btrfs_super_csum_size(&root->fs_info->super_copy);

	path = btrfs_alloc_path();
	BUG_ON(!path);

	key.objectid = BTRFS_EXTENT_CSUM_OBJECTID;
	key.offset = start;
	key.type = BTRFS_EXTENT_CSUM_KEY;

	ret = btrfs_search_slot(NULL, root, &key, path, 0, 0);
	if (ret < 0)
		goto fail;
	if (ret > 0 && path->slots[0] > 0) {
		leaf = path->nodes[0];
		btrfs_item_key_to_cpu(leaf, &key, path->slots[0] - 1);
		if (key.objectid == BTRFS_EXTENT_CSUM_OBJECTID &&
		    key.type == BTRFS_EXTENT_CSUM_KEY) {
			offset = (start - key.offset) >>
				 root->fs_info->sb->s_blocksize_bits;
			if (offset * csum_size <
			    btrfs_item_size_nr(leaf, path->slots[0] - 1))
				path->slots[0]--;
		}
	}

	while (start <= end) {
		leaf = path->nodes[0];
		if (path->slots[0] >= btrfs_header_nritems(leaf)) {
			ret = btrfs_next_leaf(root, path);
			if (ret < 0)
				goto fail;
			if (ret > 0)
				break;
			leaf = path->nodes[0];
		}

		btrfs_item_key_to_cpu(leaf, &key, path->slots[0]);
		if (key.objectid != BTRFS_EXTENT_CSUM_OBJECTID ||
		    key.type != BTRFS_EXTENT_CSUM_KEY)
			break;

		btrfs_item_key_to_cpu(leaf, &key, path->slots[0]);
		if (key.offset > end)
			break;

		if (key.offset > start)
			start = key.offset;

		size = btrfs_item_size_nr(leaf, path->slots[0]);
		csum_end = key.offset + (size / csum_size) * root->sectorsize;
		if (csum_end <= start) {
			path->slots[0]++;
			continue;
		}

		csum_end = min(csum_end, end + 1);
		item = btrfs_item_ptr(path->nodes[0], path->slots[0],
				      struct btrfs_csum_item);
		while (start < csum_end) {
			size = min_t(size_t, csum_end - start,
					MAX_ORDERED_SUM_BYTES(root));
			sums = kzalloc(btrfs_ordered_sum_size(root, size),
					GFP_NOFS);
			BUG_ON(!sums);

			sector_sum = sums->sums;
			sums->bytenr = start;
			sums->len = size;

			offset = (start - key.offset) >>
				root->fs_info->sb->s_blocksize_bits;
			offset *= csum_size;

			while (size > 0) {
				read_extent_buffer(path->nodes[0],
						&sector_sum->sum,
						((unsigned long)item) +
						offset, csum_size);
				sector_sum->bytenr = start;

				size -= root->sectorsize;
				start += root->sectorsize;
				offset += csum_size;
				sector_sum++;
			}
			list_add_tail(&sums->list, list);
		}
		path->slots[0]++;
	}
	ret = 0;
fail:
	btrfs_free_path(path);
	return ret;
}

int btrfs_csum_one_bio(struct btrfs_root *root, struct inode *inode,
		       struct bio *bio, u64 file_start, int contig)
{
	struct btrfs_ordered_sum *sums;
	struct btrfs_sector_sum *sector_sum;
	struct btrfs_ordered_extent *ordered;
	char *data;
	struct bio_vec *bvec = bio->bi_io_vec;
	int bio_index = 0;
	unsigned long total_bytes = 0;
	unsigned long this_sum_bytes = 0;
	u64 offset;
	u64 disk_bytenr;

	WARN_ON(bio->bi_vcnt <= 0);
	sums = kzalloc(btrfs_ordered_sum_size(root, bio->bi_size), GFP_NOFS);
	if (!sums)
		return -ENOMEM;

	sector_sum = sums->sums;
	disk_bytenr = (u64)bio->bi_sector << 9;
	sums->len = bio->bi_size;
	INIT_LIST_HEAD(&sums->list);

	if (contig)
		offset = file_start;
	else
		offset = page_offset(bvec->bv_page) + bvec->bv_offset;

	ordered = btrfs_lookup_ordered_extent(inode, offset);
	BUG_ON(!ordered);
	sums->bytenr = ordered->start;

	while (bio_index < bio->bi_vcnt) {
		if (!contig)
			offset = page_offset(bvec->bv_page) + bvec->bv_offset;

		if (!contig && (offset >= ordered->file_offset + ordered->len ||
		    offset < ordered->file_offset)) {
			unsigned long bytes_left;
			sums->len = this_sum_bytes;
			this_sum_bytes = 0;
			btrfs_add_ordered_sum(inode, ordered, sums);
			btrfs_put_ordered_extent(ordered);

			bytes_left = bio->bi_size - total_bytes;

			sums = kzalloc(btrfs_ordered_sum_size(root, bytes_left),
				       GFP_NOFS);
			BUG_ON(!sums);
			sector_sum = sums->sums;
			sums->len = bytes_left;
			ordered = btrfs_lookup_ordered_extent(inode, offset);
			BUG_ON(!ordered);
			sums->bytenr = ordered->start;
		}

		data = kmap_atomic(bvec->bv_page, KM_USER0);
		sector_sum->sum = ~(u32)0;
		sector_sum->sum = btrfs_csum_data(root,
						  data + bvec->bv_offset,
						  sector_sum->sum,
						  bvec->bv_len);
		kunmap_atomic(data, KM_USER0);
		btrfs_csum_final(sector_sum->sum,
				 (char *)&sector_sum->sum);
		sector_sum->bytenr = disk_bytenr;

		sector_sum++;
		bio_index++;
		total_bytes += bvec->bv_len;
		this_sum_bytes += bvec->bv_len;
		disk_bytenr += bvec->bv_len;
		offset += bvec->bv_len;
		bvec++;
	}
	this_sum_bytes = 0;
	btrfs_add_ordered_sum(inode, ordered, sums);
	btrfs_put_ordered_extent(ordered);
	return 0;
}

/*
 * helper function for csum removal, this expects the
 * key to describe the csum pointed to by the path, and it expects
 * the csum to overlap the range [bytenr, len]
 *
 * The csum should not be entirely contained in the range and the
 * range should not be entirely contained in the csum.
 *
 * This calls btrfs_truncate_item with the correct args based on the
 * overlap, and fixes up the key as required.
 */
static noinline int truncate_one_csum(struct btrfs_trans_handle *trans,
				      struct btrfs_root *root,
				      struct btrfs_path *path,
				      struct btrfs_key *key,
				      u64 bytenr, u64 len)
{
	struct extent_buffer *leaf;
	u16 csum_size =
		btrfs_super_csum_size(&root->fs_info->super_copy);
	u64 csum_end;
	u64 end_byte = bytenr + len;
	u32 blocksize_bits = root->fs_info->sb->s_blocksize_bits;
	int ret;

	leaf = path->nodes[0];
	csum_end = btrfs_item_size_nr(leaf, path->slots[0]) / csum_size;
	csum_end <<= root->fs_info->sb->s_blocksize_bits;
	csum_end += key->offset;

	if (key->offset < bytenr && csum_end <= end_byte) {
		/*
		 *         [ bytenr - len ]
		 *         [   ]
		 *   [csum     ]
		 *   A simple truncate off the end of the item
		 */
		u32 new_size = (bytenr - key->offset) >> blocksize_bits;
		new_size *= csum_size;
		ret = btrfs_truncate_item(trans, root, path, new_size, 1);
		BUG_ON(ret);
	} else if (key->offset >= bytenr && csum_end > end_byte &&
		   end_byte > key->offset) {
		/*
		 *         [ bytenr - len ]
		 *                 [ ]
		 *                 [csum     ]
		 * we need to truncate from the beginning of the csum
		 */
		u32 new_size = (csum_end - end_byte) >> blocksize_bits;
		new_size *= csum_size;

		ret = btrfs_truncate_item(trans, root, path, new_size, 0);
		BUG_ON(ret);

		key->offset = end_byte;
		ret = btrfs_set_item_key_safe(trans, root, path, key);
		BUG_ON(ret);
	} else {
		BUG();
	}
	return 0;
}

/*
 * deletes the csum items from the csum tree for a given
 * range of bytes.
 */
int btrfs_del_csums(struct btrfs_trans_handle *trans,
		    struct btrfs_root *root, u64 bytenr, u64 len)
{
	struct btrfs_path *path;
	struct btrfs_key key;
	u64 end_byte = bytenr + len;
	u64 csum_end;
	struct extent_buffer *leaf;
	int ret;
	u16 csum_size =
		btrfs_super_csum_size(&root->fs_info->super_copy);
	int blocksize_bits = root->fs_info->sb->s_blocksize_bits;

	root = root->fs_info->csum_root;

	path = btrfs_alloc_path();

	while (1) {
		key.objectid = BTRFS_EXTENT_CSUM_OBJECTID;
		key.offset = end_byte - 1;
		key.type = BTRFS_EXTENT_CSUM_KEY;

		path->leave_spinning = 1;
		ret = btrfs_search_slot(trans, root, &key, path, -1, 1);
		if (ret > 0) {
			if (path->slots[0] == 0)
				goto out;
			path->slots[0]--;
		}
		leaf = path->nodes[0];
		btrfs_item_key_to_cpu(leaf, &key, path->slots[0]);

		if (key.objectid != BTRFS_EXTENT_CSUM_OBJECTID ||
		    key.type != BTRFS_EXTENT_CSUM_KEY) {
			break;
		}

		if (key.offset >= end_byte)
			break;

		csum_end = btrfs_item_size_nr(leaf, path->slots[0]) / csum_size;
		csum_end <<= blocksize_bits;
		csum_end += key.offset;

		/* this csum ends before we start, we're done */
		if (csum_end <= bytenr)
			break;

		/* delete the entire item, it is inside our range */
		if (key.offset >= bytenr && csum_end <= end_byte) {
			ret = btrfs_del_item(trans, root, path);
			BUG_ON(ret);
			if (key.offset == bytenr)
				break;
		} else if (key.offset < bytenr && csum_end > end_byte) {
			unsigned long offset;
			unsigned long shift_len;
			unsigned long item_offset;
			/*
			 *        [ bytenr - len ]
			 *     [csum                ]
			 *
			 * Our bytes are in the middle of the csum,
			 * we need to split this item and insert a new one.
			 *
			 * But we can't drop the path because the
			 * csum could change, get removed, extended etc.
			 *
			 * The trick here is the max size of a csum item leaves
			 * enough room in the tree block for a single
			 * item header.  So, we split the item in place,
			 * adding a new header pointing to the existing
			 * bytes.  Then we loop around again and we have
			 * a nicely formed csum item that we can neatly
			 * truncate.
			 */
			offset = (bytenr - key.offset) >> blocksize_bits;
			offset *= csum_size;

			shift_len = (len >> blocksize_bits) * csum_size;

			item_offset = btrfs_item_ptr_offset(leaf,
							    path->slots[0]);

			memset_extent_buffer(leaf, 0, item_offset + offset,
					     shift_len);
			key.offset = bytenr;

			/*
			 * btrfs_split_item returns -EAGAIN when the
			 * item changed size or key
			 */
			ret = btrfs_split_item(trans, root, path, &key, offset);
			BUG_ON(ret && ret != -EAGAIN);

			key.offset = end_byte - 1;
		} else {
			ret = truncate_one_csum(trans, root, path,
						&key, bytenr, len);
			BUG_ON(ret);
			if (key.offset < bytenr)
				break;
		}
		btrfs_release_path(root, path);
	}
out:
	btrfs_free_path(path);
	return 0;
}

int btrfs_csum_file_blocks(struct btrfs_trans_handle *trans,
			   struct btrfs_root *root,
			   struct btrfs_ordered_sum *sums)
{
	u64 bytenr;
	int ret;
	struct btrfs_key file_key;
	struct btrfs_key found_key;
	u64 next_offset;
	u64 total_bytes = 0;
	int found_next;
	struct btrfs_path *path;
	struct btrfs_csum_item *item;
	struct btrfs_csum_item *item_end;
	struct extent_buffer *leaf = NULL;
	u64 csum_offset;
	struct btrfs_sector_sum *sector_sum;
	u32 nritems;
	u32 ins_size;
	char *eb_map;
	char *eb_token;
	unsigned long map_len;
	unsigned long map_start;
	u16 csum_size =
		btrfs_super_csum_size(&root->fs_info->super_copy);

	path = btrfs_alloc_path();
	BUG_ON(!path);
	sector_sum = sums->sums;
again:
	next_offset = (u64)-1;
	found_next = 0;
	file_key.objectid = BTRFS_EXTENT_CSUM_OBJECTID;
	file_key.offset = sector_sum->bytenr;
	bytenr = sector_sum->bytenr;
	btrfs_set_key_type(&file_key, BTRFS_EXTENT_CSUM_KEY);

	item = btrfs_lookup_csum(trans, root, path, sector_sum->bytenr, 1);
	if (!IS_ERR(item)) {
		leaf = path->nodes[0];
		ret = 0;
		goto found;
	}
	ret = PTR_ERR(item);
	if (ret == -EFBIG) {
		u32 item_size;
		/* we found one, but it isn't big enough yet */
		leaf = path->nodes[0];
		item_size = btrfs_item_size_nr(leaf, path->slots[0]);
		if ((item_size / csum_size) >=
		    MAX_CSUM_ITEMS(root, csum_size)) {
			/* already at max size, make a new one */
			goto insert;
		}
	} else {
		int slot = path->slots[0] + 1;
		/* we didn't find a csum item, insert one */
		nritems = btrfs_header_nritems(path->nodes[0]);
		if (path->slots[0] >= nritems - 1) {
			ret = btrfs_next_leaf(root, path);
			if (ret == 1)
				found_next = 1;
			if (ret != 0)
				goto insert;
			slot = 0;
		}
		btrfs_item_key_to_cpu(path->nodes[0], &found_key, slot);
		if (found_key.objectid != BTRFS_EXTENT_CSUM_OBJECTID ||
		    found_key.type != BTRFS_EXTENT_CSUM_KEY) {
			found_next = 1;
			goto insert;
		}
		next_offset = found_key.offset;
		found_next = 1;
		goto insert;
	}

	/*
	 * at this point, we know the tree has an item, but it isn't big
	 * enough yet to put our csum in.  Grow it
	 */
	btrfs_release_path(root, path);
	ret = btrfs_search_slot(trans, root, &file_key, path,
				csum_size, 1);
	if (ret < 0)
		goto fail_unlock;

	if (ret > 0) {
		if (path->slots[0] == 0)
			goto insert;
		path->slots[0]--;
	}

	leaf = path->nodes[0];
	btrfs_item_key_to_cpu(leaf, &found_key, path->slots[0]);
	csum_offset = (bytenr - found_key.offset) >>
			root->fs_info->sb->s_blocksize_bits;

	if (btrfs_key_type(&found_key) != BTRFS_EXTENT_CSUM_KEY ||
	    found_key.objectid != BTRFS_EXTENT_CSUM_OBJECTID ||
	    csum_offset >= MAX_CSUM_ITEMS(root, csum_size)) {
		goto insert;
	}

	if (csum_offset >= btrfs_item_size_nr(leaf, path->slots[0]) /
	    csum_size) {
		u32 diff = (csum_offset + 1) * csum_size;

		/*
		 * is the item big enough already?  we dropped our lock
		 * before and need to recheck
		 */
		if (diff < btrfs_item_size_nr(leaf, path->slots[0]))
			goto csum;

		diff = diff - btrfs_item_size_nr(leaf, path->slots[0]);
		if (diff != csum_size)
			goto insert;

		ret = btrfs_extend_item(trans, root, path, diff);
		BUG_ON(ret);
		goto csum;
	}

insert:
	btrfs_release_path(root, path);
	csum_offset = 0;
	if (found_next) {
		u64 tmp = total_bytes + root->sectorsize;
		u64 next_sector = sector_sum->bytenr;
		struct btrfs_sector_sum *next = sector_sum + 1;

		while (tmp < sums->len) {
			if (next_sector + root->sectorsize != next->bytenr)
				break;
			tmp += root->sectorsize;
			next_sector = next->bytenr;
			next++;
		}
		tmp = min(tmp, next_offset - file_key.offset);
		tmp >>= root->fs_info->sb->s_blocksize_bits;
		tmp = max((u64)1, tmp);
		tmp = min(tmp, (u64)MAX_CSUM_ITEMS(root, csum_size));
		ins_size = csum_size * tmp;
	} else {
		ins_size = csum_size;
	}
	path->leave_spinning = 1;
	ret = btrfs_insert_empty_item(trans, root, path, &file_key,
				      ins_size);
	path->leave_spinning = 0;
	if (ret < 0)
		goto fail_unlock;
	if (ret != 0) {
		WARN_ON(1);
		goto fail_unlock;
	}
csum:
	leaf = path->nodes[0];
	item = btrfs_item_ptr(leaf, path->slots[0], struct btrfs_csum_item);
	ret = 0;
	item = (struct btrfs_csum_item *)((unsigned char *)item +
					  csum_offset * csum_size);
found:
	item_end = btrfs_item_ptr(leaf, path->slots[0], struct btrfs_csum_item);
	item_end = (struct btrfs_csum_item *)((unsigned char *)item_end +
				      btrfs_item_size_nr(leaf, path->slots[0]));
	eb_token = NULL;
next_sector:

	if (!eb_token ||
	   (unsigned long)item + csum_size >= map_start + map_len) {
		int err;

		if (eb_token)
			unmap_extent_buffer(leaf, eb_token, KM_USER1);
		eb_token = NULL;
		err = map_private_extent_buffer(leaf, (unsigned long)item,
						csum_size,
						&eb_token, &eb_map,
						&map_start, &map_len, KM_USER1);
		if (err)
			eb_token = NULL;
	}
	if (eb_token) {
		memcpy(eb_token + ((unsigned long)item & (PAGE_CACHE_SIZE - 1)),
		       &sector_sum->sum, csum_size);
	} else {
		write_extent_buffer(leaf, &sector_sum->sum,
				    (unsigned long)item, csum_size);
	}

	total_bytes += root->sectorsize;
	sector_sum++;
	if (total_bytes < sums->len) {
		item = (struct btrfs_csum_item *)((char *)item +
						  csum_size);
		if (item < item_end && bytenr + PAGE_CACHE_SIZE ==
		    sector_sum->bytenr) {
			bytenr = sector_sum->bytenr;
			goto next_sector;
		}
	}
	if (eb_token) {
		unmap_extent_buffer(leaf, eb_token, KM_USER1);
		eb_token = NULL;
	}
	btrfs_mark_buffer_dirty(path->nodes[0]);
	if (total_bytes < sums->len) {
		btrfs_release_path(root, path);
		cond_resched();
		goto again;
	}
out:
	btrfs_free_path(path);
	return ret;

fail_unlock:
	goto out;
}

[-- Attachment #3: file-item.c.sig --]
[-- Type: application/octet-stream, Size: 72 bytes --]

[-- Attachment #4: mroconnor.vcf --]
[-- Type: text/x-vcard, Size: 260 bytes --]

begin:vcard
fn:Marc O'Connor
n:O'Connor;Marc
org:Camden County Board of Social Services;Information Technology
adr:;;600 Market St.;Camden;NJ;08102;USA
email;internet:mroconnor@oel.state.nj.us
tel;work:856-225-8915
tel;cell:609-206-3458
version:2.1
end:vcard


[-- Attachment #5: disclaimer.txt --]
[-- Type: Text/Plain, Size: 662 bytes --]

This E-mail, including any attachments, may be intended solely for the personal 
and confidential use of the sender and recipient(s) named above. This message 
may include advisory, consultative and/or deliberative material and, as such, 
would be privileged and confidential and not a public document. Any Information 
in this e-mail identifying a client of the Department of Human Services is 
confidential. If you have received this e-mail in error, you must not review, 
transmit, convert to hard copy, copy, use or disseminate this e-mail or any 
attachments to it and you must delete this message. You are requested to notify 
the sender by return e-mail.

Re: kernel bug in file-item.c

[Chris Mason]

On Wed, 2009-04-29 at 12:04 -0400, Marc R. O'Connor wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> full file-item.c attached
> 
> Chris Mason wrote:
> > On Tue, 2009-04-28 at 13:39 -0400, Marc R. O'Connor wrote:
> >> I have had two 'kernel bug' issues today both referencing file-item.c.
> >> The first oops happened when i was cp'ing from and external HD(ext3) to
> >> and ext3 partition. The second happened during boot up. I have attached
> >> them both.
> >>
> >> Im using btrfs that was merged into my kernel yesterday.
> >>
> >> plain text document attachment (btrfs_bug_1)
> >> Apr 28 10:55:10 cosmo2 ------------[ cut here ]------------
> >> Apr 28 10:55:10 cosmo2 kernel BUG at fs/btrfs/file-item.c:494!
> > 
> > Well, I think I see the bug.  It looks like we want to do
> > 
> > -        if (key->offset < bytenr && csum_end <= end_byte) {
> > +        if (key->offset <= bytenr && csum_end <= end_byte) {
> > 
> > in truncate_one_csum.  But I need to test that here for a bit and send
> > you a patch.

Ok, line 494 is actually this one ;)

                key->offset = end_byte;
                ret = btrfs_set_item_key_safe(trans, root, path, key);
                BUG_ON(ret); <---- 494

Which means we're finding things out of order in the btree leaf.

Could you please run btrfsck on this filesystem?

-chris

Re: kernel bug in file-item.c

[Marc R. O'Connor]

[-- Attachment #1: Type: text/plain, Size: 1683 bytes --]



Chris Mason wrote:
> On Wed, 2009-04-29 at 12:04 -0400, Marc R. O'Connor wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> full file-item.c attached
>>
>> Chris Mason wrote:
>>> On Tue, 2009-04-28 at 13:39 -0400, Marc R. O'Connor wrote:
>>>> I have had two 'kernel bug' issues today both referencing file-item.c.
>>>> The first oops happened when i was cp'ing from and external HD(ext3) to
>>>> and ext3 partition. The second happened during boot up. I have attached
>>>> them both.
>>>>
>>>> Im using btrfs that was merged into my kernel yesterday.
>>>>
>>>> plain text document attachment (btrfs_bug_1)
>>>> Apr 28 10:55:10 cosmo2 ------------[ cut here ]------------
>>>> Apr 28 10:55:10 cosmo2 kernel BUG at fs/btrfs/file-item.c:494!
>>> Well, I think I see the bug.  It looks like we want to do
>>>
>>> -        if (key->offset < bytenr && csum_end <= end_byte) {
>>> +        if (key->offset <= bytenr && csum_end <= end_byte) {
>>>
>>> in truncate_one_csum.  But I need to test that here for a bit and send
>>> you a patch.
> 
> Ok, line 494 is actually this one ;)
> 
>                 key->offset = end_byte;
>                 ret = btrfs_set_item_key_safe(trans, root, path, key);
>                 BUG_ON(ret); <---- 494
> 
> Which means we're finding things out of order in the btree leaf.
> 
> Could you please run btrfsck on this filesystem?
> 
> -chris
> 
> 

I have done that on all btrfs partitions I have and btrfsck did not
return anything odd.

-- 

--
Marc R. O'Connor
Information Systems
Camden County Board of Social Services
600 Market St.
Camden, NJ 08102
mroconnor@oel.state.nj.us
856-225-8915 Ofc.
609-206-3458 Blackberry
319D8AF1 BB PIN


[-- Attachment #2: mroconnor.vcf --]
[-- Type: text/x-vcard, Size: 260 bytes --]

begin:vcard
fn:Marc O'Connor
n:O'Connor;Marc
org:Camden County Board of Social Services;Information Technology
adr:;;600 Market St.;Camden;NJ;08102;USA
email;internet:mroconnor@oel.state.nj.us
tel;work:856-225-8915
tel;cell:609-206-3458
version:2.1
end:vcard


[-- Attachment #3: disclaimer.txt --]
[-- Type: Text/Plain, Size: 662 bytes --]

This E-mail, including any attachments, may be intended solely for the personal 
and confidential use of the sender and recipient(s) named above. This message 
may include advisory, consultative and/or deliberative material and, as such, 
would be privileged and confidential and not a public document. Any Information 
in this e-mail identifying a client of the Department of Human Services is 
confidential. If you have received this e-mail in error, you must not review, 
transmit, convert to hard copy, copy, use or disseminate this e-mail or any 
attachments to it and you must delete this message. You are requested to notify 
the sender by return e-mail.

Re: kernel bug in file-item.c

[Chris Mason]

On Wed, 2009-04-29 at 14:21 -0400, Marc R. O'Connor wrote:
> 
> Chris Mason wrote:
> > On Wed, 2009-04-29 at 12:04 -0400, Marc R. O'Connor wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> full file-item.c attached
> >>
> >> Chris Mason wrote:
> >>> On Tue, 2009-04-28 at 13:39 -0400, Marc R. O'Connor wrote:
> >>>> I have had two 'kernel bug' issues today both referencing file-item.c.
> >>>> The first oops happened when i was cp'ing from and external HD(ext3) to
> >>>> and ext3 partition. The second happened during boot up. I have attached
> >>>> them both.
> >>>>
> >>>> Im using btrfs that was merged into my kernel yesterday.
> >>>>
> >>>> plain text document attachment (btrfs_bug_1)
> >>>> Apr 28 10:55:10 cosmo2 ------------[ cut here ]------------
> >>>> Apr 28 10:55:10 cosmo2 kernel BUG at fs/btrfs/file-item.c:494!
> >>> Well, I think I see the bug.  It looks like we want to do
> >>>
> >>> -        if (key->offset < bytenr && csum_end <= end_byte) {
> >>> +        if (key->offset <= bytenr && csum_end <= end_byte) {
> >>>
> >>> in truncate_one_csum.  But I need to test that here for a bit and send
> >>> you a patch.
> > 
> > Ok, line 494 is actually this one ;)
> > 
> >                 key->offset = end_byte;
> >                 ret = btrfs_set_item_key_safe(trans, root, path, key);
> >                 BUG_ON(ret); <---- 494
> > 
> > Which means we're finding things out of order in the btree leaf.
> > 
> > Could you please run btrfsck on this filesystem?
> > 

> I have done that on all btrfs partitions I have and btrfsck did not
> return anything odd.
> 

In that case, the bad ordering is being introduced at run time.  Could
you please run memtest86 on the box?

-chris

Re: kernel bug in file-item.c

[Marc R. O'Connor]

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]



Chris Mason wrote:
> On Wed, 2009-04-29 at 14:21 -0400, Marc R. O'Connor wrote:
>> Chris Mason wrote:
>>> On Wed, 2009-04-29 at 12:04 -0400, Marc R. O'Connor wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> full file-item.c attached
>>>>
>>>> Chris Mason wrote:
>>>>> On Tue, 2009-04-28 at 13:39 -0400, Marc R. O'Connor wrote:
>>>>>> I have had two 'kernel bug' issues today both referencing file-item.c.
>>>>>> The first oops happened when i was cp'ing from and external HD(ext3) to
>>>>>> and ext3 partition. The second happened during boot up. I have attached
>>>>>> them both.
>>>>>>
>>>>>> Im using btrfs that was merged into my kernel yesterday.
>>>>>>
>>>>>> plain text document attachment (btrfs_bug_1)
>>>>>> Apr 28 10:55:10 cosmo2 ------------[ cut here ]------------
>>>>>> Apr 28 10:55:10 cosmo2 kernel BUG at fs/btrfs/file-item.c:494!
>>>>> Well, I think I see the bug.  It looks like we want to do
>>>>>
>>>>> -        if (key->offset < bytenr && csum_end <= end_byte) {
>>>>> +        if (key->offset <= bytenr && csum_end <= end_byte) {
>>>>>
>>>>> in truncate_one_csum.  But I need to test that here for a bit and send
>>>>> you a patch.
>>> Ok, line 494 is actually this one ;)
>>>
>>>                 key->offset = end_byte;
>>>                 ret = btrfs_set_item_key_safe(trans, root, path, key);
>>>                 BUG_ON(ret); <---- 494
>>>
>>> Which means we're finding things out of order in the btree leaf.
>>>
>>> Could you please run btrfsck on this filesystem?
>>>
> 
>> I have done that on all btrfs partitions I have and btrfsck did not
>> return anything odd.
>>
> 
> In that case, the bad ordering is being introduced at run time.  Could
> you please run memtest86 on the box?
> 
> -chris
> 
> 
 memtest comes back with two errors very early on then reboots the
sysrescueCD. :(
-- 

--
Marc R. O'Connor
Information Systems
Camden County Board of Social Services
600 Market St.
Camden, NJ 08102
mroconnor@oel.state.nj.us
856-225-8915 Ofc.
609-206-3458 Blackberry
319D8AF1 BB PIN


[-- Attachment #2: mroconnor.vcf --]
[-- Type: text/x-vcard, Size: 260 bytes --]

begin:vcard
fn:Marc O'Connor
n:O'Connor;Marc
org:Camden County Board of Social Services;Information Technology
adr:;;600 Market St.;Camden;NJ;08102;USA
email;internet:mroconnor@oel.state.nj.us
tel;work:856-225-8915
tel;cell:609-206-3458
version:2.1
end:vcard


[-- Attachment #3: disclaimer.txt --]
[-- Type: Text/Plain, Size: 662 bytes --]

This E-mail, including any attachments, may be intended solely for the personal 
and confidential use of the sender and recipient(s) named above. This message 
may include advisory, consultative and/or deliberative material and, as such, 
would be privileged and confidential and not a public document. Any Information 
in this e-mail identifying a client of the Department of Human Services is 
confidential. If you have received this e-mail in error, you must not review, 
transmit, convert to hard copy, copy, use or disseminate this e-mail or any 
attachments to it and you must delete this message. You are requested to notify 
the sender by return e-mail.

Re: kernel bug in file-item.c

[Chris Mason]

On Wed, 2009-04-29 at 14:38 -0400, Marc R. O'Connor wrote:
> > 
> >> I have done that on all btrfs partitions I have and btrfsck did not
> >> return anything odd.
> >>
> > 
> > In that case, the bad ordering is being introduced at run time.  Could
> > you please run memtest86 on the box?
> > 
> > -chris
> > 
> > 
>  memtest comes back with two errors very early on then reboots the
> sysrescueCD. :(

Well, then I'm surprised btrfs doesn't crash more violently and more
often ;)

Do you think you're hitting a memtest bug or is the HW really bad?

-chris

Re: kernel bug in file-item.c

[Marc R. O'Connor]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

To be honest I have no idea. Let me see if I can find a different
version to test with and see. I think I'm still under warranty. ;)

Chris Mason wrote:
> On Wed, 2009-04-29 at 14:38 -0400, Marc R. O'Connor wrote:
>>>> I have done that on all btrfs partitions I have and btrfsck did not
>>>> return anything odd.
>>>>
>>> In that case, the bad ordering is being introduced at run time.  Could
>>> you please run memtest86 on the box?
>>>
>>> -chris
>>>
>>>
>>  memtest comes back with two errors very early on then reboots the
>> sysrescueCD. :(
> 
> Well, then I'm surprised btrfs doesn't crash more violently and more
> often ;)
> 
> Do you think you're hitting a memtest bug or is the HW really bad?
> 
> -chris
> 
> 
> 
> 

-- 

--
Marc R. O'Connor
Information Systems
Camden County Board of Social Services
600 Market St.
Camden, NJ 08102
mroconnor@oel.state.nj.us
856-225-8915 Ofc.
609-206-3458 Blackberry
319D8AF1 BB PIN


[-- Attachment #2: mroconnor.vcf --]
[-- Type: text/x-vcard, Size: 260 bytes --]

begin:vcard
fn:Marc O'Connor
n:O'Connor;Marc
org:Camden County Board of Social Services;Information Technology
adr:;;600 Market St.;Camden;NJ;08102;USA
email;internet:mroconnor@oel.state.nj.us
tel;work:856-225-8915
tel;cell:609-206-3458
version:2.1
end:vcard


[-- Attachment #3: disclaimer.txt --]
[-- Type: Text/Plain, Size: 662 bytes --]

This E-mail, including any attachments, may be intended solely for the personal 
and confidential use of the sender and recipient(s) named above. This message 
may include advisory, consultative and/or deliberative material and, as such, 
would be privileged and confidential and not a public document. Any Information 
in this e-mail identifying a client of the Department of Human Services is 
confidential. If you have received this e-mail in error, you must not review, 
transmit, convert to hard copy, copy, use or disseminate this e-mail or any 
attachments to it and you must delete this message. You are requested to notify 
the sender by return e-mail.

Re: kernel bug in file-item.c

[Zach Brown]

> Do you think you're hitting a memtest bug or is the HW really bad?

If you can stomach it, you can get a second opinion from the bootable
windows memory testing iso:

  http://oca.microsoft.com/en/windiag.asp

- z

Re: kernel bug in file-item.c

[Marc R. O'Connor]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]



Zach Brown wrote:
>> Do you think you're hitting a memtest bug or is the HW really bad?
> 
> If you can stomach it, you can get a second opinion from the bootable
> windows memory testing iso:
> 
>   http://oca.microsoft.com/en/windiag.asp
> 
> - z


It will be hard but I might just try it. Two versions of memtest86+ die
in the middle of the scan. Ugh.
-- 

--
Marc R. O'Connor
Information Systems
Camden County Board of Social Services
600 Market St.
Camden, NJ 08102
mroconnor@oel.state.nj.us
856-225-8915 Ofc.
609-206-3458 Blackberry
319D8AF1 BB PIN


[-- Attachment #2: mroconnor.vcf --]
[-- Type: text/x-vcard, Size: 260 bytes --]

begin:vcard
fn:Marc O'Connor
n:O'Connor;Marc
org:Camden County Board of Social Services;Information Technology
adr:;;600 Market St.;Camden;NJ;08102;USA
email;internet:mroconnor@oel.state.nj.us
tel;work:856-225-8915
tel;cell:609-206-3458
version:2.1
end:vcard


[-- Attachment #3: disclaimer.txt --]
[-- Type: Text/Plain, Size: 662 bytes --]

This E-mail, including any attachments, may be intended solely for the personal 
and confidential use of the sender and recipient(s) named above. This message 
may include advisory, consultative and/or deliberative material and, as such, 
would be privileged and confidential and not a public document. Any Information 
in this e-mail identifying a client of the Department of Human Services is 
confidential. If you have received this e-mail in error, you must not review, 
transmit, convert to hard copy, copy, use or disseminate this e-mail or any 
attachments to it and you must delete this message. You are requested to notify 
the sender by return e-mail.

Re: kernel bug in file-item.c

[Tracy Reed]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

On Wed, Apr 29, 2009 at 02:40:19PM -0400, Chris Mason spake thusly:
> Well, then I'm surprised btrfs doesn't crash more violently and more
> often ;)

Note that this will be a problem that btrfs must properly manage. And
it must be done MUCH better than a certain previously semi-popular
filesystem did. The expectation needs to be set that due to the much
more complicated in-memory structures being used by modern filesystems
that your hardware must be rock solid or you will get filesystem
corruption. I ran the other filesystem on hundreds of machines with no
problem (all solid hardware) but I regularly run into people (just
this morning, for example) who swear that *every*single*time* they
created a filesystem with that other fs it was corrupted in a short
amount of time. It just doesn't add up. First impressions and early
rumors can doom a filesystem (although clearly other factors such as
personalities and politics can be at play as well).

> Do you think you're hitting a memtest bug or is the HW really bad?

A bug in memtest? It's been rock solid for years hasn't it? Maybe some
new memory configuration or MMU might freak it out. Seems quite
unlikely compared to the chances of actually having bad RAM.

-- 
Tracy Reed
http://tracyreed.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: kernel bug in file-item.c

[Dmitri Nikulin]

On Thu, Apr 30, 2009 at 5:04 AM, Marc R. O'Connor
<mroconnor@oel.state.nj.us> wrote:
>> If you can stomach it, you can get a second opinion from the bootabl=
e
>> windows memory testing iso:
>>
>> =C2=A0 http://oca.microsoft.com/en/windiag.asp
>
>
> It will be hard but I might just try it. Two versions of memtest86+ d=
ie
> in the middle of the scan. Ugh.

Also try memtester in Linux. Boot up as you normally do and give it a
fair chunk of your RAM to run on. Unlike memtest it leaves all the
actual low level stuff to the kernel. Doesn't even need root, let
alone boot. At least then you can thoroughly rule out a memtest86 bug.

--=20
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia
--
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

Re: kernel bug in file-item.c

[Paul Komkoff]

On Wed, Apr 29, 2009 at 8:32 PM, Tracy Reed <treed@ultraviolet.org> wrote:
> Note that this will be a problem that btrfs must properly manage. And
> it must be done MUCH better than a certain previously semi-popular
> filesystem did. The expectation needs to be set that due to the much

I don't think it's workable or feasible or whatever.
As soon as you have faulty memory or CPU, all bets are off.
-- 
This message represents the official view of the voices in my head

Re: kernel bug in file-item.c

[Tracy Reed]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

On Thu, Apr 30, 2009 at 10:08:04AM +0100, Paul Komkoff spake thusly:
> On Wed, Apr 29, 2009 at 8:32 PM, Tracy Reed <treed@ultraviolet.org> wrote:
> > Note that this will be a problem that btrfs must properly manage. And
> > it must be done MUCH better than a certain previously semi-popular
> > filesystem did. The expectation needs to be set that due to the much
> 
> I don't think it's workable or feasible or whatever.
> As soon as you have faulty memory or CPU, all bets are off.

Sorry, I was unclear: I meant manage in a public-relations sort of
way. Not in a technical way. You are absolutely right that bad RAM or
CPU means you are hosed.

-- 
Tracy Reed
http://tracyreed.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: kernel bug in file-item.c

[Dmitri Nikulin]

On Fri, May 1, 2009 at 2:54 AM, Tracy Reed <treed@ultraviolet.org> wrote:
> Sorry, I was unclear: I meant manage in a public-relations sort of
> way. Not in a technical way. You are absolutely right that bad RAM or
> CPU means you are hosed.

Even so, it's a perfect opportunity to not make things worse by trying
to write data after fundamental assertions have already failed. My
most recent data loss scenario with ext3 involved a little
kernel/hardware/whatever glitch that would have been harmless on its
own, but ext3 took as a cue to completely mangle metadata. I found XML
config files with PNG blocks in them, etc.

-- 
Dmitri Nikulin

Centre for Synchrotron Science
Monash University
Victoria 3800, Australia