linux-kernel - Re: [PATCH 0/22] Immutable biovecs, block layer changes

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: <20130808211529.GB15409@kmo-pixel>
Date:	Thu, 8 Aug 2013 14:15:29 -0700
From:	Kent Overstreet <kmo@...erainc.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	axboe@...nel.dk, neilb@...e.de, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, dm-devel@...hat.com,
	linux-raid@...r.kernel.org
Subject: Re: [PATCH 0/22] Immutable biovecs, block layer changes

On Thu, Aug 08, 2013 at 08:09:54AM -0700, Christoph Hellwig wrote:
> On Wed, Aug 07, 2013 at 02:54:09PM -0700, Kent Overstreet wrote:
> > _However_, I have more patches (that depend on this patch series) to get
> > that back - segment merging improvements that get rid of
> > bi_seg_front_size, bi_seg_back_size, and bi_phys_segments. Once all that
> > is in it should be a net reduction to the size of struct bio.
> 
> What is preventing you from sending those out as well?  While it's not
> absolutely nessecary it would certainly be good if we'd avoid a struct
> bio size regression.

There's still some fairly significant changes, and I don't want to make
too many invasive changes at once.

Main thing is making generic_make_request() take arbitrary size bios.
After this series that's just two simple patches, but then the changes
to make use of that will be changing behaviour in non obvious ways.

The way the merging changes work is it enables multi page bvecs - so a
bvec can point to many physically contiguous pages. This moves segment
merging to bio_add_page(), and gets rid of bi_phys_segments - now
bi_vcnt == bi_phys_segments, we just split the bio if it's too big.

Then, with bio_add_page() building up large bios and the block layer
splitting them as necessary, there shouldn't be any need for segment
merging across bios anymore (because generally when that would've
happened before, now we'd just be sending one larger bio down).

The remaining patches aren't terribly complicated though (less
complicated than this patch series). Trickiest bit is multipage bvecs,
and that's mostly just lots of code auditing - the way I convert
existing code is by adding bio_for_each_page() - analagous to
bio_for_each_segment, but giving you bvecs that point to single pages.
So it's an easy conversion, just have to make sure nothing's missed.
--
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/