Re: [PATCH 37/45] drivers: use req op accessor
On 08/03/2016 07:30 PM, Shaun Tancheff wrote: > On Wed, Aug 3, 2016 at 6:47 PM, Mike Christie <mchri...@redhat.com> wrote: >> On 08/03/2016 05:33 PM, Ross Zwisler wrote: >>> On Sun, Jun 5, 2016 at 1:32 PM, <mchri...@redhat.com> wrote: >>>> From: Mike Christie <mchri...@redhat.com> >>>> >>>> The req operation REQ_OP is separated from the rq_flag_bits >>>> definition. This converts the block layer drivers to >>>> use req_op to get the op from the request struct. >>>> >>>> Signed-off-by: Mike Christie <mchri...@redhat.com> >>>> --- >>>> drivers/block/loop.c | 6 +++--- >>>> drivers/block/mtip32xx/mtip32xx.c | 2 +- >>>> drivers/block/nbd.c | 2 +- >>>> drivers/block/rbd.c | 4 ++-- >>>> drivers/block/xen-blkfront.c | 8 +--- >>>> drivers/ide/ide-floppy.c | 2 +- >>>> drivers/md/dm.c | 2 +- >>>> drivers/mmc/card/block.c | 7 +++ >>>> drivers/mmc/card/queue.c | 6 ++ >>> >>> Dave Chinner reported a deadlock with XFS + DAX, which I reproduced >>> and bisected to this commit: >>> >>> commit c2df40dfb8c015211ec55f4b1dd0587f875c7b34 >>> Author: Mike Christie <mchri...@redhat.com> >>> Date: Sun Jun 5 14:32:17 2016 -0500 >>> drivers: use req op accessor >>> >>> Here are the steps to reproduce the deadlock with a BRD ramdisk: >>> >>> mkfs.xfs -f /dev/ram0 >>> mount -o dax /dev/ram0 /mnt/scratch >> >> When using ramdisks, we need the attached patch like in your other bug >> report. I think it will fix some hangs people are seeing. >> >> I do not think that it should cause the failure to run issue you saw >> when doing generic/008 and ext2. >> > > I think the translation in loop.c is suspicious here: > > "if use DIO && not (a flush_flag or discard_flag)" > should translate to: > "if use DIO && not ((a flush_flag) || op == discard)" > > But in the patch I read: > "if use DIO && ((not a flush_flag) || op == discard) > > Which would have DIO && discards follow the AIO path? > > So I would humbly suggest something like the following > (on top of commit c2df40dfb8c015211ec55f4b1dd0587f875c7b34): > [Please excuse the messed up patch format ... gmail eats tabs] > > diff --git a/drivers/block/loop.c b/drivers/block/loop.c > index b9b737c..0754d83 100644 > --- a/drivers/block/loop.c > +++ b/drivers/block/loop.c > @@ -1659,8 +1659,9 @@ static int loop_queue_rq(struct blk_mq_hw_ctx *hctx, > if (lo->lo_state != Lo_bound) > return -EIO; > > - if (lo->use_dio && (!(cmd->rq->cmd_flags & REQ_FLUSH) || > - req_op(cmd->rq) == REQ_OP_DISCARD)) > + if (lo->use_dio && !( > + (cmd->rq->cmd_flags & REQ_FLUSH) || > +req_op(cmd->rq) == REQ_OP_DISCARD)) > cmd->use_aio = true; > else > cmd->use_aio = false; > You are right. The translation was bad and your code above is correct. I think we need my patch in the other mail though too, because for the rw_page user case if WB_SYNC_ALL is set, then the IO gets sent down as a read instead of a write. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 37/45] drivers: use req op accessor
On 08/03/2016 05:33 PM, Ross Zwisler wrote:
> On Sun, Jun 5, 2016 at 1:32 PM, <mchri...@redhat.com> wrote:
>> From: Mike Christie <mchri...@redhat.com>
>>
>> The req operation REQ_OP is separated from the rq_flag_bits
>> definition. This converts the block layer drivers to
>> use req_op to get the op from the request struct.
>>
>> Signed-off-by: Mike Christie <mchri...@redhat.com>
>> ---
>> drivers/block/loop.c | 6 +++---
>> drivers/block/mtip32xx/mtip32xx.c | 2 +-
>> drivers/block/nbd.c | 2 +-
>> drivers/block/rbd.c | 4 ++--
>> drivers/block/xen-blkfront.c | 8 +---
>> drivers/ide/ide-floppy.c | 2 +-
>> drivers/md/dm.c | 2 +-
>> drivers/mmc/card/block.c | 7 +++
>> drivers/mmc/card/queue.c | 6 ++
>
> Dave Chinner reported a deadlock with XFS + DAX, which I reproduced
> and bisected to this commit:
>
> commit c2df40dfb8c015211ec55f4b1dd0587f875c7b34
> Author: Mike Christie <mchri...@redhat.com>
> Date: Sun Jun 5 14:32:17 2016 -0500
> drivers: use req op accessor
>
> Here are the steps to reproduce the deadlock with a BRD ramdisk:
>
> mkfs.xfs -f /dev/ram0
> mount -o dax /dev/ram0 /mnt/scratch
When using ramdisks, we need the attached patch like in your other bug
report. I think it will fix some hangs people are seeing.
I do not think that it should cause the failure to run issue you saw
when doing generic/008 and ext2.
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index 3022dad..9fbbeba 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -300,20 +300,20 @@ static void copy_from_brd(void *dst, struct brd_device *brd,
* Process a single bvec of a bio.
*/
static int brd_do_bvec(struct brd_device *brd, struct page *page,
- unsigned int len, unsigned int off, int rw,
+ unsigned int len, unsigned int off, int op,
sector_t sector)
{
void *mem;
int err = 0;
- if (rw != READ) {
+ if (op_is_write(op)) {
err = copy_to_brd_setup(brd, sector, len);
if (err)
goto out;
}
mem = kmap_atomic(page);
- if (rw == READ) {
+ if (!op_is_write(op)) {
copy_from_brd(mem + off, brd, sector, len);
flush_dcache_page(page);
} else {
@@ -330,7 +330,6 @@ static blk_qc_t brd_make_request(struct request_queue *q, struct bio *bio)
{
struct block_device *bdev = bio->bi_bdev;
struct brd_device *brd = bdev->bd_disk->private_data;
- int rw;
struct bio_vec bvec;
sector_t sector;
struct bvec_iter iter;
@@ -347,14 +346,12 @@ static blk_qc_t brd_make_request(struct request_queue *q, struct bio *bio)
goto out;
}
- rw = bio_data_dir(bio);
-
bio_for_each_segment(bvec, bio, iter) {
unsigned int len = bvec.bv_len;
int err;
err = brd_do_bvec(brd, bvec.bv_page, len,
- bvec.bv_offset, rw, sector);
+ bvec.bv_offset, bio_op(bio), sector);
if (err)
goto io_error;
sector += len >> SECTOR_SHIFT;
@@ -369,11 +366,11 @@ io_error:
}
static int brd_rw_page(struct block_device *bdev, sector_t sector,
- struct page *page, int rw)
+ struct page *page, int op, int op_flags)
{
struct brd_device *brd = bdev->bd_disk->private_data;
- int err = brd_do_bvec(brd, page, PAGE_SIZE, 0, rw, sector);
- page_endio(page, rw & WRITE, err);
+ int err = brd_do_bvec(brd, page, PAGE_SIZE, 0, op, sector);
+ page_endio(page, op, err);
return err;
}
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 7454cf1..f0e126c 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -843,15 +843,15 @@ static void zram_bio_discard(struct zram *zram, u32 index,
}
static int zram_bvec_rw(struct zram *zram, struct bio_vec *bvec, u32 index,
- int offset, int rw)
+ int offset, int op)
{
unsigned long start_time = jiffies;
int ret;
- generic_start_io_acct(rw, bvec->bv_len >> SECTOR_SHIFT,
+ generic_start_io_acct(op, bvec->bv_len >> SECTOR_SHIFT,
>disk->part0);
- if (rw == READ) {
+ if (!op_is_write(op)) {
atomic64_inc(>stats.num_reads);
ret = zram_bvec_read(zram, bvec, index, offset);
} else {
@@ -859,10 +859,10 @@ static int zram_bvec_rw(struct zram *zram, struct bio_vec *bvec, u32 index,
ret = zram_bvec_write(zram, bvec, index, offset);
}
- generic_end_io_acct(rw, >disk->part0, start_time);
+ generic_end_io_acct(op, >disk->part0, start_time);
if (unlikely(ret)) {
- if (rw == READ)
+ if (!op_is_write(op))
atomic64_inc(>stats.failed_reads);
else
atomic64_inc(>stats.failed_writes);
@@ -873,7 +873,7 @@ static int zram_bvec_rw(struct zram *zram, struct bio_vec *bvec, u32 index,
static void __zram_make_request(struct zram *zram, struct bio *bio)
{
- int offset, rw;
+ int offset;
u32 index;
struc
Re: [PATCH 42/45] block, fs, drivers: remove REQ_OP compat defs and related code
On 08/03/2016 11:25 AM, Ross Zwisler wrote: > run fstests generic/008 at 2016-08-03 09:54:56 > page:ea0017af04c0 count:3 mapcount:0 mapping:8805eb059200 index:0x0 > flags: 0x3fff802828(uptodate|lru|private|writeback) > page dumped because: VM_BUG_ON_PAGE(!PageLocked(page)) > page->mem_cgroup:8806098e0800 > [ cut here ] > kernel BUG at mm/filemap.c:833! > invalid opcode: [#1] SMP > Modules linked in: brd dax_pmem nd_pmem dax nd_btt nd_e820 libnvdimm > CPU: 0 PID: 2522 Comm: xfs_io Not tainted 4.7.0-rc2-00042-g4e1b2d52 #18 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014 > task: 8805ebae4ec0 ti: 8805eba3c000 task.ti: 8805eba3c000 > RIP: 0010:[] [] unlock_page+0xa5/0xb0 > RSP: 0018:8805eba3fa60 EFLAGS: 00010282 > RAX: 0021 RBX: RCX: 0006 > RDX: RSI: 0001 RDI: 8806109ce200 > RBP: 8805eba3fa60 R08: 0001 R09: 0001 > R10: 8805ebae4ec0 R11: 0001 R12: ea0017af04c0 > R13: 00028000 R14: a00202c0 R15: 88060eff1200 > FS: 7f87a31cf700() GS:88061080() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f87a31e6000 CR3: 00060da31000 CR4: 001406f0 > Stack: > 8805eba3fa98 812bd782 8805eba3fdb0 1000 > ea0017af04c0 0088 8805eba3fbe0 > 812c3ff1 8805eba3fd00 00028000 000c > Call Trace: > [] bdev_write_page+0xb2/0xe0 fs/block_dev.c:462 > [] __mpage_writepage+0x5c1/0x750 fs/mpage.c:604 > [] write_cache_pages+0x20d/0x5f0 mm/page-writeback.c:2261 > [] mpage_writepages+0x75/0xe0 fs/mpage.c:703 > [] ext2_writepages+0x3b/0x40 fs/ext2/inode.c:887 > [] do_writepages+0x21/0x30 mm/page-writeback.c:2361 > [] __filemap_fdatawrite_range+0xc6/0x100 mm/filemap.c:300 > [] filemap_write_and_wait_range+0x44/0x90 mm/filemap.c:490 > [] __generic_file_fsync+0x27/0x90 fs/libfs.c:937 > [] generic_file_fsync+0x19/0x40 fs/libfs.c:974 > [] ext2_fsync+0x2e/0x70 fs/ext2/file.c:149 > [] vfs_fsync_range+0x4b/0xb0 fs/sync.c:195 > [< inline >] vfs_fsync fs/sync.c:209 > [] do_fsync+0x3d/0x70 fs/sync.c:219 > [< inline >] SYSC_fsync fs/sync.c:227 > [] SyS_fsync+0x10/0x20 fs/sync.c:225 > [] entry_SYSCALL_64_fastpath+0x1f/0xbd > arch/x86/entry/entry_64.S:207 > Code: 00 00 48 d3 ea 89 d2 48 8d 0c 92 48 8d 14 4a 48 8d 3c d0 31 d2 > e8 bc fc f1 ff 5d c3 48 c7 c6 20 1d ec 81 4c 89 c7 e8 bb 8d 03 00 <0f> > 0b 66 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 b9 08 00 00 > RIP [] unlock_page+0xa5/0xb0 mm/filemap.c:833 > RSP > ---[ end trace d419bf59bba263fb ]--- Thanks for testing and the detailed bug report. Looks like I missed the rw_page callback. Testing a patch right now. Should be done in a couple of hours. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH next] Btrfs: fix comparison in __btrfs_map_block()
On 07/15/2016 10:03 AM, Vincent Stehlé wrote:
> Add missing comparison to op in expression, which was forgotten when doing
> the REQ_OP transition.
>
> Fixes: b3d3fa519905 ("btrfs: update __btrfs_map_block for REQ_OP transition")
> Signed-off-by: Vincent Stehlé <vincent.ste...@intel.com>
> Cc: Mike Christie <mchri...@redhat.com>
> Cc: Jens Axboe <ax...@fb.com>
> ---
>
>
> Hi,
>
> I saw that issue in linux next.
>
> Not sure if it is too late to squash the fix with commit b3d3fa519905 or
> not...
>
> Best regards,
>
> Vincent.
>
>
> fs/btrfs/volumes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index a69203a..6ee1e36 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -5533,7 +5533,7 @@ static int __btrfs_map_block(struct btrfs_fs_info
> *fs_info, int op,
> }
>
> } else if (map->type & BTRFS_BLOCK_GROUP_DUP) {
> - if (op == REQ_OP_WRITE || REQ_OP_DISCARD ||
> + if (op == REQ_OP_WRITE || op == REQ_OP_DISCARD ||
> op == REQ_GET_READ_MIRRORS) {
> num_stripes = map->num_stripes;
> } else if (mirror_num) {
>
Shoot. Dumb mistake by me. It is of course correct.
Reviewed-by: Mike Christie <mchri...@redhat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 28/45] target: use bio op accessors
On 06/06/2016 01:46 AM, Hannes Reinecke wrote:
> On 06/05/2016 09:32 PM, mchri...@redhat.com wrote:
>> From: Mike Christie <mchri...@redhat.com>
>>
>> Separate the op from the rq_flag_bits and have the target layer
>> set/get the bio using bio_set_op_attrs/bio_op.
>>
>> Signed-off-by: Mike Christie <mchri...@redhat.com>
>> ---
>> drivers/target/target_core_iblock.c | 29 ++---
>> drivers/target/target_core_pscsi.c | 2 +-
>> 2 files changed, 15 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/target/target_core_iblock.c
>> b/drivers/target/target_core_iblock.c
>> index c25109c..22af12f 100644
>> --- a/drivers/target/target_core_iblock.c
>> +++ b/drivers/target/target_core_iblock.c
> [ .. ]
>> @@ -689,18 +690,15 @@ iblock_execute_rw(struct se_cmd *cmd, struct
>> scatterlist *sgl, u32 sgl_nents,
>> * Force writethrough using WRITE_FUA if a volatile write cache
>> * is not enabled, or if initiator set the Force Unit Access
>> bit.
>> */
>> +op = REQ_OP_WRITE;
>> if (test_bit(QUEUE_FLAG_FUA, >queue_flags)) {
>> if (cmd->se_cmd_flags & SCF_FUA)
>> -rw = WRITE_FUA;
>> +op_flags = WRITE_FUA;
>> else if (!test_bit(QUEUE_FLAG_WC, >queue_flags))
>> -rw = WRITE_FUA;
>> -else
>> -rw = WRITE;
>> -} else {
>> -rw = WRITE;
>> +op_flags = WRITE_FUA;
>> }
> Wrong intendation.
It should be ok. That line is for the QUEUE_FLAG_WC test. We end up with:
op = REQ_OP_WRITE;
if (test_bit(QUEUE_FLAG_FUA, >queue_flags)) {
if (cmd->se_cmd_flags & SCF_FUA)
op_flags = WRITE_FUA;
else if (!test_bit(QUEUE_FLAG_WC, >queue_flags))
op_flags = WRITE_FUA;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs
On 05/04/2016 12:58 PM, Jeff Moyer wrote: > Mike Christie <mchri...@redhat.com> writes: > >> On 05/03/2016 03:44 PM, Jeff Moyer wrote: >>> Hi, Mike, >>> >>> That git tree doesn't seem to exist. I did manage to apply your patch >>> set on top of next-20160415, though. >>> >>> So... what testing did you do? ;-) I ran into the following problems >> >> I normally run xfstests and run it on my daily workstation and laptop. I >> did not do this for every FS this time and hit a regression. >> >> What FS were you using? > > I'm using xfs, scsi disk, no blk-mq, no dm. > >>> - git clone fails >>> - yum segfaults >> >> In v7/v6, I missed a new submit_bio call, so I hit issues like the two >> above. I have this fixed in the next version. > > OK, does this mean you're posting another version, or you already did > and I somehow missed it? > I did not repost yet. I am still testing. Jens had me add some wrappers around the operation access, so because of my last screw up and the wrapper change affected all my patches I am redoing all my testing. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs
On 05/03/2016 03:44 PM, Jeff Moyer wrote: > mchri...@redhat.com writes: > >> The following patches begin to cleanup the request->cmd_flags and >> bio->bi_rw mess. We currently use cmd_flags to specify the operation, >> attributes and state of the request. For bi_rw we use it for similar >> info and also the priority but then also have another bi_flags field >> for state. At some point, we abused them so much we just made cmd_flags >> 64 bits, so we could add more. >> >> The following patches seperate the operation (read, write discard, >> flush, etc) from cmd_flags/bi_rw. >> >> This patchset was made against linux-next from today April 15 >> (git tag next-20160415). >> >> I put a git tree here: >> https://github.com/mikechristie/linux-kernel.git >> The patches are in the op branch. > > Hi, Mike, > > That git tree doesn't seem to exist. I did manage to apply your patch > set on top of next-20160415, though. > > So... what testing did you do? ;-) I ran into the following problems I normally run xfstests and run it on my daily workstation and laptop. I did not do this for every FS this time and hit a regression. What FS were you using? > - git clone fails > - yum segfaults In v7/v6, I missed a new submit_bio call, so I hit issues like the two above. I have this fixed in the next version. > - many blktrace/blkparse issues, including incorrect cpu recorded in > traces, null task names, and blkparse outputting nothing for a trace > file several gigabytes in size. I will double check for these issues. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 41/42] block: do not use REQ_FLUSH for tracking flush support
On 04/15/2016 05:50 AM, Juergen Gross wrote:
> On 15/04/16 12:40, mchri...@redhat.com wrote:
>> From: Mike Christie <mchri...@redhat.com>
>>
>> The last patch added a REQ_OP_FLUSH for request_fn drivers
>> and the next patch renames REQ_FLUSH to REQ_PREFLUSH which
>> will be used by file systems and make_request_fn drivers so
>> they can send a write/flush combo.
>>
>> This patch drops xen's use of REQ_FLUSH to track if it supports
>> REQ_OP_FLUSH requests, so REQ_FLUSH can be deleted.
>>
>> v6:
>> - Dropped parts of patch handled by Jens's QUEUE_FLAG_WC/FUA
>> patches and modified patch to check feature_flush/fua bits.
>>
>> Signed-off-by: Mike Christie <mchri...@redhat.com>
>> Reviewed-by: Hannes Reinecke <h...@suse.com>
>> ---
>> drivers/block/xen-blkfront.c | 47
>> ++--
>> 1 file changed, 24 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>> index f01691a..d6429e7 100644
>> --- a/drivers/block/xen-blkfront.c
>> +++ b/drivers/block/xen-blkfront.c
>
> ...
>
>> @@ -985,24 +981,22 @@ static int xlvbd_init_blk_queue(struct gendisk *gd,
>> u16 sector_size,
>> return 0;
>> }
>>
>> -static const char *flush_info(unsigned int feature_flush)
>> +static const char *flush_info(struct blkfront_info *info)
>> {
>> -switch (feature_flush & ((REQ_FLUSH | REQ_FUA))) {
>> -case REQ_FLUSH|REQ_FUA:
>> +if (info->feature_flush && info->feature_fua)
>> return "barrier: enabled;";
>> -case REQ_FLUSH:
>> +else if (info->feature_fua)
>
> Shouldn't this test feature_flush?
>
>> return "flush diskcache: enabled;";
>> -default:
>> +else
>> return "barrier or flush: disabled;";
>> -}
>> }
>>
>> static void xlvbd_flush(struct blkfront_info *info)
>> {
>> -blk_queue_write_cache(info->rq, info->feature_flush & REQ_FLUSH,
>> -info->feature_flush & REQ_FUA);
>> +blk_queue_write_cache(info->rq, info->feature_flush ? true : false,
>> + info->feature_flush ? true : false);
>
> And here the second test should be feature_fua?
>
You are right. Will fix up and resend.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/35 v4] separate operations from flags in the bio/request structs
On 02/29/2016 11:13 AM, Christoph Hellwig wrote: > Any reason you've dropped my ACK for the previous version? Sorry. I think I accidentally dropped it when I rebased back over to linux-next. It looks like it only got stuck on the first patch. I will fix that up on the resend for those kbuild errors. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [dm-devel] [PATCH 4/9] block: Make generic_make_request handle arbitrary sized bios
On 11/04/2013 03:36 PM, Kent Overstreet wrote:
@@ -1822,6 +1820,14 @@ void generic_make_request(struct bio *bio)
*/
blk_queue_bounce(q, bio);
+ if (!blk_queue_largebios(q))
+ split = blk_bio_segment_split(q, bio, q-bio_split);
Is it assumed bios coming down this path are created using bio_add_page?
If not, does blk_bio_segment_split need a queue_max_sectors or
queue_max_hw_sectors check? I only saw a segment count check below.
+
+struct bio *blk_bio_segment_split(struct request_queue *q, struct bio *bio,
+ struct bio_set *bs)
+{
+ struct bio *split;
+ struct bio_vec bv, bvprv;
+ struct bvec_iter iter;
+ unsigned seg_size = 0, nsegs = 0;
+ int prev = 0;
+
+ struct bvec_merge_data bvm = {
+ .bi_bdev= bio-bi_bdev,
+ .bi_sector = bio-bi_iter.bi_sector,
+ .bi_size= 0,
+ .bi_rw = bio-bi_rw,
+ };
+
+ if (bio-bi_rw REQ_DISCARD)
+ return blk_bio_discard_split(q, bio, bs);
+
+ if (bio-bi_rw REQ_WRITE_SAME)
+ return blk_bio_write_same_split(q, bio, bs);
+
+ bio_for_each_segment(bv, bio, iter) {
+ if (q-merge_bvec_fn
+ q-merge_bvec_fn(q, bvm, bv) (int) bv.bv_len)
+ goto split;
+
+ bvm.bi_size += bv.bv_len;
+
+ if (prev blk_queue_cluster(q)) {
+ if (seg_size + bv.bv_len queue_max_segment_size(q))
+ goto new_segment;
+ if (!BIOVEC_PHYS_MERGEABLE(bvprv, bv))
+ goto new_segment;
+ if (!BIOVEC_SEG_BOUNDARY(q, bvprv, bv))
+ goto new_segment;
+
+ seg_size += bv.bv_len;
+ bvprv = bv;
+ prev = 1;
+ continue;
+ }
+new_segment:
+ if (nsegs == queue_max_segments(q))
+ goto split;
+
+ nsegs++;
+ bvprv = bv;
+ prev = 1;
+ seg_size = bv.bv_len;
+ }
+
+ return NULL;
+split:
+ split = bio_clone_bioset(bio, GFP_NOIO, bs);
+
+ split-bi_iter.bi_size -= iter.bi_size;
+ bio-bi_iter = iter;
+
+ if (bio_integrity(bio)) {
+ bio_integrity_advance(bio, split-bi_iter.bi_size);
+ bio_integrity_trim(split, 0, bio_sectors(split));
+ }
+
+ return split;
+}
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
