* Re: [PATCH 3/3] xfs: alignment check bio buffers [not found] ` <20190821083820.11725-4-david@fromorbit.com> @ 2019-08-21 23:29 ` Christoph Hellwig 2019-08-22 0:37 ` Dave Chinner 2019-08-22 2:50 ` Ming Lei 0 siblings, 2 replies; 11+ messages in thread From: Christoph Hellwig @ 2019-08-21 23:29 UTC (permalink / raw) To: Dave Chinner; +Cc: linux-xfs, Jens Axboe, linux-block On Wed, Aug 21, 2019 at 06:38:20PM +1000, Dave Chinner wrote: > From: Dave Chinner <dchinner@redhat.com> > > Add memory buffer alignment validation checks to bios built in XFS > to catch bugs that will result in silent data corruption in block > drivers that cannot handle unaligned memory buffers but don't > validate the incoming buffer alignment is correct. > > Known drivers with these issues are xenblk, brd and pmem. > > Despite there being nothing XFS specific to xfs_bio_add_page(), this > function was created to do the required validation because the block > layer developers that keep telling us that is not possible to > validate buffer alignment in bio_add_page(), and even if it was > possible it would be too much overhead to do at runtime. I really don't think we should life this to XFS, but instead fix it in the block layer. And that is not only because I have a pending series lifting bits you are touching to the block layer.. > +int > +xfs_bio_add_page( > + struct bio *bio, > + struct page *page, > + unsigned int len, > + unsigned int offset) > +{ > + struct request_queue *q = bio->bi_disk->queue; > + bool same_page = false; > + > + if (WARN_ON_ONCE(!blk_rq_aligned(q, len, offset))) > + return -EIO; > + > + if (!__bio_try_merge_page(bio, page, len, offset, &same_page)) { > + if (bio_full(bio, len)) > + return 0; > + __bio_add_page(bio, page, len, offset); > + } > + return len; I know Jens disagree, but with the amount of bugs we've been hitting thangs to slub (and I'm pretty sure we have a more hiding outside of XFS) I think we need to add the blk_rq_aligned check to bio_add_page. Note that all current callers of bio_add_page can only really check for the return value != the added len anyway, so it is not going to make anything worse. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] xfs: alignment check bio buffers 2019-08-21 23:29 ` [PATCH 3/3] xfs: alignment check bio buffers Christoph Hellwig @ 2019-08-22 0:37 ` Dave Chinner 2019-08-22 8:03 ` Christoph Hellwig 2019-08-22 2:50 ` Ming Lei 1 sibling, 1 reply; 11+ messages in thread From: Dave Chinner @ 2019-08-22 0:37 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-xfs, Jens Axboe, linux-block On Wed, Aug 21, 2019 at 04:29:45PM -0700, Christoph Hellwig wrote: > On Wed, Aug 21, 2019 at 06:38:20PM +1000, Dave Chinner wrote: > > From: Dave Chinner <dchinner@redhat.com> > > > > Add memory buffer alignment validation checks to bios built in XFS > > to catch bugs that will result in silent data corruption in block > > drivers that cannot handle unaligned memory buffers but don't > > validate the incoming buffer alignment is correct. > > > > Known drivers with these issues are xenblk, brd and pmem. > > > > Despite there being nothing XFS specific to xfs_bio_add_page(), this > > function was created to do the required validation because the block > > layer developers that keep telling us that is not possible to > > validate buffer alignment in bio_add_page(), and even if it was > > possible it would be too much overhead to do at runtime. > > I really don't think we should life this to XFS, but instead fix it > in the block layer. And that is not only because I have a pending > series lifting bits you are touching to the block layer.. I agree, but.... > > > +int > > +xfs_bio_add_page( > > + struct bio *bio, > > + struct page *page, > > + unsigned int len, > > + unsigned int offset) > > +{ > > + struct request_queue *q = bio->bi_disk->queue; > > + bool same_page = false; > > + > > + if (WARN_ON_ONCE(!blk_rq_aligned(q, len, offset))) > > + return -EIO; > > + > > + if (!__bio_try_merge_page(bio, page, len, offset, &same_page)) { > > + if (bio_full(bio, len)) > > + return 0; > > + __bio_add_page(bio, page, len, offset); > > + } > > + return len; > > I know Jens disagree, but with the amount of bugs we've been hitting > thangs to slub (and I'm pretty sure we have a more hiding outside of > XFS) I think we need to add the blk_rq_aligned check to bio_add_page. ... I'm not prepared to fight this battle to get this initial fix into the code. Get the fix merged, then we can > Note that all current callers of bio_add_page can only really check > for the return value != the added len anyway, so it is not going to > make anything worse. It does make things worse - it turns multi-bio chaining loops like the one xfs_rw_bdev() into an endless loop as they don't make progress - they just keep allocating a new bio and retrying the same badly aligned buffer and failing. So if we want an alignment failure to error out, callers need to handle the failure, not treat it like a full bio. Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] xfs: alignment check bio buffers 2019-08-22 0:37 ` Dave Chinner @ 2019-08-22 8:03 ` Christoph Hellwig 2019-08-22 10:17 ` Dave Chinner 0 siblings, 1 reply; 11+ messages in thread From: Christoph Hellwig @ 2019-08-22 8:03 UTC (permalink / raw) To: Dave Chinner; +Cc: Christoph Hellwig, linux-xfs, Jens Axboe, linux-block On Thu, Aug 22, 2019 at 10:37:45AM +1000, Dave Chinner wrote: > > I know Jens disagree, but with the amount of bugs we've been hitting > > thangs to slub (and I'm pretty sure we have a more hiding outside of > > XFS) I think we need to add the blk_rq_aligned check to bio_add_page. > > ... I'm not prepared to fight this battle to get this initial fix > into the code. Get the fix merged, then we can Well, the initial fix are the first two patches. This patch really just adds a safety belt. I'll happily take over the effort to get sensible checks in the block code if you give me a couple weeks, in the meantime I'd prefer if we could skip this third patch for now. > > Note that all current callers of bio_add_page can only really check > > for the return value != the added len anyway, so it is not going to > > make anything worse. > > It does make things worse - it turns multi-bio chaining loops like > the one xfs_rw_bdev() into an endless loop as they don't make > progress - they just keep allocating a new bio and retrying the same > badly aligned buffer and failing. So if we want an alignment failure > to error out, callers need to handle the failure, not treat it like > a full bio. True. And we need to improve the interface here, which I'm going to try to fit into my series that lift some common bio filling code to the core. I'll add you to the cc list. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] xfs: alignment check bio buffers 2019-08-22 8:03 ` Christoph Hellwig @ 2019-08-22 10:17 ` Dave Chinner 0 siblings, 0 replies; 11+ messages in thread From: Dave Chinner @ 2019-08-22 10:17 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-xfs, Jens Axboe, linux-block On Thu, Aug 22, 2019 at 01:03:12AM -0700, Christoph Hellwig wrote: > On Thu, Aug 22, 2019 at 10:37:45AM +1000, Dave Chinner wrote: > > > I know Jens disagree, but with the amount of bugs we've been hitting > > > thangs to slub (and I'm pretty sure we have a more hiding outside of > > > XFS) I think we need to add the blk_rq_aligned check to bio_add_page. > > > > ... I'm not prepared to fight this battle to get this initial fix > > into the code. Get the fix merged, then we can > > Well, the initial fix are the first two patches. This patch really > just adds a safety belt. I'll happily take over the effort to get > sensible checks in the block code if you give me a couple weeks, > in the meantime I'd prefer if we could skip this third patch for now. Fine by me. I'll just repost the current versions of the first two patches (now three) in the morning. Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] xfs: alignment check bio buffers 2019-08-21 23:29 ` [PATCH 3/3] xfs: alignment check bio buffers Christoph Hellwig 2019-08-22 0:37 ` Dave Chinner @ 2019-08-22 2:50 ` Ming Lei 2019-08-22 4:49 ` Dave Chinner 1 sibling, 1 reply; 11+ messages in thread From: Ming Lei @ 2019-08-22 2:50 UTC (permalink / raw) To: Christoph Hellwig Cc: Dave Chinner, open list:XFS FILESYSTEM, Jens Axboe, linux-block On Thu, Aug 22, 2019 at 8:06 AM Christoph Hellwig <hch@infradead.org> wrote: > > On Wed, Aug 21, 2019 at 06:38:20PM +1000, Dave Chinner wrote: > > From: Dave Chinner <dchinner@redhat.com> > > > > Add memory buffer alignment validation checks to bios built in XFS > > to catch bugs that will result in silent data corruption in block > > drivers that cannot handle unaligned memory buffers but don't > > validate the incoming buffer alignment is correct. > > > > Known drivers with these issues are xenblk, brd and pmem. > > > > Despite there being nothing XFS specific to xfs_bio_add_page(), this > > function was created to do the required validation because the block > > layer developers that keep telling us that is not possible to > > validate buffer alignment in bio_add_page(), and even if it was > > possible it would be too much overhead to do at runtime. > > I really don't think we should life this to XFS, but instead fix it > in the block layer. And that is not only because I have a pending > series lifting bits you are touching to the block layer.. > > > +int > > +xfs_bio_add_page( > > + struct bio *bio, > > + struct page *page, > > + unsigned int len, > > + unsigned int offset) > > +{ > > + struct request_queue *q = bio->bi_disk->queue; > > + bool same_page = false; > > + > > + if (WARN_ON_ONCE(!blk_rq_aligned(q, len, offset))) > > + return -EIO; > > + > > + if (!__bio_try_merge_page(bio, page, len, offset, &same_page)) { > > + if (bio_full(bio, len)) > > + return 0; > > + __bio_add_page(bio, page, len, offset); > > + } > > + return len; > > I know Jens disagree, but with the amount of bugs we've been hitting > thangs to slub (and I'm pretty sure we have a more hiding outside of > XFS) I think we need to add the blk_rq_aligned check to bio_add_page. It isn't correct to blk_rq_aligned() here because 'len' has to be logical block size aligned, instead of DMA aligned only. Also not sure all users may setup bio->bi_disk well before adding page to bio, since it is allowed to do that now. If slub buffer crosses two pages, block layer may not handle it at all even though un-aligned 'offset' issue is solved. Thanks, Ming Lei ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] xfs: alignment check bio buffers 2019-08-22 2:50 ` Ming Lei @ 2019-08-22 4:49 ` Dave Chinner 2019-08-22 7:23 ` Ming Lei 2019-08-22 8:08 ` Christoph Hellwig 0 siblings, 2 replies; 11+ messages in thread From: Dave Chinner @ 2019-08-22 4:49 UTC (permalink / raw) To: Ming Lei Cc: Christoph Hellwig, open list:XFS FILESYSTEM, Jens Axboe, linux-block On Thu, Aug 22, 2019 at 10:50:02AM +0800, Ming Lei wrote: > On Thu, Aug 22, 2019 at 8:06 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > On Wed, Aug 21, 2019 at 06:38:20PM +1000, Dave Chinner wrote: > > > From: Dave Chinner <dchinner@redhat.com> > > > > > > Add memory buffer alignment validation checks to bios built in XFS > > > to catch bugs that will result in silent data corruption in block > > > drivers that cannot handle unaligned memory buffers but don't > > > validate the incoming buffer alignment is correct. > > > > > > Known drivers with these issues are xenblk, brd and pmem. > > > > > > Despite there being nothing XFS specific to xfs_bio_add_page(), this > > > function was created to do the required validation because the block > > > layer developers that keep telling us that is not possible to > > > validate buffer alignment in bio_add_page(), and even if it was > > > possible it would be too much overhead to do at runtime. > > > > I really don't think we should life this to XFS, but instead fix it > > in the block layer. And that is not only because I have a pending > > series lifting bits you are touching to the block layer.. > > > > > +int > > > +xfs_bio_add_page( > > > + struct bio *bio, > > > + struct page *page, > > > + unsigned int len, > > > + unsigned int offset) > > > +{ > > > + struct request_queue *q = bio->bi_disk->queue; > > > + bool same_page = false; > > > + > > > + if (WARN_ON_ONCE(!blk_rq_aligned(q, len, offset))) > > > + return -EIO; > > > + > > > + if (!__bio_try_merge_page(bio, page, len, offset, &same_page)) { > > > + if (bio_full(bio, len)) > > > + return 0; > > > + __bio_add_page(bio, page, len, offset); > > > + } > > > + return len; > > > > I know Jens disagree, but with the amount of bugs we've been hitting > > thangs to slub (and I'm pretty sure we have a more hiding outside of > > XFS) I think we need to add the blk_rq_aligned check to bio_add_page. > > It isn't correct to blk_rq_aligned() here because 'len' has to be logical block > size aligned, instead of DMA aligned only. News to me. AFAIA, the overall _IO_ that is being built needs to be a multiple of the logical block size in total size (i.e. bio->bi_iter.size) because sub sector IO is not allowed. But queue DMA limits are not defined in sectors - they define the scatter/gather DMA capability of the hardware, and that's what individual segments (bvecs) need to align to. That's what blk_rq_aligned() checks here - that the bvec segment aligns to what the underlying driver(s) requires, not that the entire IO is sector sized and aligned. Also, think about multipage bvecs - the pages we are spanning here are contiguous pages, so this should end up merging them and turning it into a single multipage bvec whose length is sector size aligned... > Also not sure all users may setup bio->bi_disk well before adding page to bio, > since it is allowed to do that now. XFS does, so I just don't care about random users of bio_add_page() in this patch. Somebody else can run the block layer gauntlet to get these checks moved into generic code and they've already been rejected twice as unnecessary. > If slub buffer crosses two pages, block layer may not handle it at all > even though > un-aligned 'offset' issue is solved. A slub buffer crossing two _contiguous_ pages should end up merged as a multipage bvec. But I'm curious, what does adding multiple contiguous pages to a bio actually break? -Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] xfs: alignment check bio buffers 2019-08-22 4:49 ` Dave Chinner @ 2019-08-22 7:23 ` Ming Lei 2019-08-22 8:08 ` Christoph Hellwig 1 sibling, 0 replies; 11+ messages in thread From: Ming Lei @ 2019-08-22 7:23 UTC (permalink / raw) To: Dave Chinner Cc: Ming Lei, Christoph Hellwig, open list:XFS FILESYSTEM, Jens Axboe, linux-block On Thu, Aug 22, 2019 at 02:49:05PM +1000, Dave Chinner wrote: > On Thu, Aug 22, 2019 at 10:50:02AM +0800, Ming Lei wrote: > > On Thu, Aug 22, 2019 at 8:06 AM Christoph Hellwig <hch@infradead.org> wrote: > > > > > > On Wed, Aug 21, 2019 at 06:38:20PM +1000, Dave Chinner wrote: > > > > From: Dave Chinner <dchinner@redhat.com> > > > > > > > > Add memory buffer alignment validation checks to bios built in XFS > > > > to catch bugs that will result in silent data corruption in block > > > > drivers that cannot handle unaligned memory buffers but don't > > > > validate the incoming buffer alignment is correct. > > > > > > > > Known drivers with these issues are xenblk, brd and pmem. > > > > > > > > Despite there being nothing XFS specific to xfs_bio_add_page(), this > > > > function was created to do the required validation because the block > > > > layer developers that keep telling us that is not possible to > > > > validate buffer alignment in bio_add_page(), and even if it was > > > > possible it would be too much overhead to do at runtime. > > > > > > I really don't think we should life this to XFS, but instead fix it > > > in the block layer. And that is not only because I have a pending > > > series lifting bits you are touching to the block layer.. > > > > > > > +int > > > > +xfs_bio_add_page( > > > > + struct bio *bio, > > > > + struct page *page, > > > > + unsigned int len, > > > > + unsigned int offset) > > > > +{ > > > > + struct request_queue *q = bio->bi_disk->queue; > > > > + bool same_page = false; > > > > + > > > > + if (WARN_ON_ONCE(!blk_rq_aligned(q, len, offset))) > > > > + return -EIO; > > > > + > > > > + if (!__bio_try_merge_page(bio, page, len, offset, &same_page)) { > > > > + if (bio_full(bio, len)) > > > > + return 0; > > > > + __bio_add_page(bio, page, len, offset); > > > > + } > > > > + return len; > > > > > > I know Jens disagree, but with the amount of bugs we've been hitting > > > thangs to slub (and I'm pretty sure we have a more hiding outside of > > > XFS) I think we need to add the blk_rq_aligned check to bio_add_page. > > > > It isn't correct to blk_rq_aligned() here because 'len' has to be logical block > > size aligned, instead of DMA aligned only. > > News to me. > > AFAIA, the overall _IO_ that is being built needs to be a multiple > of the logical block size in total size (i.e. bio->bi_iter.size) Right. > because sub sector IO is not allowed. But queue DMA limits are not > defined in sectors - they define the scatter/gather DMA capability > of the hardware, and that's what individual segments (bvecs) need to > align to. That's what blk_rq_aligned() checks here - that the bvec Segment isn't same with bvec. We build segment via scatterlist interface from bvecs in case that driver needs segment for DMA between CPU and HBA. The built segment has to respect every kinds of queue limits. Now there are two kinds of bio, one is called fs bio, the other one is bio for doing IO from/to the device. Block layer splits fs bio into bios with proper size for doing IO. If one bvec is added with un-aligned length to fs bio, and if this bvec can't be merged with the following ones, how can block layer handle that? For example, this bvec is un-aligned with virt boundary, then one single bio is allocated for doing IO of this bvec, then sub-sector IO is generated. > segment aligns to what the underlying driver(s) requires, not that > the entire IO is sector sized and aligned. Not every drivers need to handle segment, some drivers simply handle single-page bvec(pmem, brd, zram, ...) or multi-page bvec(loop). Then un-aligned bvec may cause trouble for drivers which single-page bvec. > > Also, think about multipage bvecs - the pages we are spanning here > are contiguous pages, so this should end up merging them and turning > it into a single multipage bvec whose length is sector size > aligned... This way works for drivers which use segment, and most of drivers belong to this type. > > > Also not sure all users may setup bio->bi_disk well before adding page to bio, > > since it is allowed to do that now. > > XFS does, so I just don't care about random users of bio_add_page() > in this patch. Somebody else can run the block layer gauntlet to get > these checks moved into generic code and they've already been > rejected twice as unnecessary. If the check is to be added on bio_add_page(), every users have to be audited. > > > If slub buffer crosses two pages, block layer may not handle it at all > > even though > > un-aligned 'offset' issue is solved. > > A slub buffer crossing two _contiguous_ pages should end up merged > as a multipage bvec. But I'm curious, what does adding multiple > contiguous pages to a bio actually break? Some drivers don't or can't handle multi-page bvec, we have to split it into single-page bvec, then un-aligned bvec is seen by this drivers. thanks, Ming ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] xfs: alignment check bio buffers 2019-08-22 4:49 ` Dave Chinner 2019-08-22 7:23 ` Ming Lei @ 2019-08-22 8:08 ` Christoph Hellwig 2019-08-22 10:20 ` Ming Lei 1 sibling, 1 reply; 11+ messages in thread From: Christoph Hellwig @ 2019-08-22 8:08 UTC (permalink / raw) To: Dave Chinner Cc: Ming Lei, Christoph Hellwig, open list:XFS FILESYSTEM, Jens Axboe, linux-block On Thu, Aug 22, 2019 at 02:49:05PM +1000, Dave Chinner wrote: > On Thu, Aug 22, 2019 at 10:50:02AM +0800, Ming Lei wrote: > > It isn't correct to blk_rq_aligned() here because 'len' has to be logical block > > size aligned, instead of DMA aligned only. Even if len would have to be a multiple of the sector size, that doesn't mean calling blk_rq_aligned would be incorrect, just possibly not catching all issues. But as Dave outlined I don't think it is a problem in any way. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] xfs: alignment check bio buffers 2019-08-22 8:08 ` Christoph Hellwig @ 2019-08-22 10:20 ` Ming Lei 2019-08-23 0:14 ` Christoph Hellwig 0 siblings, 1 reply; 11+ messages in thread From: Ming Lei @ 2019-08-22 10:20 UTC (permalink / raw) To: Christoph Hellwig Cc: Dave Chinner, Ming Lei, open list:XFS FILESYSTEM, Jens Axboe, linux-block On Thu, Aug 22, 2019 at 01:08:52AM -0700, Christoph Hellwig wrote: > On Thu, Aug 22, 2019 at 02:49:05PM +1000, Dave Chinner wrote: > > On Thu, Aug 22, 2019 at 10:50:02AM +0800, Ming Lei wrote: > > > It isn't correct to blk_rq_aligned() here because 'len' has to be logical block > > > size aligned, instead of DMA aligned only. > > Even if len would have to be a multiple of the sector size, that doesn't > mean calling blk_rq_aligned would be incorrect, just possibly not > catching all issues. In theory, fs bio shouldn't care any DMA limits, which should have been done on splitted bio for doing IO to device. Also .dma_alignment isn't considered in blk_stack_limits(), so in case of DM, MD or other stacking drivers, fs code won't know the accurate .dma_alignment of underlying queues at all, and the stacking driver's queue dma alignment is still 512. Also suppose the check is added, I am a bit curious how fs code handles the failure, so could you explain a bit about the failure handling? Thanks, Ming ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] xfs: alignment check bio buffers 2019-08-22 10:20 ` Ming Lei @ 2019-08-23 0:14 ` Christoph Hellwig 2019-08-23 1:19 ` Ming Lei 0 siblings, 1 reply; 11+ messages in thread From: Christoph Hellwig @ 2019-08-23 0:14 UTC (permalink / raw) To: Ming Lei Cc: Christoph Hellwig, Dave Chinner, Ming Lei, open list:XFS FILESYSTEM, Jens Axboe, linux-block On Thu, Aug 22, 2019 at 06:20:00PM +0800, Ming Lei wrote: > In theory, fs bio shouldn't care any DMA limits, which should have been done > on splitted bio for doing IO to device. > > Also .dma_alignment isn't considered in blk_stack_limits(), so in case > of DM, MD or other stacking drivers, fs code won't know the accurate > .dma_alignment of underlying queues at all, and the stacking driver's > queue dma alignment is still 512. Trying to handling alignment lower down means bounce buffering, so I don't think trying to hndle it is a sane idea. I'd be much happier to say non-passthrough bios need 512 byte alignment, period. That should cover all the sane cases and we can easily check for it. The occasional device that would need larger alignment just needs to deal with it. > Also suppose the check is added, I am a bit curious how fs code handles the > failure, so could you explain a bit about the failure handling? Even just an assert is a a start. But a bio_add_page variant with saner return value semantic would be helpful, and I have some ideas there that I need to try out first. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 3/3] xfs: alignment check bio buffers 2019-08-23 0:14 ` Christoph Hellwig @ 2019-08-23 1:19 ` Ming Lei 0 siblings, 0 replies; 11+ messages in thread From: Ming Lei @ 2019-08-23 1:19 UTC (permalink / raw) To: Christoph Hellwig Cc: Dave Chinner, Ming Lei, open list:XFS FILESYSTEM, Jens Axboe, linux-block On Thu, Aug 22, 2019 at 05:14:40PM -0700, Christoph Hellwig wrote: > On Thu, Aug 22, 2019 at 06:20:00PM +0800, Ming Lei wrote: > > In theory, fs bio shouldn't care any DMA limits, which should have been done > > on splitted bio for doing IO to device. > > > > Also .dma_alignment isn't considered in blk_stack_limits(), so in case > > of DM, MD or other stacking drivers, fs code won't know the accurate > > .dma_alignment of underlying queues at all, and the stacking driver's > > queue dma alignment is still 512. > > Trying to handling alignment lower down means bounce buffering, so I > don't think trying to hndle it is a sane idea. I'd be much happier to > say non-passthrough bios need 512 byte alignment, period. That should > cover all the sane cases and we can easily check for it. The occasional > device that would need larger alignment just needs to deal with it. Yeah, I agree we need to avoid bounce buffer, and it is fine to check 512 simply. Also we should consider the interface/protocol between fs and block layer, it could make both sides happy to always align offset & length with logical block size. And that is reasonable for fs bio. Thanks, Ming ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-08-23 1:19 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20190821083820.11725-1-david@fromorbit.com> [not found] ` <20190821083820.11725-4-david@fromorbit.com> 2019-08-21 23:29 ` [PATCH 3/3] xfs: alignment check bio buffers Christoph Hellwig 2019-08-22 0:37 ` Dave Chinner 2019-08-22 8:03 ` Christoph Hellwig 2019-08-22 10:17 ` Dave Chinner 2019-08-22 2:50 ` Ming Lei 2019-08-22 4:49 ` Dave Chinner 2019-08-22 7:23 ` Ming Lei 2019-08-22 8:08 ` Christoph Hellwig 2019-08-22 10:20 ` Ming Lei 2019-08-23 0:14 ` Christoph Hellwig 2019-08-23 1:19 ` Ming Lei
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).