Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+Re\:\s+another\s+problem\s+with\s+latest\s+code\s+drops\s*$/: 27 ]

Total 27 documents matching your query.

1. [PATCH] Re: another problem with latest code drops (score: 1)
Author: >
Date: Fri, 17 Oct 2008 13:04:34 +1100
..... Patch below that replaces xfs_idestroy() with IRELE() to destroy the inode via the normal iput() path. It also fixes a second issue that I found by inspection related to security contexts as a
/archives/xfs/2008-10/msg00331.html (12,584 bytes)

2. Re: [PATCH] Re: another problem with latest code drops (score: 1)
Author: >
Date: Fri, 17 Oct 2008 13:07:18 +1100
And now with the patch. -- Dave Chinner david@xxxxxxxxxxxxx XFS: Ensure that we destroy the linux inode after initialisation Now that XFS initialises the struct inode prior to completing all checks a
/archives/xfs/2008-10/msg00332.html (16,279 bytes)

3. Re: [PATCH] Re: another problem with latest code drops (score: 1)
Author: >
Date: Fri, 17 Oct 2008 13:14:52 +1000
Dave Chinner wrote: On Fri, Oct 17, 2008 at 12:21:41PM +1100, Dave Chinner wrote: On Fri, Oct 17, 2008 at 11:17:46AM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: I am seeing a lot of memory used
/archives/xfs/2008-10/msg00333.html (12,303 bytes)

4. Re: [PATCH] Re: another problem with latest code drops (score: 1)
Author: >
Date: Mon, 20 Oct 2008 12:37:13 +1000
Dave Chinner wrote: On Fri, Oct 17, 2008 at 01:04:34PM +1100, Dave Chinner wrote: On Fri, Oct 17, 2008 at 12:21:41PM +1100, Dave Chinner wrote: On Fri, Oct 17, 2008 at 11:17:46AM +1000, Lachlan McIlr
/archives/xfs/2008-10/msg00374.html (18,658 bytes)

5. Re: [PATCH] Re: another problem with latest code drops (score: 1)
Author: >
Date: Mon, 20 Oct 2008 14:17:57 +1100
I didn't fix xfs_iread() properly - it still calls xfs_idestroy() directly rather than dropping reference counts. Updated patch below that should fix this. I don't think there is an iput() in that pa
/archives/xfs/2008-10/msg00378.html (20,383 bytes)

6. Re: [PATCH] Re: another problem with latest code drops (score: 1)
Author: >
Date: Mon, 20 Oct 2008 14:37:42 +1000
Dave Chinner wrote: On Mon, Oct 20, 2008 at 12:37:13PM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: On Fri, Oct 17, 2008 at 01:04:34PM +1100, Dave Chinner wrote: On Fri, Oct 17, 2008 at 12:21:41
/archives/xfs/2008-10/msg00379.html (16,114 bytes)

7. Re: [PATCH] Re: another problem with latest code drops (score: 1)
Author: >
Date: Mon, 20 Oct 2008 16:29:29 +1100
Ok, that makes more sense. Yeah, xfs_setup_inode() is what is doing: inode->i_state = I_NEW|I_LOCK; which happens after the cache miss has been processed. Ok, so the initialisation code needs to clea
/archives/xfs/2008-10/msg00380.html (18,423 bytes)

8. Re: [PATCH] Re: another problem with latest code drops (score: 1)
Author: >
Date: Mon, 20 Oct 2008 17:05:22 +1100
On second thoughts, the inode has not been set up properly by this stage, so we can't really even expect to be able to call iput() on it. Hmmmm - maybe the only thing we can do here is call security_
/archives/xfs/2008-10/msg00382.html (12,946 bytes)

9. s: Re: linux-next: Tree for October 17) (score: 1)
Author: >
Date: Mon, 20 Oct 2008 17:41:33 -0400
Calling destroy_inode after exporting it seems most logical. If we want to undo init_inode_once we should have VFS functionality taking care of that, too. I've implemented this including some prepara
/archives/xfs/2008-10/msg00409.html (10,467 bytes)

10. e (score: 1)
Author: <david@xxxxxxxxxxxxx>
Date: Fri, 17 Oct 2008 13:04:34 +1100
..... Patch below that replaces xfs_idestroy() with IRELE() to destroy the inode via the normal iput() path. It also fixes a second issue that I found by inspection related to security contexts as a
/archives/xfs/2008-10/msg01152.html (12,405 bytes)

