linux-kernel - Re: [PATCH] block: fix update first/last mergeable segment sizes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <x49pp2zumc1.fsf@segfault.boston.devel.redhat.com>
Date:	Fri, 07 Aug 2015 11:53:18 -0400
From:	Jeff Moyer <jmoyer@...hat.com>
To:	Wanpeng Li <wanpeng.li@...mail.com>
Cc:	Jens Axboe <axboe@...com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] block: fix update first/last mergeable segment sizes

Wanpeng Li <wanpeng.li@...mail.com> writes:

> To keep track of the max segment size, the sizes of the first and last 
> mergeable segments in the bio are accounted, prev->bio->bi_seg_front_size
> and next->biotail->bi_seg_back_size will be updated if blk_phys_contig_segment 
> is true, however, there are still some scenarios such like nonconsistent
> blk integrity which leads to merge fail, in addtion, futher merge fail is 
> incurred due to bio->bi_seg_back_size + next->bi_seg_front_size > 
> queue_max_segment_size(q) check in function blk_phys_contig_segment(). This 
> patch fix it by updating first/last mergeable segments size iff all the 
> conditions of merging are meet.

Does it matter?  Did you see any incorrect behaviour as a result of the
current code?

Cheers,
Jeff

>
> Signed-off-by: Wanpeng Li <wanpeng.li@...mail.com>
> ---
>  block/blk-merge.c | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 30a0d9f..7e7bda4 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -367,6 +367,7 @@ static int req_gap_to_prev(struct request *req, struct request *next)
>  static int ll_merge_requests_fn(struct request_queue *q, struct request *req,
>  				struct request *next)
>  {
> +	bool update_segment_size = false;
>  	int total_phys_segments;
>  	unsigned int seg_size =
>  		req->biotail->bi_seg_back_size + next->bio->bi_seg_front_size;
> @@ -391,10 +392,7 @@ static int ll_merge_requests_fn(struct request_queue *q, struct request *req,
>  
>  	total_phys_segments = req->nr_phys_segments + next->nr_phys_segments;
>  	if (blk_phys_contig_segment(q, req->biotail, next->bio)) {
> -		if (req->nr_phys_segments == 1)
> -			req->bio->bi_seg_front_size = seg_size;
> -		if (next->nr_phys_segments == 1)
> -			next->biotail->bi_seg_back_size = seg_size;
> +		update_segment_size = true;
>  		total_phys_segments--;
>  	}
>  
> @@ -405,6 +403,12 @@ static int ll_merge_requests_fn(struct request_queue *q, struct request *req,
>  		return 0;
>  
>  	/* Merge is OK... */
> +	if (update_segment_size) {
> +		if (req->nr_phys_segments == 1)
> +			req->bio->bi_seg_front_size = seg_size;
> +		if (next->nr_phys_segments == 1)
> +			next->biotail->bi_seg_back_size = seg_size;
> +	}
>  	req->nr_phys_segments = total_phys_segments;
>  	return 1;
>  }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/