Re: 5.3-rc1 regression with XFS log recovery

["Verma, Vishal L" <vishal.l.verma@intel.com>]

On Wed, 2019-08-21 at 11:08 +1000, Dave Chinner wrote:
> On Wed, Aug 21, 2019 at 02:44:13AM +0200, hch@lst.de wrote:
> > On Wed, Aug 21, 2019 at 10:26:43AM +1000, Dave Chinner wrote:
> > > After thinking on this for a bit, I suspect the better thing to do
> > > here is add a KM_ALIGNED flag to the allocation, so if the
> > > internal
> > > kmem_alloc() returns an unaligned pointer we free it and fall
> > > through to vmalloc() to get a properly aligned pointer....
> > > 
> > > That way none of the other interfaces have to change, and we can
> > > then use kmem_alloc_large() everywhere we allocate buffers for IO.
> > > And we don't need new infrastructure just to support these debug
> > > configurations, either.
> > > 
> > > Actually, kmem_alloc_io() might be a better idea - keep the
> > > aligned
> > > flag internal to the kmem code. Seems like a pretty simple
> > > solution
> > > to the entire problem we have here...
> > 
> > The interface sounds ok.  The simple try and fallback implementation
> > OTOH means we always do two allocations іf slub debugging is
> > enabled,
> > which is a little lasty.
> 
> Some creative ifdefery could avoid that, but quite frankly it's only
> necessary for limited allocation contexts and so the
> overhead/interactions would largely be unnoticable compared to the
> wider impact of memory debugging...
> 
> > I guess the best we can do for 5.3 and
> > then figure out a way to avoid for later.
> 
> Yeah, it also has the advantage of documenting all the places we
> need to be careful of allocation alignment, and it would allow us to
> simply plug in whatever future infrastructure comes along that
> guarantees allocation alignment without changing any other XFS
> code...

Just to clarify, this precludes the changes to bio_add_page() you
suggested earlier, right?