New: kernel BUG at fs/ext4/inode.c:3123

http://bugzilla.kernel.org/show_bug.cgi?id=13369

Summary: kernel BUG at fs/ext4/inode.c:3123
Product: File System
Version: 2.5
Kernel Version: 2.6.30-rc6
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: blocking
Priority: P1
Component: ext4
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: No

Being haunted by a consistent bug in 2.6.29.[234] that kept pdflush stuck at 100% cpu, I fetched and compiled 2.6.30-rc6. Now, I keep getting "kernel BUG at fs/ext4/inode.c:3123!" (usually when I fire up ktorrent). In the attached kernel logs you can see 2 different occurences of the bug.

A nearby single core cpu, low end box has not exhibited a single bug or corruption for 3 months now, since I've converted to ext4, so I tried the "nosmp" kernel boot parameter on the dual core laptop in question. Lo and behold, the bug didn't rear its ugly head.

All partitions are mounted with "nodelalloc".

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #1 from Chris Komner <[email protected]> 2009-05-23 12:07:40 --- Created an attachment (id=21506)
--> (http://bugzilla.kernel.org/attachment.cgi?id=21506)
Kernel logs of the bug, had to pull the plug to get the second one since the box wouldn't reboot normally.

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

Eric Sandeen <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #2 from Eric Sandeen <[email protected]> 2009-05-23 15:06:18 --- This is:
static int ext4_normal_writepage(struct page *page,
struct writeback_control *wbc)
{
...
if (page_has_buffers(page)) {
/* if page has buffers it should all be mapped
* and allocated. If there are not buffers attached
* to the page we know the page is dirty but it lost
* buffers. That means that at some moment in time
* after write_begin() / write_end() has been called
* all buffers have been clean and thus they must have been
* written at least once. So they are all mapped and we can
* happily proceed with mapping them and writing the page. */
BUG_ON(walk_page_buffers(NULL, page_buffers(page), 0, len,
NULL,

                                        ext4_bh_unmapped_or_delay));
        }

Does ktorrent preallocate space? You might try turning that off to see if it goes away, as a hint. I can't look at this much today, it's my birthday and I'm going to have some non-computer fun. ;)

If you want, you could modify the test in ext4_normal_writepage() at this spot to something like:

        if (page_has_buffers(page)) {
                /*
                 * (big comment deleted)
                 */
                if (walk_page_buffers(NULL, page_buffers(page), 0, len, NULL,
                                        ext4_bh_unmapped_or_delay)) {
                        struct buffer_head *bh;

                        bh = (struct buffer_head *)page_private(page);
                        printk("bh state 0x%x\n", bh->b_state);
                        BUG();
                }
        }

so that we'd see the actual buffer head state that was wrong. (this assumes you have page-sized blocks; most likely true, if you have 4k blocks, which is the mkfs default)

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #3 from Chris Komner <[email protected]> 2009-05-23 21:40:22 --- Space preallocation is turned off in ktorrent. The modification didn't help much, but then again the block size is 1k. Additional info from dumpe2fs:

Filesystem volume name:   STORAGE
Last mounted on:          <not available>
Filesystem UUID:          7d9c4f5a-c7fe-4b2d-a02a-dc095ba40e7c
Filesystem magic number:  0xEF53

Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype
needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              10799616
Block count:              172787076
Reserved block count:     0
Free blocks:              8744435
Free inodes:              10795146
First block:              1
Block size:               1024
Fragment size:            1024
Reserved GDT blocks:      256
Blocks per group:         8192
Fragments per group:      8192
Inodes per group:         512
Inode blocks per group:   128
Flex block group size:    16
Filesystem created:       Tue Apr 28 14:51:31 2009
Last mount time:          Sat May 23 23:11:38 2009
Last write time:          Sat May 23 23:11:38 2009
Mount count:              3
Maximum mount count:      400
Last checked:             Sat May 23 10:17:43 2009
Check interval:           34560000 (13 months, 1 week, 3 days)
Next check after:         Sun Jun 27 10:17:43 2010
Lifetime writes:          5176 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:              256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      71ca129e-0529-45c7-944c-03f3ca7ddd83
Journal backup:           inode blocks
Journal size:             32M

Oh, and happy birthday!

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

With data=journal and blocksize= 1k I am seeing some problem explained here

http://bugzilla.kernel.org/show_bug.cgi?id=12624

-aneesh

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #4 from Chris Komner <[email protected]> 2009-05-23 21:46:29 --- Created an attachment (id=21510)
--> (http://bugzilla.kernel.org/attachment.cgi?id=21510)
dmesg output of the bug

kernel tree bumped to -rc6-git6

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

Theodore Tso <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #5 from Theodore Tso <[email protected]> 2009-05-24 02:52:48 --- So I'm glad you're using a filesystem with a 1k blocksize since it provides a good test case for us --- and we don't do enough testing for the case where the
blocksize != pagesize. But you do realize that the ext4 filesystem will be
far more efficient with the larger 4k blocksize, right?

I'm not able to reproduce the problem on a filesystem with 1k blocksize running fsx, fsstress, and dbench using a 2.6.30-rc6 kernel with the full ext4 patch
queue, using a netbook with an dual-core N270 Atom processor. I'm retrying
with a stock 2.6.30-rc6 kernel now...

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

It is with nodelalloc. I am also finding some unmapped buffer_heads in nodelalloc mode with data=journal. See the latest update for bug

http://bugzilla.kernel.org/show_bug.cgi?id=12624

-aneesh

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #6 from Theodore Tso <[email protected]> 2009-05-24 05:08:05 --- I've tried replicating using fsstress, fsx, and dbench using a stock 2.6.30-rc6 on a dual-core netbook and a 1k block filesystem; no luck.

I tried replicating using fsstress, fsx, and dbench using 2.6.30-rc6 + the ext4 patch queue on a x61s Lenovo laptop (Intel Core 2 Duo L7500), again with a 1k block filesystem. No luck. I'm now trying to do a bittorrent download using transmission onto the 1k block filesystem.

How easily can you reproduce the problem on your system?

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #7 from Chris Komner <[email protected]> 2009-05-24 12:02:05 --- The 1k blocksize was decided accidentally by an obsolete and forgotten /etc/mke2fs.conf, and ATM I can't back up the data and reformat 4k.

The reproduction of the problem is as easy as it gets: I just launch ktorrent and wait. Of note might be that after the bug occurs, normal reboot procedure hangs, the kernel seems to sync and remount read-only with the magic sysrq combos, but fails to reboot or poweroff and there's always some loss of data in the partition.

The latest dmesg snip follows attached.

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #8 from Chris Komner <[email protected]> 2009-05-24 12:03:48 --- Created an attachment (id=21512)
--> (http://bugzilla.kernel.org/attachment.cgi?id=21512)
yet another snip

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #9 from Eric Sandeen <[email protected]> 2009-05-24 16:32:18 --- So the modification w/ the printk didn't print anything? Must not have been the first bh on the page that was wrong, then, I didn't anticipate 1k blocks, I'll come up with another patch later that will print the state for all bh's on the page.

-Eric

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #10 from Aneesh Kumar K.V <[email protected]> 2009-05-24 18:27:55 --- With data=journal and blocksize= 1k I am seeing some problem explained
here

http://bugzilla.kernel.org/show_bug.cgi?id=12624

-aneesh

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #11 from Aneesh Kumar K.V <[email protected]> 2009-05-24 18:28:23 ---

It is with nodelalloc. I am also finding some unmapped buffer_heads in nodelalloc mode with data=journal. See the latest update for bug

http://bugzilla.kernel.org/show_bug.cgi?id=12624

-aneesh

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

Can you try with the patch series found at

http://article.gmane.org/gmane.comp.file-systems.ext4/12962
(Threading is not working for gmane currently so the two patches you may need are
http://thread.gmane.org/gmane.linux.file-systems/31465
http://thread.gmane.org/gmane.comp.file-systems.ext4/12960
)

I guess mmap and truncate combination can result in we missing pagefault when we write to second block in the same page. That would mean we may have to do block allocation in writepage.

-aneesh

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #12 from Aneesh Kumar K.V <[email protected]> 2009-05-24 19:20:34 --- Can you try with the patch series found at

http://article.gmane.org/gmane.comp.file-systems.ext4/12962
(Threading is not working for gmane currently so the two patches you may need are
http://thread.gmane.org/gmane.linux.file-systems/31465
http://thread.gmane.org/gmane.comp.file-systems.ext4/12960
)

I guess mmap and truncate combination can result in we missing pagefault when we write to second block in the same page. That would mean we may have to do block allocation in writepage.

-aneesh

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

Will you be able to try these patches. They are on top of stable patch from the ext4 patch queue found at

http://repo.or.cz/w/ext4-patch-queue.git

Apply the patches upto stable-boundary-undo.patch

Then apply the below five patches. Apply them in the below order.

page_cache_size.patch
1.patch
2.patch
unmap_or_unwritten
ext4_writepage

-aneesh

ext4: Don't look at buffer_heads outside i_size.

From: Aneesh Kumar K.V <[email protected]>

Buffer heads outside i_size will be unmapped. So when we are doing "walk_page_buffers" limit ourself to i_size.

---
 fs/ext4/inode.c |   29 ++++++++++++++++++-----------
 1 files changed, 18 insertions(+), 11 deletions(-)

index 6e5caa7..ebf7bb3 100644
@@ -2514,7 +2514,7 @@ static int ext4_da_writepage(struct page *page,
 		 * all are mapped and non delay. We don't want to
 		 * do block allocation here.
 		 */
-		ret = block_prepare_write(page, 0, PAGE_CACHE_SIZE,
+		ret = block_prepare_write(page, 0, len,
 					  noalloc_get_block_write);
 		if (!ret) {
 			page_bufs = page_buffers(page);

@@ -2536,7 +2536,7 @@ static int ext4_da_writepage(struct page *page,
 			return 0;
 		}
 		/* now mark the buffer_heads as dirty and uptodate */
-		block_commit_write(page, 0, PAGE_CACHE_SIZE);
+		block_commit_write(page, 0, len);
 	}
 
 	if (test_opt(inode->i_sb, NOBH) && ext4_should_writeback_data(inode))

@@ -3210,6 +3210,8 @@ static int ext4_normal_writepage(struct page *page,
 static int __ext4_journalled_writepage(struct page *page,
 				struct writeback_control *wbc)
 {
+	loff_t size;
+	unsigned int len;
 	struct address_space *mapping = page->mapping;
 	struct inode *inode = mapping->host;
 	struct buffer_head *page_bufs;

@@ -3217,14 +3219,19 @@ static int __ext4_journalled_writepage(struct page *page,
 	int ret = 0;
 	int err;
 
-	ret = block_prepare_write(page, 0, PAGE_CACHE_SIZE,
+	size = i_size_read(inode);
+	if (page->index == size >> PAGE_CACHE_SHIFT)
+		len = size & ~PAGE_CACHE_MASK;
+	else
+		len = PAGE_CACHE_SIZE;
+
+	ret = block_prepare_write(page, 0, len,
 				  noalloc_get_block_write);
 	if (ret != 0)
 		goto out_unlock;
 
 	page_bufs = page_buffers(page);
-	walk_page_buffers(handle, page_bufs, 0, PAGE_CACHE_SIZE, NULL,
-								bget_one);
+	walk_page_buffers(handle, page_bufs, 0, len, NULL, bget_one);
 	/* As soon as we unlock the page, it can go away, but we have
 	 * references to buffers so we are safe */
 	unlock_page(page);

@@ -3235,19 +3242,19 @@ static int __ext4_journalled_writepage(struct page *page,
 		goto out;
 	}
 
-	ret = walk_page_buffers(handle, page_bufs, 0,
-			PAGE_CACHE_SIZE, NULL, do_journal_get_write_access);
+	ret = walk_page_buffers(handle, page_bufs, 0, len,
+				NULL, do_journal_get_write_access);
 
-	err = walk_page_buffers(handle, page_bufs, 0,
-				PAGE_CACHE_SIZE, NULL, write_end_fn);
+	err = walk_page_buffers(handle, page_bufs, 0, len,
+				NULL, write_end_fn);
 	if (ret == 0)
 		ret = err;
 	err = ext4_journal_stop(handle);
 	if (!ret)
 		ret = err;
 
-	walk_page_buffers(handle, page_bufs, 0,
-				PAGE_CACHE_SIZE, NULL, bput_one);
+	walk_page_buffers(handle, page_bufs, 0, len,
+				NULL, bput_one);
 	EXT4_I(inode)->i_state |= EXT4_STATE_JDATA;
 	goto out;
 

page_mkwrite() is meant to be used by filesystems to allocate blocks under a

From: Jan Kara <[email protected]>

page which is becoming writeably mmapped in some process address space. This allows a filesystem to return a page fault if there is not enough space available, user exceeds quota or similar problem happens, rather than silently discarding data later when writepage is called.

On filesystems where blocksize < pagesize the situation is more complicated. Think for example that blocksize = 1024, pagesize = 4096 and a process does:
ftruncate(fd, 0);
pwrite(fd, buf, 1024, 0);
map = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED, fd, 0);
map[0] = 'a'; ----> page_mkwrite() for index 0 is called ftruncate(fd, 10000); /* or even pwrite(fd, buf, 1, 10000) */ fsync(fd); ----> writepage() for index 0 is called

At the moment page_mkwrite() is called, filesystem can allocate only one block for the page because i_size == 1024. Otherwise it would create blocks beyond i_size which is generally undesirable. But later at writepage() time, we would like to have blocks allocated for the whole page (and in principle we have to allocate them because user could have filled the page with data after the second ftruncate()). This patch introduces a framework which allows filesystems to handle this with a reasonable effort.

The idea is following: Before we extend i_size, we obtain a special lock blocking page_mkwrite() on the page straddling i_size. Then we writeprotect the page, change i_size and unlock the special lock. This way, page_mkwrite() is called for a page each time a number of blocks needed to be allocated for a page increases.

---
 fs/buffer.c                 |  130 +++++++++++++++++++++++++++++++++++++++++++
 include/linux/buffer_head.h |    4 +
 include/linux/fs.h          |   11 +++-
 mm/filemap.c                |   10 +++
 mm/memory.c                 |    2 -
 5 files changed, 153 insertions(+), 4 deletions(-)

index 16ed028..56a0162 100644
@@ -219,6 +219,10 @@ int cont_write_begin(struct file *, struct address_space *, loff_t,
 			get_block_t *, loff_t *);
 int generic_cont_expand_simple(struct inode *inode, loff_t size);
 int block_commit_write(struct page *page, unsigned from, unsigned to);
+int block_lock_hole_extend(struct inode *inode, loff_t pos);
+void block_unlock_hole_extend(struct inode *inode);
+int block_wait_on_hole_extend(struct inode *inode, loff_t pos);
+void block_extend_i_size(struct inode *inode, loff_t pos, loff_t len);
 int block_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf,
 				get_block_t get_block);
 void block_sync_page(struct page *);

index 3b534e5..7cbb0c2 100644
@@ -580,7 +580,7 @@ struct address_space_operations {
 	int (*write_end)(struct file *, struct address_space *mapping,
 				loff_t pos, unsigned len, unsigned copied,
 				struct page *page, void *fsdata);
-
+	void (*extend_i_size)(struct inode *, loff_t pos, loff_t len);
 	/* Unfortunately this kludge is needed for FIBMAP. Don't use it */
 	sector_t (*bmap)(struct address_space *, sector_t);
 	void (*invalidatepage) (struct page *, unsigned long);

@@ -597,6 +597,8 @@ struct address_space_operations {
 					unsigned long);
 };
 
+void do_extend_i_size(struct inode *inode, loff_t pos, loff_t len);
+
 /*
  * pagecache_write_begin/pagecache_write_end must be used by general code
  * to write into the pagecache.

@@ -1590,7 +1592,8 @@ struct super_operations {
  * until that flag is cleared.  I_WILL_FREE, I_FREEING and I_CLEAR are set at
  * various stages of removing an inode.
  *
- * Two bits are used for locking and completion notification, I_LOCK and I_SYNC.
+ * Three bits are used for locking and completion notification, I_LOCK,
+ * I_HOLE_EXTEND and I_SYNC.
  *
  * I_DIRTY_SYNC		Inode is dirty, but doesn't have to be written on
  *			fdatasync().  i_atime is the usual cause.

@@ -1628,6 +1631,8 @@ struct super_operations {
  *			of inode dirty data.  Having a separate lock for this
  *			purpose reduces latency and prevents some filesystem-
  *			specific deadlocks.
+ * I_HOLE_EXTEND	A lock synchronizing extension of a file which creates
+ *			a hole under a mmapped page with page_mkwrite().
  *
  * Q: What is the difference between I_WILL_FREE and I_FREEING?
  * Q: igrab() only checks on (I_FREEING|I_WILL_FREE).  Should it also check on

@@ -1644,6 +1649,8 @@ struct super_operations {
 #define I_LOCK			(1 << __I_LOCK)
 #define __I_SYNC		8
 #define I_SYNC			(1 << __I_SYNC)
+#define __I_HOLE_EXTEND		9
+#define I_HOLE_EXTEND		(1 << __I_HOLE_EXTEND)
 
 #define I_DIRTY (I_DIRTY_SYNC | I_DIRTY_DATASYNC | I_DIRTY_PAGES)
 

index 379ff0b..a227174 100644
@@ -2079,6 +2079,14 @@ int pagecache_write_end(struct file *file, struct address_space *mapping,
 }
 EXPORT_SYMBOL(pagecache_write_end);
 
+void do_extend_i_size(struct inode *inode, loff_t pos, loff_t len)
+{
+	if (inode->i_mapping->a_ops->extend_i_size)
+		inode->i_mapping->a_ops->extend_i_size(inode, pos, len);
+	else
+		i_size_write(inode, pos + len);
+}
+
 ssize_t
 generic_file_direct_write(struct kiocb *iocb, const struct iovec *iov,
 		unsigned long *nr_segs, loff_t pos, loff_t *ppos,

@@ -2139,7 +2147,7 @@ generic_file_direct_write(struct kiocb *iocb, const struct iovec *iov,
 	if (written > 0) {
 		loff_t end = pos + written;
 		if (end > i_size_read(inode) && !S_ISBLK(inode->i_mode)) {
-			i_size_write(inode,  end);
+			do_extend_i_size(inode, pos, written);
 			mark_inode_dirty(inode);
 		}
 		*ppos = end;

index 4126dd1..535183d 100644
@@ -2377,7 +2377,7 @@ int vmtruncate(struct inode * inode, loff_t offset)
 			goto out_sig;
 		if (offset > inode->i_sb->s_maxbytes)
 			goto out_big;
-		i_size_write(inode, offset);
+		do_extend_i_size(inode, offset, 0);
 	} else {
 		struct address_space *mapping = inode->i_mapping;
 

In a situation like:

From: Jan Kara <[email protected]>

truncate(f, 1024);
a = mmap(f, 0, 4096);
a[0] = 'a';
truncate(f, 4096);

we end up with a dirty page which does not have all blocks allocated / reserved. Fix the problem by using new VFS infrastructure.

---
 fs/ext4/inode.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

index ebf7bb3..f0f0065 100644
@@ -3469,6 +3469,7 @@ static int ext4_journalled_set_page_dirty(struct page *page)
 	.sync_page		= block_sync_page,
 	.write_begin		= ext4_write_begin,
 	.write_end		= ext4_ordered_write_end,
+	.extend_i_size		= block_extend_i_size,
 	.bmap			= ext4_bmap,
 	.invalidatepage		= ext4_invalidatepage,
 	.releasepage		= ext4_releasepage,

@@ -3484,6 +3485,7 @@ static int ext4_journalled_set_page_dirty(struct page *page)
 	.sync_page		= block_sync_page,
 	.write_begin		= ext4_write_begin,
 	.write_end		= ext4_writeback_write_end,
+	.extend_i_size		= block_extend_i_size,
 	.bmap			= ext4_bmap,
 	.invalidatepage		= ext4_invalidatepage,
 	.releasepage		= ext4_releasepage,

@@ -3499,6 +3501,7 @@ static int ext4_journalled_set_page_dirty(struct page *page)
 	.sync_page		= block_sync_page,
 	.write_begin		= ext4_write_begin,
 	.write_end		= ext4_journalled_write_end,
+	.extend_i_size		= block_extend_i_size,
 	.set_page_dirty		= ext4_journalled_set_page_dirty,
 	.bmap			= ext4_bmap,
 	.invalidatepage		= ext4_invalidatepage,

@@ -3514,6 +3517,7 @@ static int ext4_journalled_set_page_dirty(struct page *page)
 	.sync_page		= block_sync_page,
 	.write_begin		= ext4_da_write_begin,
 	.write_end		= ext4_da_write_end,
+	.extend_i_size		= block_extend_i_size,
 	.bmap			= ext4_bmap,
 	.invalidatepage		= ext4_da_invalidatepage,
 	.releasepage		= ext4_releasepage,

@@ -5379,6 +5383,12 @@ int ext4_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf)
 	struct address_space *mapping = inode->i_mapping;
 
 	/*
+	 * Wait for extending of i_size, after this moment, next truncate /
+	 * write can create holes under us but they writeprotect our page so
+	 * we'll be called again to fill the hole.
+	 */
+	block_wait_on_hole_extend(inode, page_offset(page));
+	/*
 	 * Get i_alloc_sem to stop truncates messing with the inode. We cannot
 	 * get i_mutex because we are already holding mmap_sem.
 	 */

ext4: Check for only delay or unwritten buffer_heads

From: Aneesh Kumar K.V <[email protected]>

---
 fs/ext4/inode.c |   21 +++++++--------------
 1 files changed, 7 insertions(+), 14 deletions(-)

index f0f0065..1efb296 100644
@@ -2239,15 +2239,9 @@ static void mpage_add_bh_to_extent(struct mpage_da_data *mpd,
 	return;
 }
 
-static int ext4_bh_unmapped_or_delay(handle_t *handle, struct buffer_head *bh)
+static int ext4_bh_delay_or_unwritten(handle_t *handle, struct buffer_head *bh)
 {
-	/*
-	 * unmapped buffer is possible for holes.
-	 * delay buffer is possible with delayed allocation.
-	 * We also need to consider unwritten buffer as unmapped.
-	 */
-	return (!buffer_mapped(bh) || buffer_delay(bh) ||
-				buffer_unwritten(bh)) && buffer_dirty(bh);
+	return (buffer_delay(bh) || buffer_unwritten(bh)) && buffer_dirty(bh);
 }
 
 /*

@@ -2334,7 +2328,7 @@ static int __mpage_da_writepage(struct page *page,
 			 * Otherwise we won't make progress
 			 * with the page in ext4_da_writepage
 			 */
-			if (ext4_bh_unmapped_or_delay(NULL, bh)) {
+			if (ext4_bh_delay_or_unwritten(NULL, bh)) {
 				mpage_add_bh_to_extent(mpd, logical,
 						       bh->b_size,
 						       bh->b_state);

@@ -2451,7 +2445,6 @@ static int noalloc_get_block_write(struct inode *inode, sector_t iblock,
 	 * so call get_block_wrap with create = 0
 	 */
 	ret = ext4_get_blocks(NULL, inode, iblock, max_blocks, bh_result, 0);
-	BUG_ON(create && ret == 0);
 	if (ret > 0) {
 		bh_result->b_size = (ret << inode->i_blkbits);
 		ret = 0;

@@ -2487,7 +2480,7 @@ static int ext4_da_writepage(struct page *page,
 	if (page_has_buffers(page)) {
 		page_bufs = page_buffers(page);
 		if (walk_page_buffers(NULL, page_bufs, 0, len, NULL,
-					ext4_bh_unmapped_or_delay)) {
+					ext4_bh_delay_or_unwritten)) {
 			/*
 			 * We don't want to do  block allocation
 			 * So redirty the page and return

@@ -2520,7 +2513,7 @@ static int ext4_da_writepage(struct page *page,
 			page_bufs = page_buffers(page);
 			/* check whether all are mapped and non delay */
 			if (walk_page_buffers(NULL, page_bufs, 0, len, NULL,
-						ext4_bh_unmapped_or_delay)) {
+						ext4_bh_delay_or_unwritten)) {
 				redirty_page_for_writepage(wbc, page);
 				unlock_page(page);
 				return 0;

@@ -3196,7 +3189,7 @@ static int ext4_normal_writepage(struct page *page,
 		 * happily proceed with mapping them and writing the page.
 		 */
 		BUG_ON(walk_page_buffers(NULL, page_buffers(page), 0, len, NULL,
-					ext4_bh_unmapped_or_delay));
+					ext4_bh_delay_or_unwritten));
 	}
 
 	if (!ext4_journal_current_handle())

@@ -3291,7 +3284,7 @@ static int ext4_journalled_writepage(struct page *page,
 		 * happily proceed with mapping them and writing the page.
 		 */
 		BUG_ON(walk_page_buffers(NULL, page_buffers(page), 0, len, NULL,
-					ext4_bh_unmapped_or_delay));
+					ext4_bh_delay_or_unwritten));
 	}
 
 	if (ext4_journal_current_handle())

ext4: Add generic writepage callback

From: Aneesh Kumar K.V <[email protected]>

---
 fs/ext4/inode.c |  338 +++++++++++++++++--------------------------------------
 1 files changed, 104 insertions(+), 234 deletions(-)

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #13 from Chris Komner <[email protected]> 2009-05-24 20:43:22 --- I applied both patches, recompiled and rebooted. A few seconds after ktorrent started, I got this:

kernel BUG at fs/ext4/inode.c:3123!
invalid opcode: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

Modules linked in: nvidia(P) oss_usb oss_hdaudio osscore aes_i586 aes_generic

ipt_MASQUERADE ipt_REDIRECT xt_multiport xt_tcpudp xt_conntrack xt_state iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_filter ip_tables x_tables uvcvideo videodev v4l1_compat uhci_hcd sr_mod ohci1394 sdhci_pci sdhci ieee1394 cdrom mmc_core ehci_hcd ac button battery sg i2c_i801 usbcore i2c_core psmouse ata_piix evdev arc4 ecb iwl3945 iwlcore mac80211 led_class cfg80211 fuse dell_laptop backlight rfkill b44 dcdbas mii rtc_cmos rtc_core rtc_lib [last unloaded: soundcore]

Pid: 1060, comm: kjournald2 Tainted: P (2.6.30-rc6-git6 #2) Vostro
1500
EIP: 0060:[<c01ffd13>] EFLAGS: 00010202 CPU: 1
EIP is at ext4_normal_writepage+0x183/0x190
EAX: 00000001 EBX: c28cb8e0 ECX: 00001000 EDX: 00000000
ESI: 00001000 EDI: 00000000 EBP: f756be00 ESP: f756bdd4
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process kjournald2 (pid: 1060, ti=f756a000 task=f6d33390 task.ti=f756a000)

Stack:
 00001000 00000000 c01fc0f0 8000082d 0000000c 00000000 f756bf1c 10541259
 eb4d7d30 00000002 eb4d7d30 f756bea0 c01780d7 10541259 c28cb8e0 c01789b9
 00000000 00000007 10541259 00000000 00000001 eb4d7d30 c01780c0 f74fc0a8
Call Trace:
 [<c01fc0f0>] ? ext4_bh_unmapped_or_delay+0x0/0x50
 [<c01780d7>] ? __writepage+0x17/0x60
 [<c01789b9>] ? write_cache_pages+0x1a9/0x3f0
 [<c01780c0>] ? __writepage+0x0/0x60
 [<c01ffb90>] ? ext4_normal_writepage+0x0/0x190
 [<c0178c27>] ? generic_writepages+0x27/0x50
 [<c02228d2>] ? jbd2_journal_commit_transaction+0x3b2/0x12b0
 [<c013eeaf>] ? try_to_del_timer_sync+0x4f/0x70
 [<c0227a87>] ? kjournald2+0xd7/0x230
 [<c014c430>] ? autoremove_wake_function+0x0/0x60
 [<c02279b0>] ? kjournald2+0x0/0x230
 [<c014c002>] ? kthread+0x52/0xa0
 [<c014bfb0>] ? kthread+0x0/0xa0
 [<c0103d67>] ? kernel_thread_helper+0x7/0x10
Code: 00 00 00 75 21 8b 4c 24 18 89 d8 83 c4 20 ba b0 17 20 c0 5b 5e 5f c9 e9
fc e5 fc ff f3 90 8b 4f 48 e9 b4 fe ff ff e8 6d 30 f3 ff <0f> 0b eb fe 0f 0b eb
fe 90 8d 74 26 00 55 89 e5 57 56 89 ce 53 
EIP: [<c01ffd13>] ext4_normal_writepage+0x183/0x190 SS:ESP 0068:f756bdd4
---[ end trace d3629642779515bf ]---

In between, I had booted the stock archlinux kernel, version 2.6.29.4 and I couldn't reproduce the bug; instead I got these errors, which might be odd because I had just e2fsck'ed the device:
ext4: find_group_flex failed, fallback succeeded dir 572486
ext4: find_group_flex failed, fallback succeeded dir 572439
ext4: find_group_flex failed, fallback succeeded dir 572469
ext4: find_group_flex failed, fallback succeeded dir 572470
ext4: find_group_flex failed, fallback succeeded dir 572478
ext4: find_group_flex failed, fallback succeeded dir 572444
ext4: find_group_flex failed, fallback succeeded dir 572477
ext4: find_group_flex failed, fallback succeeded dir 572447
ext4: find_group_flex failed, fallback succeeded dir 572482
ext4: find_group_flex failed, fallback succeeded dir 572446

Fsck is always needed for this partition, after the inode.c bug and the mandatory cold reboot, otherwise it aborts:
ext4_abort called.
EXT4-fs error (device sda9): ext4_put_super: Couldn't clean up the journal

My kernel .config follows.

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #14 from Chris Komner <[email protected]> 2009-05-24 20:44:26 --- Created an attachment (id=21520)
--> (http://bugzilla.kernel.org/attachment.cgi?id=21520)
kernel .config

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #15 from Aneesh Kumar K.V <[email protected]> 2009-05-26 13:16:29 --- Will you be able to try these patches. They are on top
of stable patch from the ext4 patch queue found at

http://repo.or.cz/w/ext4-patch-queue.git

Apply the patches upto stable-boundary-undo.patch

Then apply the below five patches. Apply them in the below order.

page_cache_size.patch
1.patch
2.patch
unmap_or_unwritten
ext4_writepage

-aneesh

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

--- Comment #16 from Chris Komner <[email protected]> 2009-05-27 21:32:01 --- Patches applied 24 hours ago and no bugs whatsoever, so far. Thanks.

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.kernel.org/show_bug.cgi?id=13369

Eric Sandeen <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

         AssignedTo|[email protected] |[email protected]
                   |g                           |

--- Comment #17 from Eric Sandeen <[email protected]> 2009-08-18 17:38:22 --- Assigning to myself just so I can close.

Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.