On Wed, 2019-08-21 at 11:08 +1000, Dave Chinner wrote: > On Wed, Aug 21, 2019 at 02:44:13AM +0200, hch@xxxxxx 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?
