From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id B8A187FA3 for ; Wed, 6 Aug 2014 07:32:34 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 8A7538F8050 for ; Wed, 6 Aug 2014 05:32:31 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id oublZvUZlmmJL0Hs for ; Wed, 06 Aug 2014 05:32:29 -0700 (PDT) Date: Wed, 6 Aug 2014 22:32:15 +1000 From: Dave Chinner Subject: Re: use-after-free on log replay failure Message-ID: <20140806123215.GJ20518@dastard> References: <20140113204314.GJ3469@dastard> <20140115014503.GQ3469@dastard> <20140119231745.GF18112@dastard> <4B2A412C75324EE9880358513C069476@alyakaslap> <9D3CBECB663B4A77B7EF74B67973310A@alyakaslap> <20140804230721.GA20518@dastard> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: Alex Lyakas Cc: xfs@oss.sgi.com On Wed, Aug 06, 2014 at 01:05:34PM +0300, Alex Lyakas wrote: > Hi Dave, > > On Tue, Aug 5, 2014 at 2:07 AM, Dave Chinner wrote: > > On Mon, Aug 04, 2014 at 02:00:05PM +0300, Alex Lyakas wrote: > >> Greetings, > >> > >> we had a log replay failure due to some errors that the underlying > >> block device returned: > >> [49133.801406] XFS (dm-95): metadata I/O error: block 0x270e8c180 > >> ("xlog_recover_iodone") error 28 numblks 16 > >> [49133.802495] XFS (dm-95): log mount/recovery failed: error 28 > >> [49133.802644] XFS (dm-95): log mount failed > > > > #define ENOSPC 28 /* No space left on device */ > > > > You're getting an ENOSPC as a metadata IO error during log recovery? > > Thin provisioning problem, perhaps, > Yes, it is a thin provisioning problem (which I already know the cause for). > > > and the error is occurring on > > submission rather than completion? If so: > > > > 8d6c121 xfs: fix buffer use after free on IO error > I am not sure what do you mean by "submission rather than completion". > Do you mean that xfs_buf_ioapply_map() returns without submitting any > bios? No, that the bio submission results in immediate failure (e.g. the device goes away, so submission results in ENODEV). Hence when _xfs_buf_ioapply() releases it's IO reference itis the only remaining reference to the buffer and so completion processing is run immediately. i.e. inline from the submission path. Normally IO errors are reported through the bio in IO completion interrupt context. i.e the IO is completed by the hardware and the error status is attached to bio, which is then completed and we get into XFS that way. The IO submision context is long gone at this point.... > In that case, no, bios are submitted to the block device, and it > fails them through a different context with ENOSPC error. I will still > try the patch you mentioned, because it also looks relevant to another > question I addressed to you earlier in: > http://oss.sgi.com/archives/xfs/2013-11/msg00648.html No, that's a different problem. 9c23ecc xfs: unmount does not wait for shutdown during unmount Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs