Re: 5.3-rc1 regression with XFS log recovery

Verma, Vishal L
2019-08-26T17:32:46Z

On Sun, 2019-08-18 at 19:34 +0200, hch@lst.de wrote:
> 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));

Is the plan to use this vmalloc fix for 5.3? Is there anything I can
help with to make progress on this?

-Vishal