On Sun, 2019-08-18 at 19:34 +0200, hch@xxxxxx wrote: > On Sun, Aug 18, 2019 at 09:41:40AM +0200, hch@xxxxxx wrote: > > On Sun, Aug 18, 2019 at 09:11:28AM +0200, hch@xxxxxx 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
