[PATCH] Re: another problem with latest code drops

[Dave Chinner <david@fromorbit.com>]

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?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com