On Fri, 2007-07-13 at 02:05 -0700, Andrew Morton wrote:
On Tue, 10 Jul 2007 16:32:47 -0700 Andrew Morton [EMAIL PROTECTED] wrote:
+ brelse(bh);
+ up_write(EXT4_I(inode)-xattr_sem);
+ return error;
+}
+
We're doing GFP_KERNEL memory allocations while holding xattr_sem. This
On Jul 16, 2007 16:52 -0700, Mingming Cao wrote:
I am not sure why we need GFP_KERNEL flag here. I think we should use
GFP_NOFS instead. The following patch use the GFP_NOFS flag, as well as
fixing memory leak issue introduced by the ext4 expand inode extra isize
patch.
Fixing memory
On Mon, 2007-07-16 at 18:06 -0600, Andreas Dilger wrote:
On Jul 16, 2007 16:52 -0700, Mingming Cao wrote:
I am not sure why we need GFP_KERNEL flag here. I think we should use
GFP_NOFS instead. The following patch use the GFP_NOFS flag, as well as
fixing memory leak issue introduced by the
On Fri, 2007-07-13 at 14:47 -0700, Zach Brown wrote:
Peter, do you have any interest in seeing how far we can get
at tracking lock_page()? I'm not holding my breath, but any little bit
would probably help.
I ran headfirst into the fact the unlock_page() need not be called by
the same task
On Fri, 2007-07-13 at 14:47 -0700, Zach Brown wrote:
Peter, do you have any interest in seeing how far we can get
at tracking lock_page()? I'm not holding my breath, but any little bit
would probably help.
Would this be a valid report?
( /me goes hunt a x86_64 unwinder patch that will
On Sun, 2007-07-15 at 15:02 +0200, Peter Zijlstra wrote:
On Fri, 2007-07-13 at 14:47 -0700, Zach Brown wrote:
Peter, do you have any interest in seeing how far we can get
at tracking lock_page()? I'm not holding my breath, but any little bit
would probably help.
Would this be a valid
On Sun, 2007-07-15 at 11:11 -0700, Andrew Morton wrote:
On Sun, 15 Jul 2007 15:02:23 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Fri, 2007-07-13 at 14:47 -0700, Zach Brown wrote:
Peter, do you have any interest in seeing how far we can get
at tracking lock_page()? I'm not
On Sun, 15 Jul 2007 21:21:03 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
Shows the current stacktrace where we violate the previously established
locking order.
yup, but the lock_page() which we did inside truncate_mutex was a
lock_page() against a different address_space: the blockdev
On Sun, 2007-07-15 at 12:59 -0700, Andrew Morton wrote:
On Sun, 15 Jul 2007 21:21:03 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
Shows the current stacktrace where we violate the previously established
locking order.
yup, but the lock_page() which we did inside truncate_mutex was a
On Fri, 2007-07-13 at 14:47 -0700, Zach Brown wrote:
I fear the consequences of this change :(
I love it. In the past I've lost time by working with patches which
didn't quite realize that ext3 holds a transaction open during
-direct_IO.
Oh well, please keep it alive, maybe beat on it
On Fri, 2007-07-13 at 02:05 -0700, Andrew Morton wrote:
Except lockdep doesn't know about journal_start(), which has ranking
requirements similar to a semaphore.
Something like so?
Or can journal_stop() be done by a different task than the one that did
journal_start()? - in which case
On Tue, 10 Jul 2007 16:32:47 -0700 Andrew Morton [EMAIL PROTECTED] wrote:
+ brelse(bh);
+ up_write(EXT4_I(inode)-xattr_sem);
+ return error;
+}
+
We're doing GFP_KERNEL memory allocations while holding xattr_sem. This
can cause the VM to reenter the filesystem, perhaps taking
On Jul 13, 2007 15:33 +0200, Peter Zijlstra wrote:
On Fri, 2007-07-13 at 02:05 -0700, Andrew Morton wrote:
Or can journal_stop() be done by a different task than the one that did
journal_start()? - in which case nothing much can be done :-/
The call to journal_stop() has to be in the same
On Fri, 13 Jul 2007 15:33:41 +0200
Peter Zijlstra [EMAIL PROTECTED] wrote:
On Fri, 2007-07-13 at 02:05 -0700, Andrew Morton wrote:
Except lockdep doesn't know about journal_start(), which has ranking
requirements similar to a semaphore.
Something like so?
Looks OK.
Or can
I fear the consequences of this change :(
I love it. In the past I've lost time by working with patches which
didn't quite realize that ext3 holds a transaction open during
-direct_IO.
Oh well, please keep it alive, maybe beat on it a bit, resend it
later on?
I can test the patch to make
On Jul 13, 2007 02:05 -0700, Andrew Morton wrote:
On Tue, 10 Jul 2007 16:32:47 -0700 Andrew Morton [EMAIL PROTECTED] wrote:
+ brelse(bh);
+ up_write(EXT4_I(inode)-xattr_sem);
+ return error;
+}
+
We're doing GFP_KERNEL memory allocations while holding xattr_sem. This
can
On Tue, 2007-07-10 at 16:32 -0700, Andrew Morton wrote:
On Sun, 01 Jul 2007 03:38:01 -0400
Mingming Cao [EMAIL PROTECTED] wrote:
This patch is on top of the nanosecond timestamp and i_version_hi
patches.
This sort of information isn't needed (or desired) when this patch hits the
git
On Jul 10, 2007 16:32 -0700, Andrew Morton wrote:
err = ext4_reserve_inode_write(handle, inode, iloc);
+ if (EXT4_I(inode)-i_extra_isize
+ EXT4_SB(inode-i_sb)-s_want_extra_isize
+ !(EXT4_I(inode)-i_state EXT4_STATE_NO_EXPAND)) {
+ /* We need extra buffer
On Wed, 11 Jul 2007 06:10:56 -0600 Andreas Dilger [EMAIL PROTECTED] wrote:
On Jul 10, 2007 16:32 -0700, Andrew Morton wrote:
err = ext4_reserve_inode_write(handle, inode, iloc);
+ if (EXT4_I(inode)-i_extra_isize
+ EXT4_SB(inode-i_sb)-s_want_extra_isize
+
On Wed, 2007-07-11 at 10:34 -0700, Andrew Morton wrote:
On Wed, 11 Jul 2007 06:10:56 -0600 Andreas Dilger [EMAIL PROTECTED] wrote:
On Jul 10, 2007 16:32 -0700, Andrew Morton wrote:
err = ext4_reserve_inode_write(handle, inode, iloc);
+ if (EXT4_I(inode)-i_extra_isize
On Sun, 01 Jul 2007 03:38:01 -0400
Mingming Cao [EMAIL PROTECTED] wrote:
This patch is on top of the nanosecond timestamp and i_version_hi
patches.
This sort of information isn't needed (or desired) when this patch hits the
git tree. Please ensure that things like this are cleaned up before
This patch is on top of the nanosecond timestamp and i_version_hi
patches.
We need to make sure that existing filesystems can also avail the new
fields that have been added to the inode. We use s_want_extra_isize and
s_min_extra_isize to decide by how much we should expand the inode. If
22 matches
Mail list logo