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

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)

Current List: 1 - 20
Page: [1] [2]