[Top] [All Lists]

Re: next-20090220: XFS, IMA: BUG: sleeping function called from invalid

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: next-20090220: XFS, IMA: BUG: sleeping function called from invalid context at mm/slub.c:1613
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Wed, 25 Feb 2009 09:34:51 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20090224191429.GA10627@xxxxxxxxxxxxx>
Mail-followup-to: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
References: <a4423d670902200300n1d1bfdeeg6daca4b32989c9d3@xxxxxxxxxxxxxx> <20090220122242.b36a778f.akpm@xxxxxxxxxxxxxxxxxxxx> <20090224191429.GA10627@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Feb 24, 2009 at 02:14:29PM -0500, Christoph Hellwig wrote:
> On Fri, Feb 20, 2009 at 12:22:42PM -0800, Andrew Morton wrote:
> > But to fix this bug, xfs needs to stop calling inode_init_always()
> > under read_lock().  Because inode_alloc_security() also can sleep (see
> > new_inode_smack()).
> The normal inode initialization path is fine as it's not in atomic
> context, but if we relcaim a partially torn down inode in
> xfs_iget_cache_hit we call inode_init_always under pag_ici_lock.
> I wonder if we should just give up on trying to "recover" such
> inodes.  Instead call finish_reclaim on them and restart the inode
> cache lookup.

The reason for this code is that journalling allows us to reuse the
inode without flushing it to disk. If we reclaim it, then we force
it to be flushed to disk before it can be reused. That will greatly
slow down workloads that create and delete temporary files

I had a brief look at the code, and I think it can be reworked to
avoid re-initialisation under the pag_ici_lock. I should have some
time this weekend to test a fix....


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>