linux-kernel - Re: [PATCH v4] block: fix trace completion for chained bio

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YNR9I7zsCJ8s0Drh@infradead.org>
Date:   Thu, 24 Jun 2021 13:40:03 +0100
From:   Christoph Hellwig <hch@...radead.org>
To:     edwardh <edwardh@...ology.com>
Cc:     axboe@...nel.dk, neilb@...e.com, hch@...radead.org,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        s3t@...ology.com, bingjingc@...ology.com, cccheng@...ology.com,
        Wade Liang <wadel@...ology.com>
Subject: Re: [PATCH v4] block: fix trace completion for chained bio

On Thu, Jun 24, 2021 at 08:30:30PM +0800, edwardh wrote:
> From: Edward Hsieh <edwardh@...ology.com>
> 
> For chained bio, trace_block_bio_complete in bio_endio is currently called
> only by the parent bio once upon all chained bio completed.
> However, the sector and size for the parent bio are modified in bio_split.
> Therefore, the size and sector of the complete events might not match the
> queue events in blktrace.
> 
> The original fix of bio completion trace <fbbaf700e7b1> ("block: trace
> completion of all bios.") wants multiple complete events to correspond
> to one queue event but missed this.
> 
> The issue can be reproduced by md/raid5 read with bio cross chunks.
> 
> To fix, move trace completion into the loop for every chained bio to call.
> 
> Fixes: fbbaf700e7b1 ("block: trace completion of all bios.")
> Reviewed-by: Wade Liang <wadel@...ology.com>
> Reviewed-by: BingJing Chang <bingjingc@...ology.com>
> Signed-off-by: Edward Hsieh <edwardh@...ology.com>

Looks good,

Reviewed-by: Christoph Hellwig <hch@....de>