11. itecture (score: 1)
Author: <david@xxxxxxxxxxxxx>
Date: Fri, 17 Oct 2008 13:07:18 +1100
And now with the patch. -- Dave Chinner david@xxxxxxxxxxxxx XFS: Ensure that we destroy the linux inode after initialisation Now that XFS initialises the struct inode prior to completing all checks a
/archives/xfs/2008-10/msg01153.html (16,100 bytes)

12. [PATCH] XFS fix remount rw with unrecognized options (score: 1)
Author: <david@xxxxxxxxxxxxx>
Date: Fri, 17 Oct 2008 13:14:52 +1000
Dave Chinner wrote: On Fri, Oct 17, 2008 at 12:21:41PM +1100, Dave Chinner wrote: On Fri, Oct 17, 2008 at 11:17:46AM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: I am seeing a lot of memory used
/archives/xfs/2008-10/msg01154.html (12,120 bytes)

13. esystem is read-only (score: 1)
Author: th <rozi@xxxxxxxxxxx>
Date: Mon, 20 Oct 2008 12:37:13 +1000
Dave Chinner wrote: On Fri, Oct 17, 2008 at 01:04:34PM +1100, Dave Chinner wrote: On Fri, Oct 17, 2008 at 12:21:41PM +1100, Dave Chinner wrote: On Fri, Oct 17, 2008 at 11:17:46AM +1000, Lachlan McIlr
/archives/xfs/2008-10/msg01195.html (18,475 bytes)

14. tem corruption on the arm(el) architecture (score: 1)
Author: <sandeen@xxxxxxxxxxx>
Date: Mon, 20 Oct 2008 14:17:57 +1100
I didn't fix xfs_iread() properly - it still calls xfs_idestroy() directly rather than dropping reference counts. Updated patch below that should fix this. I don't think there is an iput() in that pa
/archives/xfs/2008-10/msg01199.html (20,204 bytes)

15. system corruption on the arm(el) architecture (score: 1)
Author: <david@xxxxxxxxxxxxx>
Date: Mon, 20 Oct 2008 14:37:42 +1000
Dave Chinner wrote: On Mon, Oct 20, 2008 at 12:37:13PM +1000, Lachlan McIlroy wrote: Dave Chinner wrote: On Fri, Oct 17, 2008 at 01:04:34PM +1100, Dave Chinner wrote: On Fri, Oct 17, 2008 at 12:21:41
/archives/xfs/2008-10/msg01200.html (15,900 bytes)

16. ilesystem corruption on the arm(el) architecture (score: 1)
Author: roy <lachlan@xxxxxxx>
Date: Mon, 20 Oct 2008 16:29:29 +1100
Ok, that makes more sense. Yeah, xfs_setup_inode() is what is doing: inode->i_state = I_NEW|I_LOCK; which happens after the cache miss has been processed. Ok, so the initialisation code needs to clea
/archives/xfs/2008-10/msg01201.html (18,244 bytes)

17. esystem is read-only (score: 1)
Author: <david@xxxxxxxxxxxxx>
Date: Mon, 20 Oct 2008 17:05:22 +1100
On second thoughts, the inode has not been set up properly by this stage, so we can't really even expect to be able to call iput() on it. Hmmmm - maybe the only thing we can do here is call security_
/archives/xfs/2008-10/msg01203.html (12,767 bytes)

18. Undelivered Mail Returned to Sender (score: 1)
Author: <procurves@xxxxxxxxx>
Date: Mon, 20 Oct 2008 17:41:33 -0400
Calling destroy_inode after exporting it seems most logical. If we want to undo init_inode_once we should have VFS functionality taking care of that, too. I've implemented this including some prepara
/archives/xfs/2008-10/msg01230.html (10,288 bytes)

19. [PATCH] Re: another problem with latest code drops (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 17 Oct 2008 13:04:34 +1100
..... Patch below that replaces xfs_idestroy() with IRELE() to destroy the inode via the normal iput() path. It also fixes a second issue that I found by inspection related to security contexts as a
/archives/xfs/2008-10/msg01970.html (12,791 bytes)

20. Re: [PATCH] Re: another problem with latest code drops (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 17 Oct 2008 13:07:18 +1100
And now with the patch. -- Dave Chinner david@xxxxxxxxxxxxx XFS: Ensure that we destroy the linux inode after initialisation Now that XFS initialises the struct inode prior to completing all checks a
/archives/xfs/2008-10/msg01971.html (16,544 bytes)


This search system is powered by Namazu