Messages in this thread | | | Date | Tue, 16 Oct 2012 10:21:47 +1100 | From | Dave Chinner <> | Subject | Re: xfs: fix buffer lookup race on allocation failure |
| |
On Mon, Oct 15, 2012 at 11:27:58AM +0200, William Dauchy wrote: > Hello, > > I believe, the commit fe2429b fixes the attached kernel trace. > I tested it both on top of 3.2 and 3.4 stable tree. > Could we consider adding this patch in stable tree at least for 3.2 and 3.4? > > commit fe2429b0966a7ec42b5fe3bf96f0f10de0a3b536 > Author: Dave Chinner <dchinner@redhat.com> > Date: Mon Apr 23 15:58:45 2012 +1000 > > xfs: fix buffer lookup race on allocation failure > > When memory allocation fails to add the page array or tht epages to > a buffer during xfs_buf_get(), the buffer is left in the cache in a > partially initialised state. There is enough state left for the next > lookup on that buffer to find the buffer, and for the buffer to then > be used without finishing the initialisation. As a result, when an > attempt to do IO on the buffer occurs, it fails with EIO because > there are no pages attached to the buffer. > > We cannot remove the buffer from the cache immediately and free it, > because there may already be a racing lookup that is blocked on the > buffer lock. Hence the moment we unlock the buffer to then free it, > the other user is woken and we have a use-after-free situation. > > To avoid this race condition altogether, allocate the pages for the > buffer before we insert it into the cache. This then means that we > don't have an allocation failure case to deal after the buffer is > already present in the cache, and hence avoid the problem > altogether. In most cases we won't have racing inserts for the same > buffer, and so won't increase the memory pressure allocation before > insertion may entail. > > Signed-off-by: Dave Chinner <dchinner@redhat.com> > Reviewed-by: Mark Tinguely <tinguely@sgi.com> > Signed-off-by: Ben Myers <bpm@sgi.com> > > > XFS: Assertion failed: bp->b_bn != XFS_BUF_DADDR_NULL, file: > fs/xfs/xfs_buf.c, line: 598
You're running a CONFIG_XFS_DEBUG kernel. If you can reproduce the problem with CONFIG_XFS_DEBUG, then it probably should be backported.
If you are using CONFIG_XFS_DEBUG on production systems, then you shouldn't be because it does nasty things to allocation patterns, not to mention a 25-30% CPU overhead and will panic in places where errors are recoverable but as a developer we want to try to find out what went wrong.
In this case, you'll get a transient EIO error when the I/O is issued on the malformed buffer, but other than that the system can continue alon just fine and the next read ofthe buffer will work prefectly...
Cheers,
Dave. -- Dave Chinner david@fromorbit.com
| |