All of lore.kernel.org
 help / color / mirror / Atom feed
From: "hch@lst.de" <hch@lst.de>
To: "Verma, Vishal L" <vishal.l.verma@intel.com>
Cc: "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	"Williams, Dan J" <dan.j.williams@intel.com>,
	"hch@lst.de" <hch@lst.de>,
	"david@fromorbit.com" <david@fromorbit.com>,
	"darrick.wong@oracle.com" <darrick.wong@oracle.com>
Subject: Re: 5.3-rc1 regression with XFS log recovery
Date: Sun, 18 Aug 2019 19:34:26 +0200	[thread overview]
Message-ID: <20190818173426.GA32311@lst.de> (raw)
In-Reply-To: <20190818074140.GA18648@lst.de>

On Sun, Aug 18, 2019 at 09:41:40AM +0200, hch@lst.de wrote:
> On Sun, Aug 18, 2019 at 09:11:28AM +0200, hch@lst.de wrote:
> > > The kernel log shows the following when the mount fails:
> > 
> > Is it always that same message?  I'll see if I can reproduce it,
> > but I won't have that much memory to spare to create fake pmem,
> > hope this also works with a single device and/or less memory..
> 
> I've reproduced a similar ASSERT with a small pmem device, so I hope
> I can debug the issue locally now.

So I can also reproduce the same issue with the ramdisk driver, but not
with any other 4k sector size device (nvmet, scsi target, scsi_debug,
loop).  Which made me wonder if there is some issue about the memory
passed in, and indeed just switching to plain vmalloc vs the XFS
kmem_alloc_large wrapper that either uses kmalloc or vmalloc fixes
the issue for me.  I don't really understand why yet, maybe I need to
dig out alignment testing patches.

diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
index 13d1d3e95b88..918ad3b884a7 100644
--- a/fs/xfs/xfs_log_recover.c
+++ b/fs/xfs/xfs_log_recover.c
@@ -125,7 +125,7 @@ xlog_alloc_buffer(
 	if (nbblks > 1 && log->l_sectBBsize > 1)
 		nbblks += log->l_sectBBsize;
 	nbblks = round_up(nbblks, log->l_sectBBsize);
-	return kmem_alloc_large(BBTOB(nbblks), KM_MAYFAIL);
+	return vmalloc(BBTOB(nbblks));
 }
 
 /*
@@ -416,7 +416,7 @@ xlog_find_verify_cycle(
 	*new_blk = -1;
 
 out:
-	kmem_free(buffer);
+	vfree(buffer);
 	return error;
 }
 
@@ -527,7 +527,7 @@ xlog_find_verify_log_record(
 		*last_blk = i;
 
 out:
-	kmem_free(buffer);
+	vfree(buffer);
 	return error;
 }
 
@@ -781,7 +781,7 @@ xlog_find_head(
 			goto out_free_buffer;
 	}
 
-	kmem_free(buffer);
+	vfree(buffer);
 	if (head_blk == log_bbnum)
 		*return_head_blk = 0;
 	else
@@ -795,7 +795,7 @@ xlog_find_head(
 	return 0;
 
 out_free_buffer:
-	kmem_free(buffer);
+	vfree(buffer);
 	if (error)
 		xfs_warn(log->l_mp, "failed to find log head");
 	return error;
@@ -1049,7 +1049,7 @@ xlog_verify_tail(
 		"Tail block (0x%llx) overwrite detected. Updated to 0x%llx",
 			 orig_tail, *tail_blk);
 out:
-	kmem_free(buffer);
+	vfree(buffer);
 	return error;
 }
 
@@ -1096,7 +1096,7 @@ xlog_verify_head(
 	error = xlog_rseek_logrec_hdr(log, *head_blk, *tail_blk,
 				      XLOG_MAX_ICLOGS, tmp_buffer,
 				      &tmp_rhead_blk, &tmp_rhead, &tmp_wrapped);
-	kmem_free(tmp_buffer);
+	vfree(tmp_buffer);
 	if (error < 0)
 		return error;
 
@@ -1429,7 +1429,7 @@ xlog_find_tail(
 		error = xlog_clear_stale_blocks(log, tail_lsn);
 
 done:
-	kmem_free(buffer);
+	vfree(buffer);
 
 	if (error)
 		xfs_warn(log->l_mp, "failed to locate log tail");
@@ -1477,7 +1477,7 @@ xlog_find_zeroed(
 	first_cycle = xlog_get_cycle(offset);
 	if (first_cycle == 0) {		/* completely zeroed log */
 		*blk_no = 0;
