linux-kernel - [PATCH v1 0/4] block: fix bio_will

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 19 Feb 2016 11:20:18 +0800
From:	Ming Lei <ming.lei@...onical.com>
To:	Jens Axboe <axboe@...nel.dk>, linux-kernel@...r.kernel.org
Cc:	linux-block@...r.kernel.org, Christoph Hellwig <hch@...radead.org>,
	Sagi Grimberg <sagig@....mellanox.co.il>,
	Kent Overstreet <kent.overstreet@...il.com>,
	Keith Busch <keith.busch@...el.com>,
	Elliott Robert <elliott@....com>
Subject: [PATCH v1 0/4] block: fix bio_will_gap()

Hi Guys,

The bio passed to bio_will_gap() may be fast cloned from upper
layer(dm, md, bcache, fs, ...), or from bio splitting in block
core. Unfortunately bio_will_gap() just figures out the last
bvec via 'bi_io_vec[prev->bi_vcnt - 1]' directly, and this way
is obviously wrong in case of fast-cloned bio.

It is observed that lots of BIOs are still merged even if
the virt boundary limit is violated by the merge, and the issue
was reported from Sagi Grimberg.

This patch introduces two helpers for getting the first and last
bvec of one bio and applys them to fix the issue. Sagi tested
the last patchset and confirmed the fix.

V1:
	- get bvec directly for non-cloned bio
	- implement bio_get_last_bvec() with single bio_advance_iter(),
	and avoid to use bio_for_each_segment() which looks a bit inefficient
	- avoid to double check queue_virt_boundary() in bio_will_gap()

 block/blk-merge.c      |  8 ++------
 include/linux/bio.h    | 41 +++++++++++++++++++++++++++++++++++++++++
 include/linux/blkdev.h | 21 ++++++++++++++++-----
 3 files changed, 59 insertions(+), 11 deletions(-)

Thanks,
Ming