linux-kernel - Re: e827091cb1 "block: merge: get the 1st and last bvec via helpers" broken

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: <CACVXFVNuCDJ8V4-MNcaup=kbMFrAH1etLFpBHtFSJHj2OCWEBg@mail.gmail.com>
Date:	Sat, 12 Mar 2016 22:39:59 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Kent Overstreet <kent.overstreet@...il.com>
Cc:	Ming Lin <mlin@...nel.org>, Jens Axboe <axboe@...nel.dk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: e827091cb1 "block: merge: get the 1st and last bvec via helpers" broken

On Sat, Mar 12, 2016 at 10:36 PM, Kent Overstreet
<kent.overstreet@...il.com> wrote:
> On Sat, Mar 12, 2016 at 10:25:48PM +0800, Ming Lei wrote:
>> On Sat, 12 Mar 2016 05:02:56 -0900
>> Kent Overstreet <kent.overstreet@...il.com> wrote:
>>
>> > Here's the output of the patch below:
>> >
>> > generic/036 11s ...run fstests generic/036 at 2016-03-12 13:58:21
>> > end 4096 0 ffffea0001d611c0 end2 1024 0 ffffea0001d611c0
>> > len 1024 offset 0 page ffffea0001d611c0
>> > KGDB: Waiting for remote debugger
>> >
>> > Your code gives a biovec with bv_len of 4096, the old code gives a biovec with
>> > bv_len of 1024 (and then we dump every biovec, we see that the bio had only a
>> > single biovec that did indeed have bv_len == 1024).
>>
>> I guess we shouldn't have optimized for the case of non-cloned bio, could you
>> try the following patch?
>>
>> --
>> diff --git a/include/linux/bio.h b/include/linux/bio.h
>> index 1e7248f..4abc129 100644
>> --- a/include/linux/bio.h
>> +++ b/include/linux/bio.h
>> @@ -267,11 +267,6 @@ static inline void bio_get_last_bvec(struct bio *bio, struct bio_vec *bv)
>>       struct bvec_iter iter = bio->bi_iter;
>>       int idx;
>>
>> -     if (!bio_flagged(bio, BIO_CLONED)) {
>> -             *bv = bio->bi_io_vec[bio->bi_vcnt - 1];
>> -             return;
>> -     }
>> -
>>       if (unlikely(!bio_multiple_segments(bio))) {
>>               *bv = bio_iovec(bio);
>>               return;
>>
>> Thanks,
>> Ming
>
> Yes, that's it.
>
> !BIO_CLONED is _not_ a guarantee that bi_size doesn't straddle the middle of a
> bvec - bcachefs was hitting this by bouncing a bio that had already been split
> (which can happen elsewhere in the kernel...) but there's other (perfectly
> legal) ways it can happen.

Exactly!

>
> I would still strongly suggest reverting the patch for 4.5 and resubmitting
> during the next merge window.

I am fine with either way, and I will prepare one patch and let Jens
decide.


thanks,
Ming Lei