| To: | Dave Chinner <david@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: -mm: xfs lockdep warning |
| From: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
| Date: | Mon, 20 Sep 2010 15:13:55 -0400 |
| Cc: | Yang Ruirui <ruirui.r.yang@xxxxxxxxx>, hch@xxxxxxxxxxxxx, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, xfs@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Alex Elder <aelder@xxxxxxx> |
| In-reply-to: | <20100917005227.GJ24409@dastard> |
| References: | <201009161546.16909.ruirui.r.yang@xxxxxxxxx> <20100917005227.GJ24409@dastard> |
| User-agent: | Mutt/1.5.20 (2009-08-17) |
On Fri, Sep 17, 2010 at 10:52:27AM +1000, Dave Chinner wrote: > Christoph, this implies an inode that has been marked for reclaim > that has not passed through xfs_fs_evict_inode() after being > initialised. If it went through the eviction process, the iolock > would have been re-initialised to a different context. Can you think > of any path that can get here without going through ->evict? I can't > off the top of my head... I think this could happen if the init_inode_always during re-initialization of an inode in reclaim fails in iget. I have a patch to add that I'll run through xfsqa. It should only happen very rarely. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Question regarding performance on big files., Mathieu AVILA |
|---|---|
| Next by Date: | Re: Question regarding performance on big files., Stan Hoeppner |
| Previous by Thread: | Re: -mm: xfs lockdep warning, Dave Chinner |
| Next by Thread: | Re: -mm: xfs lockdep warning, Torsten Kaiser |
| Indexes: | [Date] [Thread] [Top] [All Lists] |