search for: btrfs_file_aio_writ

This problem is found in meego testing: http://bugs.meego.com/show_bug.cgi?id=6672 A file in btrfs is mmaped and the mmaped buffer is passed to pwrite to write to the same page of the same file. In btrfs_file_aio_write(), the pages is locked by prepare_pages(). So when btrfs_copy_from_user() is called, page fault happens and the same page needs to be locked again in filemap_fault(). The fix is to move iov_iter_fault_in_readable() before prepage_pages() to make page fault happen before pages are locked. And also...

...{+.+...}, at: [<ffffffffa025dbae>] btrfs_clear_lock_blocking+0x22/0x2b [btrfs] [ 1998.478275] [ 1998.478275] other info that might help us debug this: [ 1998.478275] 2 locks held by dd/25718: [ 1998.478275] #0: (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffffa0240d97>] btrfs_file_aio_write+0xdc/0x49a [btrfs] [ 1998.478275] #1: (&(&eb->lock)->rlock){+.+...}, at: [<ffffffffa025dbae>] btrfs_clear_lock_blocking+0x22/0x2b [btrfs] [ 1998.478275] [ 1998.478275] stack backtrace: [ 1998.478275] Pid: 25718, comm: dd Not tainted 2.6.39+ #3 [ 1998.478275] Call Trace: [ 19...

...c+0x13/0x15 Feb 10 10:59:45 testbox kernel: [ 524.496006] [<c04ab3cd>] iov_iter_copy_from_user_atomic+0x28/0x6c Feb 10 10:59:45 testbox kernel: [ 524.496006] [<f8217b41>] btrfs_copy_from_user.isra.6+0x5c/0x96 [btrfs] Feb 10 10:59:45 testbox kernel: [ 524.496006] [<f8218129>] btrfs_file_aio_write+0x480/0x79b [btrfs] Feb 10 10:59:45 testbox kernel: [ 524.496006] [<c04dd8e4>] ? mem_cgroup_update_page_stat+0x1a/0xd4 Feb 10 10:59:45 testbox kernel: [ 524.496006] [<c04e3e76>] do_sync_write+0x96/0xcf Feb 10 10:59:45 testbox kernel: [ 524.496006] [<c04e4265>] ? rw_verify_a...

...813c24b4>] btrfs_sync_log+0x424/0x5c0 [370517.206190]  [<ffffffff8139e9cb>] btrfs_sync_file+0x17b/0x1e0 [370517.206260]  [<ffffffff81160703>] vfs_fsync_range+0x23/0x30 [370517.206329]  [<ffffffff8116076c>] generic_write_sync+0x3c/0x40 [370517.206399]  [<ffffffff8139f4a7>] btrfs_file_aio_write+0x317/0x530 [370517.206472]  [<ffffffff8113556a>] do_sync_write+0xda/0x120 [370517.206544]  [<ffffffff8110037f>] ? handle_mm_fault+0x1af/0x320 [370517.206614]  [<ffffffff81135ab8>] vfs_write+0xc8/0x190 [370517.206682]  [<ffffffff81135c12>] sys_pwrite64+0x92/0xa0 [370517.206...

...6 20:06:23 eser kernel: [19365.563014] [<c0299c0c>] ? > iov_iter_copy_from_user_atomic+0x3c/0x90 > Jan 6 20:06:23 eser kernel: [19365.563014] [<f828d6da>] ? > btrfs_copy_from_user+0x5a/0xb0 [btrfs] > Jan 6 20:06:23 eser kernel: [19365.563014] [<f828e1ff>] ? > btrfs_file_aio_write+0x52f/0x9c0 [btrfs] > Jan 6 20:06:23 eser kernel: [19365.563014] [<c02d0810>] ? > __mem_cgroup_commit_charge+0x70/0xe0 > Jan 6 20:06:23 eser kernel: [19365.563014] [<c02d672c>] ? > do_sync_write+0x9c/0xd0 > Jan 6 20:06:23 eser kernel: [19365.563014] [<c02d6b15&g...

...file_mmap(struct file *filp, struct vm_area_struct *vma) const struct file_operations btrfs_file_operations = { .llseek = generic_file_llseek, .read = do_sync_read, + .write = do_sync_write, .aio_read = generic_file_aio_read, .splice_read = generic_file_splice_read, .aio_write = btrfs_file_aio_write, -- 1.6.5.2 -- 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

...9:40 xback2 kernel: [74920.681032] [<ffffffffa0423620>] prepare_pages+0xd3/0x2e7 [btrfs] Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa040aad7>] ? btrfs_delalloc_reserve_metadata+0xf9/0x128 [btrfs] Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffffa0423ca6>] btrfs_file_aio_write+0x472/0x7f1 [btrfs] Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff811346ef>] ? touch_atime+0x116/0x131 Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8112104b>] do_sync_write+0xbf/0xff Jul 8 11:49:40 xback2 kernel: [74920.681032] [<ffffffff8114db7b>] ? f...

