From patchwork Mon Dec 5 14:39:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christoph Hellwig X-Patchwork-Id: 9486697 X-Mozilla-Keys: nonjunk Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on sandeen.net X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-Spam-HP: BAYES_00=-1.9,HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-0.1 X-Original-To: sandeen@sandeen.net Delivered-To: sandeen@sandeen.net Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by sandeen.net (Postfix) with ESMTP id DD60A479AED for ; Mon, 5 Dec 2016 09:09:47 -0600 (CST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751615AbcLEPKb (ORCPT ); Mon, 5 Dec 2016 10:10:31 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:48784 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751598AbcLEPKa (ORCPT ); Mon, 5 Dec 2016 10:10:30 -0500 Received: from hch by bombadil.infradead.org with local (Exim 4.85_2 #1 (Red Hat Linux)) id 1cDuQ6-0006HP-FU; Mon, 05 Dec 2016 14:39:06 +0000 Date: Mon, 5 Dec 2016 06:39:06 -0800 From: Christoph Hellwig To: Eryu Guan Cc: linux-xfs@vger.kernel.org Subject: Re: [BUG] xfs/109 crashed 2k block size reflink enabled XFS Message-ID: <20161205143906.GA16352@infradead.org> References: <20161205092112.GS29149@eguan.usersys.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20161205092112.GS29149@eguan.usersys.redhat.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Mon, Dec 05, 2016 at 05:21:12PM +0800, Eryu Guan wrote: > Hi, > > I hit an xfs/109 crash today while testing reflink XFS with 2k block > size on x86_64 hosts (both baremetal and kvm guest). > > It can be reproduced by running xfs/109 many times, I tried 50-times > loop twice and it crashed at the 21st and 46th runs. And I can reproduce > it with both linus tree (4.9-rc4) and linux-xfs tree for-next branch > (updated on 2016-11-30). I haven't been able to reproduce it with 4k > block size XFS. Haven't been able to reproduce it yet unfortunately. But from looking at the out of range block this looks like it could be NULLFSBLOCK converted to a daddr. I assume you are running without CONFIG_XFS_DEBUG or CONFIG_XFS_WARN enabled? Below would catch this issue in a non-debug build. Still trying to reproduce in the meantime.. --- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c index c6eb219..2c19b11 100644 --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -780,12 +780,14 @@ try_another_ag: if (xfs_sb_version_hasreflink(&cur->bc_mp->m_sb) && args.fsbno == NULLFSBLOCK && args.type == XFS_ALLOCTYPE_NEAR_BNO) { + printk("trying another AG\n"); dfops->dop_low = true; goto try_another_ag; } /* * Allocation can't fail, the space was reserved. */ + BUG_ON(args.fsbno == NULLFSBLOCK); ASSERT(args.fsbno != NULLFSBLOCK); ASSERT(*firstblock == NULLFSBLOCK || args.agno == XFS_FSB_TO_AGNO(mp, *firstblock) ||