-		kmem_free(buffer);
+		vfree(buffer);
 		return 1;
 	}
 
@@ -1488,7 +1488,7 @@ xlog_find_zeroed(
 
 	last_cycle = xlog_get_cycle(offset);
 	if (last_cycle != 0) {		/* log completely written to */
-		kmem_free(buffer);
+		vfree(buffer);
 		return 0;
 	}
 
@@ -1535,7 +1535,7 @@ xlog_find_zeroed(
 
 	*blk_no = last_blk;
 out_free_buffer:
-	kmem_free(buffer);
+	vfree(buffer);
 	if (error)
 		return error;
 	return 1;
@@ -1647,7 +1647,7 @@ xlog_write_log_records(
 	}
 
 out_free_buffer:
-	kmem_free(buffer);
+	vfree(buffer);
 	return error;
 }
 
@@ -5291,7 +5291,7 @@ xlog_do_recovery_pass(
 			hblks = h_size / XLOG_HEADER_CYCLE_SIZE;
 			if (h_size % XLOG_HEADER_CYCLE_SIZE)
 				hblks++;
-			kmem_free(hbp);
+			vfree(hbp);
 			hbp = xlog_alloc_buffer(log, hblks);
 		} else {
 			hblks = 1;
@@ -5307,7 +5307,7 @@ xlog_do_recovery_pass(
 		return -ENOMEM;
 	dbp = xlog_alloc_buffer(log, BTOBB(h_size));
 	if (!dbp) {
-		kmem_free(hbp);
+		vfree(hbp);
 		return -ENOMEM;
 	}
 
@@ -5468,9 +5468,9 @@ xlog_do_recovery_pass(
 	}
 
  bread_err2:
-	kmem_free(dbp);
+	vfree(dbp);
  bread_err1:
-	kmem_free(hbp);
+	vfree(hbp);
 
 	/*
 	 * Submit buffers that have been added from the last record processed,

  reply	other threads:[~2019-08-18 17:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16 20:59 5.3-rc1 regression with XFS log recovery Verma, Vishal L
2019-08-18  7:11 ` hch
2019-08-18  7:41   ` hch
2019-08-18 17:34     ` hch [this message]
2019-08-19  0:08       ` Dave Chinner
2019-08-19  3:49         ` hch
2019-08-19  4:11           ` hch
2019-08-19  4:22             ` Dave Chinner
2019-08-19  4:29               ` hch
2019-08-19  4:40                 ` hch
2019-08-19  5:31                   ` Dave Chinner
2019-08-20  6:14                     ` hch
2019-08-20  4:41                   ` Dave Chinner
2019-08-20  5:53                     ` hch
2019-08-20  7:44                       ` Dave Chinner
2019-08-20  8:13                       ` Ming Lei
2019-08-20  9:24                         ` Ming Lei
2019-08-20 16:30                           ` Verma, Vishal L
2019-08-20 21:44                           ` Dave Chinner
2019-08-20 22:08                             ` Verma, Vishal L
2019-08-20 23:53                               ` Dave Chinner
2019-08-21  2:19                               ` Ming Lei
2019-08-21  1:56                             ` Ming Lei
2019-08-19  4:15           ` Dave Chinner
2019-08-19 17:19       ` Verma, Vishal L
2019-08-21  0:26       ` Dave Chinner
2019-08-21  0:44         ` hch
2019-08-21  1:08           ` Dave Chinner
2019-08-21  1:56             ` Verma, Vishal L
2019-08-21  6:15               ` Dave Chinner
2019-08-26 17:32       ` Verma, Vishal L

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190818173426.GA32311@lst.de \
    --to=hch@lst.de \
    --cc=dan.j.williams@intel.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=vishal.l.verma@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.