...nr * sizeof(u32), GFP_NOFS); ins_sizes = (u32 *)ins_data; ins_keys = (struct btrfs_key *)(ins_data + nr * sizeof(u32)); --- ./fs/btrfs/file.c 2010-07-09 15:55:34.000000000 +0400 +++ /tmp/cocci-output-7826-b84666-file.c 2010-07-28 18:43:13.000000000 +0400 @@ -925,7 +925,6 @@ static ssize_t btrfs_file_aio_write(stru nrptrs = min((iov_iter_count(&i) + PAGE_CACHE_SIZE - 1) / PAGE_CACHE_SIZE, PAGE_CACHE_SIZE / (sizeof(struct page *))); - pages = kmalloc(nrptrs * sizeof(struct page *), GFP_KERNEL); /* generic_write_checks can change our pos */ start_pos = pos; --- ./fs/btrfs/inode...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I believe that I can pretty reliably reproduce the BUG mentioned in the attached dmesg output. (This doesn''t mean that you can, but I''ll detail what I''ve done here.) [This BUG is the same one that I reported last night.] 1) Create a 2 GB dynamically expanding disk. 2) Attach it to a VirtualBox machine. 3) Start the

...tem); inode->i_rdev = 0; *rdev = btrfs_stack_inode_rdev(inode_item); BTRFS_I(inode)->flags = btrfs_stack_inode_flags(inode_item); diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 431b565..f0da02b 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1404,7 +1404,6 @@ static ssize_t btrfs_file_aio_write(struct kiocb *iocb, mutex_unlock(&inode->i_mutex); goto out; } - BTRFS_I(inode)->sequence++; start_pos = round_down(pos, root->sectorsize); if (start_pos > i_size_read(inode)) { diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 7a084fb..7d3dd2f 100644 --- a/fs/bt...

V1->V2: Check to see if our current ppos is >= i_size after a short DIO read, just in case it was actually a short read and we need to just return. This is similar to what already happens in the write case. If we have a short read while doing O_DIRECT, instead of just returning, fallthrough and try to read the rest via buffered IO. BTRFS needs this because if we encounter a compressed or

...r == 0) { fi = btrfs_item_ptr(leaf, path->slots[0], @@ -747,7 +747,7 @@ again: btrfs_mark_buffer_dirty(leaf); ret = btrfs_del_items(trans, root, path, del_slot, del_nr); - BUG_ON(ret); + btrfs_fixable_bug_on(ret); } out: btrfs_free_path(path); @@ -942,7 +942,7 @@ static ssize_t btrfs_file_aio_write(struct kiocb *iocb, pinned[0] = grab_cache_page(inode->i_mapping, first_index); if (!PageUptodate(pinned[0])) { ret = btrfs_readpage(NULL, pinned[0]); - BUG_ON(ret); + btrfs_fixable_bug_on(ret); wait_on_page_locked(pinned[0]); } else { unlock_page(pinned[0]); @@ -952,7...

An user reported that he has hit an annoying deadlock while playing with ceph based on btrfs. Current updating device tree requires space from METADATA chunk, so we -may- need to do a recursive chunk allocation when adding/updating dev extent, that is where the deadlock comes from. If we use SYSTEM metadata to update device tree, we can avoid the recursive stuff. Reported-by: Jim Schutt

I''ve been working to try to improve the write-ahead log''s performance, and I found that the bottleneck addresses in the checksum items, especially when we want to make a random write on a large file, e.g a 4G file. Then a idea for this suggested by Chris is to use sub transaction ids and just to log the part of inode that had changed since either the last log commit or the last