[PATCH] extra checking for in-inode EAs
When investigating the EA problem reported on this list, I noticed that some
of the checks for the in-inode EAs were removed (possibly when the unordered
EAs-in-inode patch was removed). The following patch returns the checks for
the e_value_offs. This passes make check with the Lustre EA test cases.
A more complete check (not implemented here) would be to ensure that
the EAs don't overlap as is done with the external EAs. Some extra
whitespace is removed in the first hunk.
Signed-off-by: Andreas Dilger [EMAIL PROTECTED]
--- e2fsck/pass1.c.orig 2008-02-04 10:41:50.0 -0700
+++ e2fsck/pass1.c 2008-02-04 17:36:34.0 -0700
@@ -268,14 +268,14 @@
/* scan all entry's headers first */
/* take finish entry 0UL into account */
- remain = storage_size - sizeof(__u32);
+ remain = storage_size - sizeof(__u32);
while (!EXT2_EXT_IS_LAST_ENTRY(entry)) {
__u32 hash;
/* header eats this space */
remain -= sizeof(struct ext2_ext_attr_entry);
-
+
/* is attribute name valid? */
if (EXT2_EXT_ATTR_SIZE(entry-e_name_len) remain) {
pctx-num = entry-e_name_len;
@@ -293,6 +293,21 @@
goto fix;
}
+ /* check value placement */
+ if (start + entry-e_value_offs end) {
+ pctx-num = entry-e_value_offset;
+ problem = PR_1_ATTR_VALUE_OFFSET;
+ goto fix;
+ }
+
+ /* check value offset + size */
+ if (start + entry-e_value_offs +
+ EXT2_XATTR_SIZE(entry-e_value_size) end) {
+ pctx-num = entry-e_value_size;
+ problem = PR_1_ATTR_VALUE_SIZE;
+ goto fix;
+ }
+
/* e_value_block must be 0 in inode's ea */
if (entry-e_value_block != 0) {
pctx-num = entry-e_value_block;
@@ -310,7 +325,7 @@
goto fix;
}
- remain -= entry-e_value_size;
+ remain -= EXT2_XATTR_SIZE(entry-e_value_size);
entry = EXT2_EXT_ATTR_NEXT(entry);
}
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: merge plans, was Re: - disable-ext4.patch removed from -mm tree
On Tue, 5 Feb 2008 10:44:54 +0100 Christoph Hellwig [EMAIL PROTECTED] wrote: On Mon, Feb 04, 2008 at 02:35:29PM -0800, Andrew Morton wrote: On Mon, 4 Feb 2008 15:24:18 -0500 Christoph Hellwig [EMAIL PROTECTED] wrote: On Sun, Feb 03, 2008 at 07:15:40PM -0800, Andrew Morton wrote: On Sun, 3 Feb 2008 20:36:26 -0500 Theodore Tso [EMAIL PROTECTED] wrote: On Sun, Feb 03, 2008 at 12:25:51PM -0800, Andrew Morton wrote: When I merge David's iget coversion patches this will instead wreck the ext4 patchset. That's ok, it shouldn't be hard for me to fix this up. How quickly will you be able to merge David's iget converstion patches? They're about 1,000 patches back Care to post a merge plan so we have a slight chance to make sure not too much crap is hiding in these 1000 patches? Pretty much everything up to # # end # reiser4-sb_sync_inodes.patch That includes the git trees? No, I don't merge git trees. Defintive NACK to unionfs. Agree, but it'd be nice to get some movement and resolution here. The thing's actively and enthusiastically maintained and is apparently useful. There's not much point in allowing developers to expend cycles on something which doesn't have a future. - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: merge plans, was Re: - disable-ext4.patch removed from -mm tree
On Mon, Feb 04, 2008 at 02:35:29PM -0800, Andrew Morton wrote: On Mon, 4 Feb 2008 15:24:18 -0500 Christoph Hellwig [EMAIL PROTECTED] wrote: On Sun, Feb 03, 2008 at 07:15:40PM -0800, Andrew Morton wrote: On Sun, 3 Feb 2008 20:36:26 -0500 Theodore Tso [EMAIL PROTECTED] wrote: On Sun, Feb 03, 2008 at 12:25:51PM -0800, Andrew Morton wrote: When I merge David's iget coversion patches this will instead wreck the ext4 patchset. That's ok, it shouldn't be hard for me to fix this up. How quickly will you be able to merge David's iget converstion patches? They're about 1,000 patches back Care to post a merge plan so we have a slight chance to make sure not too much crap is hiding in these 1000 patches? Pretty much everything up to # # end # reiser4-sb_sync_inodes.patch That includes the git trees? Defintive NACK to unionfs. - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: - disable-ext4.patch removed from -mm tree
Andrew Morton [EMAIL PROTECTED] wrote: Last time I discussed this with David he seemed to find this amusing rather than an urgent problem. Amusing? In what way? I've been at LCA, and I left all but one of my machines powered down because the local substation broke and has been giving wildly variable voltages, if at all. I've had to replace two PSUs because of this. That's made it hard to test stuff remotely. If you wish to view this as amusing, then by all means do so. David - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Handle unusual results from find_tempdir.
An alternative: make find_tempdir set tempdir to default_tempdir upon malloc failure. * arch/um/os-Linux/mem.c (make_tempfile): Handle NULL tempdir. Don't let a long tempdir (e.g., via TMPDIR) provoke heap corruption. Signed-off-by: Jim Meyering [EMAIL PROTECTED] --- arch/um/os-Linux/mem.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/um/os-Linux/mem.c b/arch/um/os-Linux/mem.c index e114d09..1458385 100644 --- a/arch/um/os-Linux/mem.c +++ b/arch/um/os-Linux/mem.c @@ -176,6 +176,9 @@ int __init make_tempfile(const char *template, char **out_tempname, return -1; find_tempdir(); + if (tempdir == NULL || strlen(tempdir) = MAXPATHLEN) + return -1; + if (template[0] != '/') strcpy(tempname, tempdir); else -- 1.5.4.19.gd3dfd - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: jbd2_handle and i_data_sem circular locking dependency detected
On Mon, Feb 04, 2008 at 05:31:56PM +0100, Jan Kara wrote:
Hi,
On Mon 04-02-08 15:42:28, Aneesh Kumar K.V wrote:
This is with the new ext3 - ext4 migrate code added. The recently added
lockdep for jbd2 helped to find this out. We want to hold the i_data_sem
on the ext3 inode during migration to prevent walking the ext3 inode
when it is being converted to ext4 format. Also we want to avoid
file truncation and new blocks being added while converting to ext4.
Also we dont want to reserve large number of credits for journal.
Any idea how to fix this ?
Hmm, while briefly looking at the code - why do you introduce i_data_sem
and not use i_alloc_sem which is already in VFS inode? That is aimed
exactly at the serialization of truncates, writes and similar users.
That doesn't solve problems with lock ordering but I was just wondering...
Another problem - ext4_fallocate() has the same lock ordering problem as
the migration code and maybe there are others...
One (stupid) solution to your problem is to make i_data_sem be
always locked before the transaction is started. It could possibly have
negative performance impact because you'd have to hold the semaphore for
a longer time and thus a writer would block readers for longer time. So one
would have to measure how big difference that would make.
Another possibility is to start a single transaction for migration and
extend it as long as you can (as truncate does it). And when you can't
extend any more, you drop the i_data_sem and start a new transaction and
acquire the semaphore again. This has the disadvantage that after dropping
the semaphore you have to resync your original inode with the temporary
one your are building which probably ends up being ugly as night... Hmm,
but maybe we could get rid of this - hold i_mutex to protect against all
writes (that ranks outside of transaction start so you can hold it for the
whole migration time - maybe you even hold it if you are called from the
write path...). After dropping i_data_sem you let some readers proceed
but writers still wait on i_mutex so the file shouldn't change under you
(but I suggest adding some BUG_ONs to verify that the file really doesn't
change :).
How about the patch below. I did the below testing
a) migrate a file
b) run fs_inode fsstres fsx_linux.
The intention was to find out whether the new locking is breaking any of
the other expected hierarchy. It seems to fine. I didn't get any lockdep
warning.
ext4: Fix circular locking dependency with migrate and rm.
From: Aneesh Kumar K.V [EMAIL PROTECTED]
We now take inode-i_mutex lock to prevent any update of the inode i_data
field. Before we switch the inode format we take i_data_sem to prevent
parallel read.
===
[ INFO: possible circular locking dependency detected ]
2.6.24-rc8 #6
---
rm/2401 is trying to acquire lock:
(ei-i_data_sem){}, at: [c01dca58] ext4_get_blocks_wrap+0x21/0x108
but task is already holding lock:
(jbd2_handle){--..}, at: [c01fc4a7] jbd2_journal_start+0xd2/0xff
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #1 (jbd2_handle){--..}:
[c0143a5c] __lock_acquire+0xa31/0xc1a
[c0143cbf] lock_acquire+0x7a/0x94
[c01fc4ca] jbd2_journal_start+0xf5/0xff
[c01e3539] ext4_journal_start_sb+0x48/0x4a
[c01eb980] ext4_ext_migrate+0x7d/0x535
[c01df328] ext4_ioctl+0x528/0x56c
[c0177700] do_ioctl+0x50/0x67
[c017794e] vfs_ioctl+0x237/0x24a
[c0177992] sys_ioctl+0x31/0x4b
[c0104f8a] sysenter_past_esp+0x5f/0xa5
[] 0x
- #0 (ei-i_data_sem){}:
[c014394c] __lock_acquire+0x921/0xc1a
[c0143cbf] lock_acquire+0x7a/0x94
[c044f247] down_read+0x42/0x79
[c01dca58] ext4_get_blocks_wrap+0x21/0x108
[c01dcba1] ext4_getblk+0x62/0x1c4
[c01e0de9] ext4_find_entry+0x350/0x5b7
[c01e200c] ext4_unlink+0x6e/0x1a4
[c017449e] vfs_unlink+0x49/0x89
[c0175f02] do_unlinkat+0x96/0x12c
[c0175fa8] sys_unlink+0x10/0x12
[c0104f8a] sysenter_past_esp+0x5f/0xa5
[] 0x
other info that might help us debug this:
3 locks held by rm/2401:
#0: (type-i_mutex_dir_key#5/1){--..}, at: [c0175eca]
do_unlinkat+0x5e/0x12c
#1: (sb-s_type-i_mutex_key#8){--..}, at: [c017448b] vfs_unlink+0x36/0x89
#2: (jbd2_handle){--..}, at: [c01fc4a7] jbd2_journal_start+0xd2/0xff
stack backtrace:
Pid: 2401, comm: rm Not tainted 2.6.24-rc8 #6
[c0106017] show_trace_log_lvl+0x1a/0x2f
[c0106893] show_trace+0x12/0x14
[c0106b89] dump_stack+0x6c/0x72
[c0141b26] print_circular_bug_tail+0x5f/0x68
[c014394c] __lock_acquire+0x921/0xc1a
[c0143cbf] lock_acquire+0x7a/0x94
[c044f247] down_read+0x42/0x79
[c01dca58] ext4_get_blocks_wrap+0x21/0x108
[c01dcba1] ext4_getblk+0x62/0x1c4
[c01e0de9]
[PATCH] Handle failed malloc.
* lib/inflate.c (inflate_dynamic): Don't deref NULL upon failed malloc. * arch/um/os-Linux/mem.c (make_tempfile): Likewise. Signed-off-by: Jim Meyering [EMAIL PROTECTED] --- arch/um/os-Linux/mem.c |2 ++ lib/inflate.c |3 +++ 2 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/um/os-Linux/mem.c b/arch/um/os-Linux/mem.c index 436f8d2..e114d09 100644 --- a/arch/um/os-Linux/mem.c +++ b/arch/um/os-Linux/mem.c @@ -172,6 +172,8 @@ int __init make_tempfile(const char *template, char **out_tempname, which_tmpdir(); tempname = malloc(MAXPATHLEN); + if (tempname == NULL) + return -1; find_tempdir(); if (template[0] != '/') diff --git a/lib/inflate.c b/lib/inflate.c index 845f91d..9762294 100644 --- a/lib/inflate.c +++ b/lib/inflate.c @@ -811,6 +811,9 @@ DEBG(dyn); ll = malloc(sizeof(*ll) * (286+30)); /* literal/length and distance code lengths */ #endif + if (ll == NULL) +return 1; + /* make local bit buffer */ b = bb; k = bk; -- 1.5.4.19.gd3dfd - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: jbd2_handle and i_data_sem circular locking dependency detected
On Tue 05-02-08 17:53:42, Aneesh Kumar K.V wrote:
On Mon, Feb 04, 2008 at 05:31:56PM +0100, Jan Kara wrote:
Hi,
On Mon 04-02-08 15:42:28, Aneesh Kumar K.V wrote:
This is with the new ext3 - ext4 migrate code added. The recently added
lockdep for jbd2 helped to find this out. We want to hold the i_data_sem
on the ext3 inode during migration to prevent walking the ext3 inode
when it is being converted to ext4 format. Also we want to avoid
file truncation and new blocks being added while converting to ext4.
Also we dont want to reserve large number of credits for journal.
Any idea how to fix this ?
Hmm, while briefly looking at the code - why do you introduce i_data_sem
and not use i_alloc_sem which is already in VFS inode? That is aimed
exactly at the serialization of truncates, writes and similar users.
That doesn't solve problems with lock ordering but I was just wondering...
Another problem - ext4_fallocate() has the same lock ordering problem as
the migration code and maybe there are others...
One (stupid) solution to your problem is to make i_data_sem be
always locked before the transaction is started. It could possibly have
negative performance impact because you'd have to hold the semaphore for
a longer time and thus a writer would block readers for longer time. So one
would have to measure how big difference that would make.
Another possibility is to start a single transaction for migration and
extend it as long as you can (as truncate does it). And when you can't
extend any more, you drop the i_data_sem and start a new transaction and
acquire the semaphore again. This has the disadvantage that after dropping
the semaphore you have to resync your original inode with the temporary
one your are building which probably ends up being ugly as night... Hmm,
but maybe we could get rid of this - hold i_mutex to protect against all
writes (that ranks outside of transaction start so you can hold it for the
whole migration time - maybe you even hold it if you are called from the
write path...). After dropping i_data_sem you let some readers proceed
but writers still wait on i_mutex so the file shouldn't change under you
(but I suggest adding some BUG_ONs to verify that the file really doesn't
change :).
How about the patch below. I did the below testing
a) migrate a file
b) run fs_inode fsstres fsx_linux.
The intention was to find out whether the new locking is breaking any of
the other expected hierarchy. It seems to fine. I didn't get any lockdep
warning.
I think there's a problem in the patch. I don't think you can call
free_ind_block() while readers are accessing the file. That could make them
think the file contains holes when they aren't there (or even worse read
freed blocks or so). So you need to lock i_data_sem before this call (that
means you have to move journal_extend() as well). Actually, I don't quite
get why ext4_journal_extend() is called in that function. You can just
count with the 1 credit in ext4_ext_migrate() when you call
ext4_journal_extend() before calling ext4_ext_swap_inode_data(). Oh,
probably because free_ind_block() could extend the transaction (which they
don't do now as far as I can see).
BTW: That freeing code should really take into account that it can modify
bitmaps in different block groups. It's even not that hard to do. Just
before each ext4_free_blocks() in free_ind_block() you check whether you
have still enough credits in the handle (use h_buffer_credits) and if not,
extend it by some amount.
Maybe you could do some test like writing a big file with some data and then
while migration is running read it in a loop and compare that MD5SUM is the
same all the time. Also run some memory-pressure during this test so that
data blocks aren't cached for the whole time of the test... That should
reasonably stress the migration code.
ext4: Fix circular locking dependency with migrate and rm.
From: Aneesh Kumar K.V [EMAIL PROTECTED]
We now take inode-i_mutex lock to prevent any update of the inode i_data
field. Before we switch the inode format we take i_data_sem to prevent
parallel read.
===
[ INFO: possible circular locking dependency detected ]
2.6.24-rc8 #6
---
rm/2401 is trying to acquire lock:
(ei-i_data_sem){}, at: [c01dca58] ext4_get_blocks_wrap+0x21/0x108
but task is already holding lock:
(jbd2_handle){--..}, at: [c01fc4a7] jbd2_journal_start+0xd2/0xff
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
- #1 (jbd2_handle){--..}:
[c0143a5c] __lock_acquire+0xa31/0xc1a
[c0143cbf] lock_acquire+0x7a/0x94
[c01fc4ca] jbd2_journal_start+0xf5/0xff
[c01e3539] ext4_journal_start_sb+0x48/0x4a
[c01eb980] ext4_ext_migrate+0x7d/0x535
[c01df328]
Re: [PATCH] Handle unusual results from find_tempdir.
On Tue, Feb 05, 2008 at 01:13:04PM +0100, Jim Meyering wrote: An alternative: make find_tempdir set tempdir to default_tempdir upon malloc failure. * arch/um/os-Linux/mem.c (make_tempfile): Handle NULL tempdir. Don't let a long tempdir (e.g., via TMPDIR) provoke heap corruption. This wasn't meant for the linux-ext4 list, was it? I think maybe you typo'ed the mailing list this patch was supposed to be sent to? Regards, - Ted - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: jbd2_handle and i_data_sem circular locking dependency detected
On Tue, Feb 05, 2008 at 02:42:28PM +0100, Jan Kara wrote: On Tue 05-02-08 17:53:42, Aneesh Kumar K.V wrote: How about the patch below. I did the below testing a) migrate a file b) run fs_inode fsstres fsx_linux. The intention was to find out whether the new locking is breaking any of the other expected hierarchy. It seems to fine. I didn't get any lockdep warning. I think there's a problem in the patch. I don't think you can call free_ind_block() while readers are accessing the file. That could make them think the file contains holes when they aren't there (or even worse read freed blocks or so). So you need to lock i_data_sem before this call (that means you have to move journal_extend() as well). Actually, I don't quite get why ext4_journal_extend() is called in that function. You can just count with the 1 credit in ext4_ext_migrate() when you call ext4_journal_extend() before calling ext4_ext_swap_inode_data(). Oh, probably because free_ind_block() could extend the transaction (which they don't do now as far as I can see). ext4_journal_extend is called to extend the journal by one credit to take care of writing the block containing inode. I moved the journal extend before taking i_data_sem lock. diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c index f97c993..dc6617a 100644 --- a/fs/ext4/migrate.c +++ b/fs/ext4/migrate.c @@ -302,10 +302,6 @@ static int ext4_ext_swap_inode_data(handle_t *handle, struct inode *inode, struct ext4_inode_info *ei = EXT4_I(inode); struct ext4_inode_info *tmp_ei = EXT4_I(tmp_inode); - retval = free_ind_block(handle, inode); - if (retval) - goto err_out; - /* * One credit accounted for writing the * i_data field of the original inode @@ -318,6 +314,10 @@ static int ext4_ext_swap_inode_data(handle_t *handle, struct inode *inode, } down_write(EXT4_I(inode)-i_data_sem); + retval = free_ind_block(handle, inode); + if (retval) + goto err_out; + /* * We have the extent map build with the tmp inode. * Now copy the i_data across The above change also make sure we don't fail after we free the indirect blocks. BTW: That freeing code should really take into account that it can modify bitmaps in different block groups. It's even not that hard to do. Just before each ext4_free_blocks() in free_ind_block() you check whether you have still enough credits in the handle (use h_buffer_credits) and if not, extend it by some amount. I have a FIXME at migrate.c:524 documenting exactly that. The difficult question was by how much we should extent the journal. ? But in reality we might have accumulated enough journal credits, I never really ran across a case where we are running out of the journal credit. Maybe you could do some test like writing a big file with some data and then while migration is running read it in a loop and compare that MD5SUM is the same all the time. Also run some memory-pressure during this test so that data blocks aren't cached for the whole time of the test... That should reasonably stress the migration code. I have tested migrate by booting with mem= and doing parallel read/write and migrate. I didn't do the MDSUM compare. Will do that this time. Thanks for all the help with review. -aneesh - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: jbd2_handle and i_data_sem circular locking dependency detected
On Tue 05-02-08 21:57:03, Aneesh Kumar K.V wrote: On Tue, Feb 05, 2008 at 02:42:28PM +0100, Jan Kara wrote: On Tue 05-02-08 17:53:42, Aneesh Kumar K.V wrote: How about the patch below. I did the below testing a) migrate a file b) run fs_inode fsstres fsx_linux. The intention was to find out whether the new locking is breaking any of the other expected hierarchy. It seems to fine. I didn't get any lockdep warning. I think there's a problem in the patch. I don't think you can call free_ind_block() while readers are accessing the file. That could make them think the file contains holes when they aren't there (or even worse read freed blocks or so). So you need to lock i_data_sem before this call (that means you have to move journal_extend() as well). Actually, I don't quite get why ext4_journal_extend() is called in that function. You can just count with the 1 credit in ext4_ext_migrate() when you call ext4_journal_extend() before calling ext4_ext_swap_inode_data(). Oh, probably because free_ind_block() could extend the transaction (which they don't do now as far as I can see). ext4_journal_extend is called to extend the journal by one credit to take care of writing the block containing inode. I moved the journal extend before taking i_data_sem lock. diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c index f97c993..dc6617a 100644 --- a/fs/ext4/migrate.c +++ b/fs/ext4/migrate.c @@ -302,10 +302,6 @@ static int ext4_ext_swap_inode_data(handle_t *handle, struct inode *inode, struct ext4_inode_info *ei = EXT4_I(inode); struct ext4_inode_info *tmp_ei = EXT4_I(tmp_inode); - retval = free_ind_block(handle, inode); - if (retval) - goto err_out; - /* * One credit accounted for writing the * i_data field of the original inode @@ -318,6 +314,10 @@ static int ext4_ext_swap_inode_data(handle_t *handle, struct inode *inode, } down_write(EXT4_I(inode)-i_data_sem); + retval = free_ind_block(handle, inode); + if (retval) + goto err_out; + /* * We have the extent map build with the tmp inode. * Now copy the i_data across The above change also make sure we don't fail after we free the indirect blocks. Yeah, now it looks fine. BTW: That freeing code should really take into account that it can modify bitmaps in different block groups. It's even not that hard to do. Just before each ext4_free_blocks() in free_ind_block() you check whether you have still enough credits in the handle (use h_buffer_credits) and if not, extend it by some amount. I have a FIXME at migrate.c:524 documenting exactly that. The difficult question was by how much we should extent the journal. ? But in reality we might have accumulated enough journal credits, I never really ran across a case where we are running out of the journal credit. Yes, I don't think it is likely to happen in reality but if somebody would trigger this, it would be almost impossible to track down so one should be quite careful with these things... And as I described, doing it failsafe is easy - just look how try_to_extend_transaction() in ext4/inode.c handles similar problems with truncate. Honza -- Jan Kara [EMAIL PROTECTED] SUSE Labs, CR - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] jbd: fix assertion failure in journal_next_log_block
Hello, Sorry for replying a bit late but I'm currently falling behind in maling-list reading... The way jbd tries to determine if there is enough space left on the journal in order to start a new transaction is looking at the space left in the journal and the space needed for the committing transaction, which is 1/4 of the journal + the number of t_outstanding_credits for that transaction. In this case its assumed that t_outstanding_credits accurately represents the number of credits Yes. waiting to be written to the journal, but this sometimes isn't the case. The transaction has two counters for buffers, t_outstanding_credits which is used in conjunction with handles that are added to the transaction, and t_nr_buffers which is only incremented/decremented when buffers are added/removed from the transaction and are actually destined to be journaled. Normally these two t_nr_buffers actually represents number of buffers on BJ_Metadata list and nobody uses it (except for the assertion in __journal_temp_unlink_buffer()). t_outstanding_credits is supposed to be *the* counter making sure we don't write more than we have credits for. counters are the same, however there are cases where the committing transaction can have buffers moved to the next running transaction, for example any buffers on the committing transactions t_reserved list would be moved to the next (running) transaction, and if it had been dirtied in the process it would immediately make it onto the t_updates list, which would increment t_nr_buffers You probably mean t_buffers list here... but not t_outstanding_credits. So you get into this situation where But which moving and dirtying do you mean? The caller which dirties the buffer must make sure that he has acquired enough credits for the transaction where the buffer ends up... So if there were not enough buffers in the running transaction where we refiled the buffer it is a bug in the caller which dirties the buffer. t_nr_buffers (the actual number of buffers that are on the transaction) is greater than the number of buffers accounted for via t_outstanding_credits. This presents a problem since as we loop through writting buffers to the journal, we decrement t_outstanding_credits, and if t_nr_buffers is more than t_outstanding_credits then we end up with a negative number for t_outstanding_credits, which means we start saying we need less than 1/4 of the journal for our committing transaction and allow more transactions than we can handle to start, and then bam we fail because journal_next_log_block doesn't have enough free blocks in order to handle the request. This has been tested and fixes the issue (which could not be reproduced by me but several other people could get it to reproduce using postmark), and although I couldn't reproduce the assertion, I could very easily reproduce the situation where t_outstanding_credits was than t_nr_buffers. I suppose you see the assertion J_ASSERT(journal-j_free 1); to fail, right? I don't see how your patch could help avoid that assertion. You've just removed accounting of t_outstanding_credits which has no impact on the real number of free blocks in the journal stored in j_free. Anyway, if you can reproduce t_outstanding_credits t_nr_buffers, then there's something fishy. Are you able to reproduce it also with a current kernel? Thanks for looking into the problem :) Honza -- Jan Kara [EMAIL PROTECTED] SuSE CR Labs - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: jbd2_handle and i_data_sem circular locking dependency detected
On Tue, Feb 05, 2008 at 05:34:04PM +0100, Jan Kara wrote:
On Tue 05-02-08 21:57:03, Aneesh Kumar K.V wrote:
I have a FIXME at migrate.c:524 documenting exactly that. The
difficult question was by how much we should extent the journal. ? But
in reality we might have accumulated enough journal credits, I never
really ran across a case where we are running out of the journal credit.
Yes, I don't think it is likely to happen in reality but if somebody
would trigger this, it would be almost impossible to track down so one
should be quite careful with these things...
And as I described, doing it failsafe is easy - just look how
try_to_extend_transaction() in ext4/inode.c handles similar problems with
truncate.
I moved the indirect block freeing after i update the original inode.
That makes sure even if we fail to free the indirect blocks we have the
original inode converted. Now since i don't need atomicity with freeing of
blocks i extend the journal for each block freed. Below is the diff i have
right now.
diff --git a/fs/ext4/migrate.c b/fs/ext4/migrate.c
index 1712844..1b00587 100644
--- a/fs/ext4/migrate.c
+++ b/fs/ext4/migrate.c
@@ -233,11 +233,14 @@ static int free_dind_blocks(handle_t *handle,
tmp_idata = (__le32 *)bh-b_data;
for (i = 0; i max_entries; i++) {
- if (tmp_idata[i])
+ if (tmp_idata[i]) {
+ extend_blkdelete_credit(handle, inode);
ext4_free_blocks(handle, inode,
le32_to_cpu(tmp_idata[i]), 1, 1);
+ }
}
put_bh(bh);
+ extend_blkdelete_credit(handle, inode);
ext4_free_blocks(handle, inode, le32_to_cpu(i_data), 1, 1);
return 0;
}
@@ -266,29 +269,32 @@ static int free_tind_blocks(handle_t *handle,
}
}
put_bh(bh);
+ extend_blkdelete_credit(handle, inode);
ext4_free_blocks(handle, inode, le32_to_cpu(i_data), 1, 1);
return 0;
}
-static int free_ind_block(handle_t *handle, struct inode *inode)
+static int free_ind_block(handle_t *handle, __le32 *i_data)
{
int retval;
- struct ext4_inode_info *ei = EXT4_I(inode);
- if (ei-i_data[EXT4_IND_BLOCK])
+ /* ei-i_data[EXT4_IND_BLOCK] */
+ if (i_data[0]) {
+ extend_blkdelete_credit(handle, inode);
ext4_free_blocks(handle, inode,
- le32_to_cpu(ei-i_data[EXT4_IND_BLOCK]), 1, 1);
+ le32_to_cpu(i_data[0]), 1, 1);
+ }
- if (ei-i_data[EXT4_DIND_BLOCK]) {
- retval = free_dind_blocks(handle, inode,
- ei-i_data[EXT4_DIND_BLOCK]);
+ /* ei-i_data[EXT4_DIND_BLOCK] */
+ if (i_data[1]) {
+ retval = free_dind_blocks(handle, inode, i_data[1]);
if (retval)
return retval;
}
- if (ei-i_data[EXT4_TIND_BLOCK]) {
- retval = free_tind_blocks(handle, inode,
- ei-i_data[EXT4_TIND_BLOCK]);
+ /* ei-i_data[EXT4_TIND_BLOCK] */
+ if (i_data[2]) {
+ retval = free_tind_blocks(handle, inode, i_data[2]);
if (retval)
return retval;
}
@@ -299,6 +305,7 @@ static int ext4_ext_swap_inode_data(handle_t *handle,
struct inode *inode,
struct inode *tmp_inode)
{
int retval;
+ __le32 i_data[3];
struct ext4_inode_info *ei = EXT4_I(inode);
struct ext4_inode_info *tmp_ei = EXT4_I(tmp_inode);
@@ -313,11 +320,11 @@ static int ext4_ext_swap_inode_data(handle_t *handle,
struct inode *inode,
goto err_out;
}
- down_write(EXT4_I(inode)-i_data_sem);
- retval = free_ind_block(handle, inode);
- if (retval)
- goto err_out;
+ i_data[0] = ei-i_data[EXT4_IND_BLOCK];
+ i_data[1] = ei-i_data[EXT4_DIND_BLOCK];
+ i_data[2] = ei-i_data[EXT4_TIND_BLOCK];
+ down_write(EXT4_I(inode)-i_data_sem);
/*
* We have the extent map build with the tmp inode.
* Now copy the i_data across
@@ -338,8 +345,12 @@ static int ext4_ext_swap_inode_data(handle_t *handle,
struct inode *inode,
inode-i_blocks += tmp_inode-i_blocks;
spin_unlock(inode-i_lock);
up_write(EXT4_I(inode)-i_data_sem);
-
ext4_mark_inode_dirty(handle, inode);
+
+ /* Now free the indirec block of the inode */
+ retval = free_ind_block(handle, i_data);
+ if (retval)
+ goto err_out;
err_out:
return retval;
}
@@ -367,6 +378,7 @@ static int free_ext_idx(handle_t *handle, struct inode
*inode,
}
}
put_bh(bh);
+ extend_blkdelete_credit(handle, inode);
ext4_free_blocks(handle, inode, block, 1, 1);
return
Re: - disable-ext4.patch removed from -mm tree
On Mon, 2008-02-04 at 10:00 -0500, Theodore Tso wrote: On Sun, Feb 03, 2008 at 07:15:40PM -0800, Andrew Morton wrote: On Sun, 3 Feb 2008 20:36:26 -0500 Theodore Tso [EMAIL PROTECTED] wrote: On Sun, Feb 03, 2008 at 12:25:51PM -0800, Andrew Morton wrote: When I merge David's iget coversion patches this will instead wreck the ext4 patchset. That's ok, it shouldn't be hard for me to fix this up. How quickly will you be able to merge David's iget converstion patches? They're about 1,000 patches back. OK, if you're not planning on pushing David's changes to Linus right away, what if I pull in David's iget-stop-ext4-from-using-iget-and-read_inode-try.patch and push it plus some other ext4 bug fixes directly to Linus, and let you know when that has happened so you can drop David's patch from your queue? David's changes to ext4 can be applied standalone without the rest of his series, so it would be safe to push that to Linus independently and in advance of the rest of his series. I get compile error when builing ext4 patch queue with iget-stop-ext4-from-using-iget-and-read_inode-try.patch applied, against 2.6.24-git14. It seems iget-stop-ext4-from-using-iget-and-read_inode-try.patch depends on patches: [PATCH 01/31] Add an ERR_CAST() macro to complement ERR_PTR and co. [PATCH 03/32] IGET: Introduce a function to register iget failure Mingming That should also help reduce the number of inter-patch queue dependencies. Regards, - Ted - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
- pagecache-zeroing-zero_user_segment-zero_user_segments-and-zero_user.patch removed from -mm tree
The patch titled
Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user
has been removed from the -mm tree. Its filename was
pagecache-zeroing-zero_user_segment-zero_user_segments-and-zero_user.patch
This patch was dropped because it was merged into mainline or a subsystem tree
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
--
Subject: Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user
From: Christoph Lameter [EMAIL PROTECTED]
Simplify page cache zeroing of segments of pages through 3 functions
zero_user_segments(page, start1, end1, start2, end2)
Zeros two segments of the page. It takes the position where to
start and end the zeroing which avoids length calculations and
makes code clearer.
zero_user_segment(page, start, end)
Same for a single segment.
zero_user(page, start, length)
Length variant for the case where we know the length.
We remove the zero_user_page macro. Issues:
1. Its a macro. Inline functions are preferable.
2. The KM_USER0 macro is only defined for HIGHMEM.
Having to treat this special case everywhere makes the
code needlessly complex. The parameter for zeroing is always
KM_USER0 except in one single case that we open code.
Avoiding KM_USER0 makes a lot of code not having to be dealing
with the special casing for HIGHMEM anymore. Dealing with
kmap is only necessary for HIGHMEM configurations. In those
configurations we use KM_USER0 like we do for a series of other
functions defined in highmem.h.
Since KM_USER0 is depends on HIGHMEM the existing zero_user_page
function could not be a macro. zero_user_* functions introduced
here can be be inline because that constant is not used when these
functions are called.
Also extract the flushing of the caches to be outside of the kmap.
[EMAIL PROTECTED]: fix nfs and ntfs build]
[EMAIL PROTECTED]: fix ntfs build some more]
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Cc: Steven French [EMAIL PROTECTED]
Cc: Michael Halcrow [EMAIL PROTECTED]
Cc: linux-ext4@vger.kernel.org
Cc: Steven Whitehouse [EMAIL PROTECTED]
Cc: Trond Myklebust [EMAIL PROTECTED]
Cc: J. Bruce Fields [EMAIL PROTECTED]
Cc: Anton Altaparmakov [EMAIL PROTECTED]
Cc: Mark Fasheh [EMAIL PROTECTED]
Cc: David Chinner [EMAIL PROTECTED]
Cc: Michael Halcrow [EMAIL PROTECTED]
Cc: Steven French [EMAIL PROTECTED]
Cc: Steven Whitehouse [EMAIL PROTECTED]
Cc: Trond Myklebust [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
fs/buffer.c| 44 ++--
fs/cifs/inode.c|2 -
fs/direct-io.c |4 +-
fs/ecryptfs/mmap.c |5 +--
fs/ext3/inode.c|4 +-
fs/ext4/inode.c|4 +-
fs/gfs2/bmap.c |2 -
fs/gfs2/ops_address.c |2 -
fs/libfs.c | 11 ++--
fs/mpage.c |7 +
fs/nfs/read.c | 10 +++
fs/nfs/write.c |4 --
fs/ntfs/aops.c | 20 --
fs/ntfs/compress.c |2 -
fs/ntfs/file.c | 32 ++-
fs/ocfs2/alloc.c |2 -
fs/ocfs2/aops.c|6 ++--
fs/reiserfs/inode.c|4 +-
fs/xfs/linux-2.6/xfs_lrw.c |2 -
include/linux/highmem.h| 48 +--
mm/filemap_xip.c |2 -
mm/truncate.c |2 -
22 files changed, 103 insertions(+), 116 deletions(-)
diff -puN
fs/buffer.c~pagecache-zeroing-zero_user_segment-zero_user_segments-and-zero_user
fs/buffer.c
---
a/fs/buffer.c~pagecache-zeroing-zero_user_segment-zero_user_segments-and-zero_user
+++ a/fs/buffer.c
@@ -1798,7 +1798,7 @@ void page_zero_new_buffers(struct page *
start = max(from, block_start);
size = min(to, block_end) - start;
- zero_user_page(page, start, size,
KM_USER0);
+ zero_user(page, start, size);
set_buffer_uptodate(bh);
}
@@ -1861,19 +1861,10 @@ static int __block_prepare_write(struct
mark_buffer_dirty(bh);
continue;
}
- if (block_end to || block_start from) {
- void *kaddr;
-
- kaddr = kmap_atomic(page, KM_USER0);
- if (block_end to)
- memset(kaddr+to, 0,
- block_end-to);
- if (block_start from)
-
Re: Replace iget with iget_locked in defrag-free-space-fragementation
On Sat, 2008-02-02 at 11:40 -0500, Theodore Ts'o wrote:
FYI, since iget() is going to be disappearing in 2.6.25, and akpm has
disabled ext4 in the -mm tree as a result, I'm folding the following
patch into the defrag-free-space-fragmentation.patch in the ext4 tree.
I noticed that you have merged the changes in the patch queue...
diff --git a/fs/ext4/defrag.c b/fs/ext4/defrag.c
index d9a14e4..6370fb8 100644
--- a/fs/ext4/defrag.c
+++ b/fs/ext4/defrag.c
@@ -287,9 +287,13 @@ static int ext4_ext_extents_info(struct
ext4_extents_info *ext_info,
int entries = 0;
int err = 0;
- inode = iget(sb, ext_info-ino);
+ inode = iget_locked(sb, ext_info-ino);
if (!inode)
return -EACCES;
+ if (inode-i_state I_NEW) {
+ sb-s_op-read_inode(inode);
+ unlock_new_inode(inode);
+ }
down_write(EXT4_I(inode)-i_data_sem);
read_inode() also sunset, as removed in
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24/2.6.24-mm1/broken-out/iget-remove-iget-and-the-read_inode-super-op-as.patch
so above changes won't compile in mm tree.
I have fixed it in patch queue, using ext4_iget() to replace iget() and
read-inode() as suggested in
iget-stop-ext4-from-using-iget-and-read_inode-try.patch
http://repo.or.cz/w/ext4-patch-queue.git?a=blob;f=ext4-online-defrag-iget-read-inode-fix.patch;h=94660ca7371680fcd02bb5804016b4cae4f20846;hb=85589744f9d53579a12aa463ccd42fb450aec786
We also have an issue where the read-only bind patches from Dave Hansen
are making changes which conflict with the ext4 patch tree, which is
making akpm very grumpy. I'll try to take a look at this later in the
weekend...
- Ted
@@ -588,9 +592,13 @@ static int ext4_ext_defrag_victim(struct file
*target_filp,
ext.len = 0;
/* Get the inode of the victim file */
- victim_inode = iget(sb, ex_info-ino);
+ victim_inode = iget_locked(sb, ex_info-ino);
if (!victim_inode)
return -EACCES;
+ if (victim_inode-i_state I_NEW) {
+ sb-s_op-read_inode(victim_inode);
+ unlock_new_inode(victim_inode);
+ }
/* Setup file for the victim file */
victim_dent.d_inode = victim_inode;
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace iget with iget_locked in defrag-free-space-fragementation
On Sat, 2008-02-02 at 11:40 -0500, Theodore Ts'o wrote: We also have an issue where the read-only bind patches from Dave Hansen are making changes which conflict with the ext4 patch tree, which is making akpm very grumpy. I'll try to take a look at this later in the weekend... - Ted BTW, Ted, could you clarify about this one? I am able to build the patch queue on akpm's 2.6.24-mm1 tree with Dave Hansen's read-only bind changes. Maybe I missed something. Mingming - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: - disable-ext4.patch removed from -mm tree
On Tue, 2008-02-05 at 13:26 -0800, Mingming Cao wrote: On Mon, 2008-02-04 at 10:00 -0500, Theodore Tso wrote: On Sun, Feb 03, 2008 at 07:15:40PM -0800, Andrew Morton wrote: On Sun, 3 Feb 2008 20:36:26 -0500 Theodore Tso [EMAIL PROTECTED] wrote: On Sun, Feb 03, 2008 at 12:25:51PM -0800, Andrew Morton wrote: When I merge David's iget coversion patches this will instead wreck the ext4 patchset. That's ok, it shouldn't be hard for me to fix this up. How quickly will you be able to merge David's iget converstion patches? They're about 1,000 patches back. OK, if you're not planning on pushing David's changes to Linus right away, what if I pull in David's iget-stop-ext4-from-using-iget-and-read_inode-try.patch and push it plus some other ext4 bug fixes directly to Linus, and let you know when that has happened so you can drop David's patch from your queue? David's changes to ext4 can be applied standalone without the rest of his series, so it would be safe to push that to Linus independently and in advance of the rest of his series. I get compile error when builing ext4 patch queue with iget-stop-ext4-from-using-iget-and-read_inode-try.patch applied, against 2.6.24-git14. It seems iget-stop-ext4-from-using-iget-and-read_inode-try.patch depends on patches: [PATCH 01/31] Add an ERR_CAST() macro to complement ERR_PTR and co. [PATCH 03/32] IGET: Introduce a function to register iget failure It seems to me the easiest way to bring ext4 patches back to mm tree, is to carry above two patches in ext4 patch queue, like we did for other ext4 patches that depend on generic code in the past. So I added above two patches to ext4 patch queue, now that ext4 patches could apply cleanly to linus git tree, and Andrew should able to easily pull ext4 patches after removing the duplicated patches. Ted, I have the ext4 patch queue updated for this. Regards, Mingming - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: - disable-ext4.patch removed from -mm tree
On Tue, 05 Feb 2008 17:02:20 -0800 Mingming Cao [EMAIL PROTECTED] wrote: On Tue, 2008-02-05 at 13:26 -0800, Mingming Cao wrote: On Mon, 2008-02-04 at 10:00 -0500, Theodore Tso wrote: On Sun, Feb 03, 2008 at 07:15:40PM -0800, Andrew Morton wrote: On Sun, 3 Feb 2008 20:36:26 -0500 Theodore Tso [EMAIL PROTECTED] wrote: On Sun, Feb 03, 2008 at 12:25:51PM -0800, Andrew Morton wrote: When I merge David's iget coversion patches this will instead wreck the ext4 patchset. That's ok, it shouldn't be hard for me to fix this up. How quickly will you be able to merge David's iget converstion patches? They're about 1,000 patches back. OK, if you're not planning on pushing David's changes to Linus right away, what if I pull in David's iget-stop-ext4-from-using-iget-and-read_inode-try.patch and push it plus some other ext4 bug fixes directly to Linus, and let you know when that has happened so you can drop David's patch from your queue? David's changes to ext4 can be applied standalone without the rest of his series, so it would be safe to push that to Linus independently and in advance of the rest of his series. I get compile error when builing ext4 patch queue with iget-stop-ext4-from-using-iget-and-read_inode-try.patch applied, against 2.6.24-git14. It seems iget-stop-ext4-from-using-iget-and-read_inode-try.patch depends on patches: [PATCH 01/31] Add an ERR_CAST() macro to complement ERR_PTR and co. [PATCH 03/32] IGET: Introduce a function to register iget failure It seems to me the easiest way to bring ext4 patches back to mm tree, is to carry above two patches in ext4 patch queue, like we did for other ext4 patches that depend on generic code in the past. It doesn't matter a lot because I won't be doing another -mm until all this is merged up anyway. So I added above two patches to ext4 patch queue, now that ext4 patches could apply cleanly to linus git tree, and Andrew should able to easily pull ext4 patches after removing the duplicated patches. Ted, I have the ext4 patch queue updated for this. This means that I merge part of the iget patch series, then twiddle thumbs until the ext4 tree merges, then merge the remainder of the iget series. So unless Ted intends to merge RSN I think it'd be preferable if I were to just merge the lot, sorry. - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Replace iget with iget_locked in defrag-free-space-fragementation
On Tue, Feb 05, 2008 at 04:55:52PM -0800, Mingming Cao wrote: On Sat, 2008-02-02 at 11:40 -0500, Theodore Ts'o wrote: We also have an issue where the read-only bind patches from Dave Hansen are making changes which conflict with the ext4 patch tree, which is making akpm very grumpy. I'll try to take a look at this later in the weekend... - Ted BTW, Ted, could you clarify about this one? I am able to build the patch queue on akpm's 2.6.24-mm1 tree with Dave Hansen's read-only bind changes. Maybe I missed something. That's because I've already removed the BKL patches that conflict. - Ted - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
- ext3-fix-lock-inversion-in-direct-io-fix.patch removed from -mm tree
The patch titled
ext3-fix-lock-inversion-in-direct-io-fix
has been removed from the -mm tree. Its filename was
ext3-fix-lock-inversion-in-direct-io-fix.patch
This patch was dropped because it was folded into
ext3-fix-lock-inversion-in-direct-io.patch
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
--
Subject: ext3-fix-lock-inversion-in-direct-io-fix
From: Andrew Morton [EMAIL PROTECTED]
fs/ext3/inode.c: In function 'ext3_get_block':
fs/ext3/inode.c:964: error: 'sb' undeclared (first use in this function)
fs/ext3/inode.c:964: error: (Each undeclared identifier is reported only once
fs/ext3/inode.c:964: error: for each function it appears in.)
Cc: linux-ext4@vger.kernel.org
Cc: Badari Pulavarty [EMAIL PROTECTED]
Cc: Jan Kara [EMAIL PROTECTED]
Cc: Zach Brown [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
fs/ext3/inode.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/ext3/inode.c~ext3-fix-lock-inversion-in-direct-io-fix
fs/ext3/inode.c
--- a/fs/ext3/inode.c~ext3-fix-lock-inversion-in-direct-io-fix
+++ a/fs/ext3/inode.c
@@ -961,7 +961,7 @@ static int ext3_get_block(struct inode *
if (max_blocks DIO_MAX_BLOCKS)
max_blocks = DIO_MAX_BLOCKS;
handle = ext3_journal_start(inode, DIO_CREDITS +
- 2 * EXT3_QUOTA_TRANS_BLOCKS(sb));
+ 2 * EXT3_QUOTA_TRANS_BLOCKS(inode-i_sb));
if (IS_ERR(handle)) {
ret = PTR_ERR(handle);
goto out;
_
Patches currently in -mm which might be from [EMAIL PROTECTED] are
origin.patch
kernel-printkc-concerns-about-the-console-handover.patch
riscom8-fix-smp-brokenness.patch
sound-oss-pss-set_io_base-always-returns-success-mark-it-void.patch
genericizing-iova-fix.patch
parallel-port-convert-port_mutex-to-the-mutex-api.patch
remove-support-for-un-needed-_extratext-section.patch
allow-auto-destruction-of-loop-devices.patch
read_current_time-cleanups.patch
address-hfs-on-disk-corruption-robustness-review-comments.patch
get-rid-of-nr_open-and-introduce-a-sysctl_nr_open.patch
kallsyms-should-prefer-non-weak-symbols.patch
quota-improve-inode-list-scanning-in-add_dquot_ref.patch
tty-enable-the-echoing-of-c-in-the-n_tty-discipline.patch
stopmachine-semaphore-to-mutex.patch
parport-add-support-for-the-quatech-sppxp-100-parallel-port-pci-expresscard.patch
debug_smp_processor_id-fixlets.patch
use-ilog2-in-fs-namespacec.patch
system-timer-fix-crash-in-100hz-system-timer.patch
speed-up-jiffies-conversion-functions-if-hz==user_hz.patch
drivers-isdn-hardware-eicon-debugc-fix-uninitialized-var-warning.patch
ecryptfs-make-show_options-reflect-actual-mount-options.patch
rtc-ds1302-rtc-support.patch
add-hpet-rtc-emulation-to-rtc_drv_cmos.patch
fbmon-cleanup-trailing-whitespaces.patch
neofb-avoid-overwriting-fb_info-fields.patch
vermilionc-use-align-not-__align_mask.patch
declare-pnp-option-parsing-functions-as-__init.patch
isapnp-driver-semaphore-to-mutex.patch
ext3-fix-lock-inversion-in-direct-io.patch
ext3-fix-lock-inversion-in-direct-io-fix.patch
kill-filp_open-checkpatch-fixes.patch
rename-open_namei-to-open_pathname-fix.patch
r-o-bind-mounts-elevate-write-count-during-entire-ncp_ioctl-fix.patch
r-o-bind-mounts-elevate-write-count-for-do_utimes.patch
r-o-bind-mounts-elevate-write-count-for-some-ioctls-checkpatch-fixes.patch
r-o-bind-mounts-elevate-write-count-for-some-ioctls-vs-forbid-user-to-change-file-flags-on-quota-files.patch
r-o-bind-mounts-elevate-write-count-opened-files-oops-fix.patch
r-o-bind-mounts-nfs-check-mnt-instead-of-superblock-directly-checkpatch-fixes.patch
r-o-bind-mounts-track-number-of-mount-writer-fix-buggy-loop-checkpatch-fixes.patch
keep-track-of-mnt_writer-state-of-struct-file-fix-warn_on-fix.patch
cgroup-simplify-space-stripping-fix.patch
memory-controller-memory-accounting-v7.patch
memory-controller-add-per-container-lru-and-reclaim-v7.patch
memory-controller-oom-handling-v7.patch
memory-controller-add-switch-to-control-what-type-of-pages-to-limit-v7.patch
memcontrol-move-mm_cgroup-to-header-file-fix.patch
memcontrol-move-mm_cgroup-to-header-file-fix-2.patch
memcontrol-move-oom-task-exclusion-to-tasklist.patch
memory-cgroup-enhancements-fix-zone-handling-in-try_to_free_mem_cgroup_page.patch
memory-cgroup-enhancements-add-status-accounting-function-for-memory-cgroup.patch
memory-cgroup-enhancements-add-memorystat-file.patch
per-zone-and-reclaim-enhancements-for-memory-controller-take-3-remember-reclaim-priority-in-memory-cgroup.patch
per-zone-and-reclaim-enhancements-for-memory-controller-take-3-modifies-vmscanc-for-isolate-globa-cgroup-lru-activity.patch
cgroups-mechanism-to-process-each-task-in-a-cgroup-cleanup.patch
cgroups-mechanism-to-process-each-task-in-a-cgroup-checkpatch-fixes.patch
