Re: [PATCH] Re: another problem with latest code drops

[Lachlan McIlroy <lachlan@sgi.com>]

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 here though:
>>>>>
>>>>> 116605669 116605669  26%    0.23K 6859157       17  27436628K selinux_inode_security
>>>> Ah - I don't run selinux. Sounds like a bug that needs reporting
>>>> to lkml...
>>> I'm sure this is caused by your changes that introduced inode_init_always().
>>> It re-initialises an existing inode without destroying it first so it calls
>>> security_inode_alloc() without calling security_inode_free().
>> I can't think of how. The layers above XFS are symmetric:
> .....
>> And we should have this symmetry everywhere.
>>
>> <thinks for a bit>
>>
>> Hmmmm - maybe the xfs_iget_cache_miss failure paths where we call
>> xfs_idestroy() could leak contexts. We should really call xfs_iput()
>> because we have an initialised linux inode at this point and so
>> we need to go through destroy_inode(). I'll have a bit more of
>> a look, but this doesn't seem to account for the huge number of
>> leaked contexts you reported....
> 
> 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 result
> of hooking up ->destroy_inode.
> 
> It's running QA now.
> 
> FWIW, I'm not sure if this patch will apply cleanly - I'm still
> running of my stack of patches and not what has been checked into
> ptools. Any idea of when all the patches in ptools will be pushed
> out to the git tree?
Should be on OSS later today.