linux-toradex.git/fs/direct-io.c, branch v4.5 Linux kernel for Apalis and Colibri modules block: fix use-after-free in dio_bio_complete 2016-01-31T05:02:10+00:00 Mike Krinkin krinkin.m.u@gmail.com 2016-01-30T16:09:59+00:00 7ddc971f86aa0a4cee9f6886c356a052461957ae kasan reported the following error when i ran xfstest: [ 701.826854] ================================================================== [ 701.826864] BUG: KASAN: use-after-free in dio_bio_complete+0x41a/0x600 at addr ffff880080b95f94 [ 701.826870] Read of size 4 by task loop2/3874 [ 701.826879] page:ffffea000202e540 count:0 mapcount:0 mapping: (null) index:0x0 [ 701.826890] flags: 0x100000000000000() [ 701.826895] page dumped because: kasan: bad access detected [ 701.826904] CPU: 3 PID: 3874 Comm: loop2 Tainted: G B W L 4.5.0-rc1-next-20160129 #83 [ 701.826910] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013 [ 701.826917] ffff88008fadf800 ffff88008fadf758 ffffffff81ca67bb 0000000041b58ab3 [ 701.826941] ffffffff830d1e74 ffffffff81ca6724 ffff88008fadf748 ffffffff8161c05c [ 701.826963] 0000000000000282 ffff88008fadf800 ffffed0010172bf2 ffffea000202e540 [ 701.826987] Call Trace: [ 701.826997] [<ffffffff81ca67bb>] dump_stack+0x97/0xdc [ 701.827005] [<ffffffff81ca6724>] ? _atomic_dec_and_lock+0xc4/0xc4 [ 701.827014] [<ffffffff8161c05c>] ? __dump_page+0x32c/0x490 [ 701.827023] [<ffffffff816b0d03>] kasan_report_error+0x5f3/0x8b0 [ 701.827033] [<ffffffff817c302a>] ? dio_bio_complete+0x41a/0x600 [ 701.827040] [<ffffffff816b1119>] __asan_report_load4_noabort+0x59/0x80 [ 701.827048] [<ffffffff817c302a>] ? dio_bio_complete+0x41a/0x600 [ 701.827053] [<ffffffff817c302a>] dio_bio_complete+0x41a/0x600 [ 701.827057] [<ffffffff81bd19c8>] ? blk_queue_exit+0x108/0x270 [ 701.827060] [<ffffffff817c32b0>] dio_bio_end_aio+0xa0/0x4d0 [ 701.827063] [<ffffffff817c3210>] ? dio_bio_complete+0x600/0x600 [ 701.827067] [<ffffffff81bd2806>] ? blk_account_io_completion+0x316/0x5d0 [ 701.827070] [<ffffffff81bafe89>] bio_endio+0x79/0x200 [ 701.827074] [<ffffffff81bd2c9f>] blk_update_request+0x1df/0xc50 [ 701.827078] [<ffffffff81c02c27>] blk_mq_end_request+0x57/0x120 [ 701.827081] [<ffffffff81c03670>] __blk_mq_complete_request+0x310/0x590 [ 701.827084] [<ffffffff812348d8>] ? set_next_entity+0x2f8/0x2ed0 [ 701.827088] [<ffffffff8124b34d>] ? put_prev_entity+0x22d/0x2a70 [ 701.827091] [<ffffffff81c0394b>] blk_mq_complete_request+0x5b/0x80 [ 701.827094] [<ffffffff821e2a33>] loop_queue_work+0x273/0x19d0 [ 701.827098] [<ffffffff811f6578>] ? finish_task_switch+0x1c8/0x8e0 [ 701.827101] [<ffffffff8129d058>] ? trace_hardirqs_on_caller+0x18/0x6c0 [ 701.827104] [<ffffffff821e27c0>] ? lo_read_simple+0x890/0x890 [ 701.827108] [<ffffffff8129dd60>] ? debug_check_no_locks_freed+0x350/0x350 [ 701.827111] [<ffffffff811f63b0>] ? __hrtick_start+0x130/0x130 [ 701.827115] [<ffffffff82a0c8f6>] ? __schedule+0x936/0x20b0 [ 701.827118] [<ffffffff811dd6bd>] ? kthread_worker_fn+0x3ed/0x8d0 [ 701.827121] [<ffffffff811dd4ed>] ? kthread_worker_fn+0x21d/0x8d0 [ 701.827125] [<ffffffff8129d058>] ? trace_hardirqs_on_caller+0x18/0x6c0 [ 701.827128] [<ffffffff811dd57f>] kthread_worker_fn+0x2af/0x8d0 [ 701.827132] [<ffffffff811dd2d0>] ? __init_kthread_worker+0x170/0x170 [ 701.827135] [<ffffffff82a1ea46>] ? _raw_spin_unlock_irqrestore+0x36/0x60 [ 701.827138] [<ffffffff811dd2d0>] ? __init_kthread_worker+0x170/0x170 [ 701.827141] [<ffffffff811dd2d0>] ? __init_kthread_worker+0x170/0x170 [ 701.827144] [<ffffffff811dd00b>] kthread+0x24b/0x3a0 [ 701.827148] [<ffffffff811dcdc0>] ? kthread_create_on_node+0x4c0/0x4c0 [ 701.827151] [<ffffffff8129d70d>] ? trace_hardirqs_on+0xd/0x10 [ 701.827155] [<ffffffff8116d41d>] ? do_group_exit+0xdd/0x350 [ 701.827158] [<ffffffff811dcdc0>] ? kthread_create_on_node+0x4c0/0x4c0 [ 701.827161] [<ffffffff82a1f52f>] ret_from_fork+0x3f/0x70 [ 701.827165] [<ffffffff811dcdc0>] ? kthread_create_on_node+0x4c0/0x4c0 [ 701.827167] Memory state around the buggy address: [ 701.827170] ffff880080b95e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 701.827172] ffff880080b95f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 701.827175] >ffff880080b95f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 701.827177] ^ [ 701.827179] ffff880080b96000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 701.827182] ffff880080b96080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 701.827183] ================================================================== The problem is that bio_check_pages_dirty calls bio_put, so we must not access bio fields after bio_check_pages_dirty. Fixes: 9b81c842355ac96097ba ("block: don't access bio->bi_error after bio_put()"). Signed-off-by: Mike Krinkin <krinkin.m.u@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe <axboe@fb.com> 
kasan reported the following error when i ran xfstest:

[  701.826854] ==================================================================
[  701.826864] BUG: KASAN: use-after-free in dio_bio_complete+0x41a/0x600 at addr ffff880080b95f94
[  701.826870] Read of size 4 by task loop2/3874
[  701.826879] page:ffffea000202e540 count:0 mapcount:0 mapping:          (null) index:0x0
[  701.826890] flags: 0x100000000000000()
[  701.826895] page dumped because: kasan: bad access detected
[  701.826904] CPU: 3 PID: 3874 Comm: loop2 Tainted: G    B   W    L  4.5.0-rc1-next-20160129 #83
[  701.826910] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
[  701.826917]  ffff88008fadf800 ffff88008fadf758 ffffffff81ca67bb 0000000041b58ab3
[  701.826941]  ffffffff830d1e74 ffffffff81ca6724 ffff88008fadf748 ffffffff8161c05c
[  701.826963]  0000000000000282 ffff88008fadf800 ffffed0010172bf2 ffffea000202e540
[  701.826987] Call Trace:
[  701.826997]  [<ffffffff81ca67bb>] dump_stack+0x97/0xdc
[  701.827005]  [<ffffffff81ca6724>] ? _atomic_dec_and_lock+0xc4/0xc4
[  701.827014]  [<ffffffff8161c05c>] ? __dump_page+0x32c/0x490
[  701.827023]  [<ffffffff816b0d03>] kasan_report_error+0x5f3/0x8b0
[  701.827033]  [<ffffffff817c302a>] ? dio_bio_complete+0x41a/0x600
[  701.827040]  [<ffffffff816b1119>] __asan_report_load4_noabort+0x59/0x80
[  701.827048]  [<ffffffff817c302a>] ? dio_bio_complete+0x41a/0x600
[  701.827053]  [<ffffffff817c302a>] dio_bio_complete+0x41a/0x600
[  701.827057]  [<ffffffff81bd19c8>] ? blk_queue_exit+0x108/0x270
[  701.827060]  [<ffffffff817c32b0>] dio_bio_end_aio+0xa0/0x4d0
[  701.827063]  [<ffffffff817c3210>] ? dio_bio_complete+0x600/0x600
[  701.827067]  [<ffffffff81bd2806>] ? blk_account_io_completion+0x316/0x5d0
[  701.827070]  [<ffffffff81bafe89>] bio_endio+0x79/0x200
[  701.827074]  [<ffffffff81bd2c9f>] blk_update_request+0x1df/0xc50
[  701.827078]  [<ffffffff81c02c27>] blk_mq_end_request+0x57/0x120
[  701.827081]  [<ffffffff81c03670>] __blk_mq_complete_request+0x310/0x590
[  701.827084]  [<ffffffff812348d8>] ? set_next_entity+0x2f8/0x2ed0
[  701.827088]  [<ffffffff8124b34d>] ? put_prev_entity+0x22d/0x2a70
[  701.827091]  [<ffffffff81c0394b>] blk_mq_complete_request+0x5b/0x80
[  701.827094]  [<ffffffff821e2a33>] loop_queue_work+0x273/0x19d0
[  701.827098]  [<ffffffff811f6578>] ? finish_task_switch+0x1c8/0x8e0
[  701.827101]  [<ffffffff8129d058>] ? trace_hardirqs_on_caller+0x18/0x6c0
[  701.827104]  [<ffffffff821e27c0>] ? lo_read_simple+0x890/0x890
[  701.827108]  [<ffffffff8129dd60>] ? debug_check_no_locks_freed+0x350/0x350
[  701.827111]  [<ffffffff811f63b0>] ? __hrtick_start+0x130/0x130
[  701.827115]  [<ffffffff82a0c8f6>] ? __schedule+0x936/0x20b0
[  701.827118]  [<ffffffff811dd6bd>] ? kthread_worker_fn+0x3ed/0x8d0
[  701.827121]  [<ffffffff811dd4ed>] ? kthread_worker_fn+0x21d/0x8d0
[  701.827125]  [<ffffffff8129d058>] ? trace_hardirqs_on_caller+0x18/0x6c0
[  701.827128]  [<ffffffff811dd57f>] kthread_worker_fn+0x2af/0x8d0
[  701.827132]  [<ffffffff811dd2d0>] ? __init_kthread_worker+0x170/0x170
[  701.827135]  [<ffffffff82a1ea46>] ? _raw_spin_unlock_irqrestore+0x36/0x60
[  701.827138]  [<ffffffff811dd2d0>] ? __init_kthread_worker+0x170/0x170
[  701.827141]  [<ffffffff811dd2d0>] ? __init_kthread_worker+0x170/0x170
[  701.827144]  [<ffffffff811dd00b>] kthread+0x24b/0x3a0
[  701.827148]  [<ffffffff811dcdc0>] ? kthread_create_on_node+0x4c0/0x4c0
[  701.827151]  [<ffffffff8129d70d>] ? trace_hardirqs_on+0xd/0x10
[  701.827155]  [<ffffffff8116d41d>] ? do_group_exit+0xdd/0x350
[  701.827158]  [<ffffffff811dcdc0>] ? kthread_create_on_node+0x4c0/0x4c0
[  701.827161]  [<ffffffff82a1f52f>] ret_from_fork+0x3f/0x70
[  701.827165]  [<ffffffff811dcdc0>] ? kthread_create_on_node+0x4c0/0x4c0
[  701.827167] Memory state around the buggy address:
[  701.827170]  ffff880080b95e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827172]  ffff880080b95f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827175] >ffff880080b95f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827177]                          ^
[  701.827179]  ffff880080b96000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827182]  ffff880080b96080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827183] ==================================================================

The problem is that bio_check_pages_dirty calls bio_put, so we must
not access bio fields after bio_check_pages_dirty.

Fixes: 9b81c842355ac96097ba ("block: don't access bio->bi_error after bio_put()").
Signed-off-by: Mike Krinkin <krinkin.m.u@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@fb.com>
wrappers for ->i_mutex access 2016-01-22T23:04:28+00:00 Al Viro viro@zeniv.linux.org.uk 2016-01-22T20:40:57+00:00 5955102c9984fa081b2d570cfac75c97eecf8f3b parallel to mutex_{lock,unlock,trylock,is_locked,lock_nested}, inode_foo(inode) being mutex_foo(&inode->i_mutex). Please, use those for access to ->i_mutex; over the coming cycle ->i_mutex will become rwsem, with ->lookup() done with it held only shared. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
parallel to mutex_{lock,unlock,trylock,is_locked,lock_nested},
inode_foo(inode) being mutex_foo(&inode->i_mutex).

Please, use those for access to ->i_mutex; over the coming cycle
->i_mutex will become rwsem, with ->lookup() done with it held
only shared.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
fix the regression from "direct-io: Fix negative return from dio read beyond eof" 2015-12-08T20:02:42+00:00 Al Viro viro@zeniv.linux.org.uk 2015-12-08T17:22:47+00:00 2d4594acbf6d8f75a27f3578476b6a27d8b13ebb Sure, it's better to bail out of past-the-eof read and return 0 than return a bogus negative value on such. Only we'd better make sure we are bailing out with 0 and not -ENOMEM... Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 
Sure, it's better to bail out of past-the-eof read and return 0 than return
a bogus negative value on such.  Only we'd better make sure we are bailing out
with 0 and not -ENOMEM...

Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
direct-io: Fix negative return from dio read beyond eof 2015-11-30T17:15:42+00:00 Jan Kara jack@suse.cz 2015-11-30T17:15:42+00:00 74cedf9b6c603f2278a05bc91b140b32b434d0b5 Assume a filesystem with 4KB blocks. When a file has size 1000 bytes and we issue direct IO read at offset 1024, blockdev_direct_IO() reads the tail of the last block and the logic for handling short DIO reads in dio_complete() results in a return value -24 (1000 - 1024) which obviously confuses userspace. Fix the problem by bailing out early once we sample i_size and can reliably check that direct IO read starts beyond i_size. Reported-by: Avi Kivity <avi@scylladb.com> Fixes: 9fe55eea7e4b444bafc42fa0000cc2d1d2847275 CC: stable@vger.kernel.org CC: Steven Whitehouse <swhiteho@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Jens Axboe <axboe@fb.com> 
Assume a filesystem with 4KB blocks. When a file has size 1000 bytes and
we issue direct IO read at offset 1024, blockdev_direct_IO() reads the
tail of the last block and the logic for handling short DIO reads in
dio_complete() results in a return value -24 (1000 - 1024) which
obviously confuses userspace.

Fix the problem by bailing out early once we sample i_size and can
reliably check that direct IO read starts beyond i_size.

Reported-by: Avi Kivity <avi@scylladb.com>
Fixes: 9fe55eea7e4b444bafc42fa0000cc2d1d2847275
CC: stable@vger.kernel.org
CC: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@fb.com>
Merge branch 'for-4.4/io-poll' of git://git.kernel.dk/linux-block 2015-11-11T01:23:49+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-11-11T01:23:49+00:00 3419b45039c6b799c974a8019361c045e7ca232c Pull block IO poll support from Jens Axboe: "Various groups have been doing experimentation around IO polling for (really) fast devices. The code has been reviewed and has been sitting on the side for a few releases, but this is now good enough for coordinated benchmarking and further experimentation. Currently O_DIRECT sync read/write are supported. A framework is in the works that allows scalable stats tracking so we can auto-tune this. And we'll add libaio support as well soon. Fow now, it's an opt-in feature for test purposes" * 'for-4.4/io-poll' of git://git.kernel.dk/linux-block: direct-io: be sure to assign dio->bio_bdev for both paths directio: add block polling support NVMe: add blk polling support block: add block polling support blk-mq: return tag/queue combo in the make_request_fn handlers block: change ->make_request_fn() and users to return a queue cookie 
Pull block IO poll support from Jens Axboe:
 "Various groups have been doing experimentation around IO polling for
  (really) fast devices.  The code has been reviewed and has been
  sitting on the side for a few releases, but this is now good enough
  for coordinated benchmarking and further experimentation.

  Currently O_DIRECT sync read/write are supported.  A framework is in
  the works that allows scalable stats tracking so we can auto-tune
  this.  And we'll add libaio support as well soon.  Fow now, it's an
  opt-in feature for test purposes"

* 'for-4.4/io-poll' of git://git.kernel.dk/linux-block:
  direct-io: be sure to assign dio->bio_bdev for both paths
  directio: add block polling support
  NVMe: add blk polling support
  block: add block polling support
  blk-mq: return tag/queue combo in the make_request_fn handlers
  block: change ->make_request_fn() and users to return a queue cookie
direct-io: be sure to assign dio->bio_bdev for both paths 2015-11-10T17:14:38+00:00 Jens Axboe axboe@fb.com 2015-11-10T17:14:38+00:00 c1c534609fe8a859f9c8108a5591e6e8a97e34d1 btrfs sets ->submit_io(), and we failed to set the block dev for that path. That resulted in a potential NULL dereference when we later wait for IO in dio_await_one(). Reported-by: kernel test robot <ying.huang@linux.intel.com> Signed-off-by: Jens Axboe <axboe@fb.com> 
btrfs sets ->submit_io(), and we failed to set the block dev for
that path. That resulted in a potential NULL dereference when
we later wait for IO in dio_await_one().

Reported-by: kernel test robot <ying.huang@linux.intel.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
directio: add block polling support 2015-11-07T17:40:47+00:00 Jens Axboe axboe@fb.com 2015-10-27T05:09:51+00:00 15c4f638f3d41bae52105ca4c0c8760afbcbeaab This adds support for sync O_DIRECT read/write poll support. Signed-off-by: Jens Axboe <axboe@fb.com> [hch: split from a larger patch, minor updates] Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Keith Busch <keith.busch@intel.com> 
This adds support for sync O_DIRECT read/write poll support.

Signed-off-by: Jens Axboe <axboe@fb.com>
[hch: split from a larger patch, minor updates]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Keith Busch <keith.busch@intel.com>
mm, page_alloc: rename __GFP_WAIT to __GFP_RECLAIM 2015-11-07T01:50:42+00:00 Mel Gorman mgorman@techsingularity.net 2015-11-07T00:28:28+00:00 71baba4b92dc1fa1bc461742c6ab1942ec6034e9 __GFP_WAIT was used to signal that the caller was in atomic context and could not sleep. Now it is possible to distinguish between true atomic context and callers that are not willing to sleep. The latter should clear __GFP_DIRECT_RECLAIM so kswapd will still wake. As clearing __GFP_WAIT behaves differently, there is a risk that people will clear the wrong flags. This patch renames __GFP_WAIT to __GFP_RECLAIM to clearly indicate what it does -- setting it allows all reclaim activity, clearing them prevents it. [akpm@linux-foundation.org: fix build] [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Mel Gorman <mgorman@techsingularity.net> Acked-by: Michal Hocko <mhocko@suse.com> Acked-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Christoph Lameter <cl@linux.com> Acked-by: David Rientjes <rientjes@google.com> Cc: Vitaly Wool <vitalywool@gmail.com> Cc: Rik van Riel <riel@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
__GFP_WAIT was used to signal that the caller was in atomic context and
could not sleep.  Now it is possible to distinguish between true atomic
context and callers that are not willing to sleep.  The latter should
clear __GFP_DIRECT_RECLAIM so kswapd will still wake.  As clearing
__GFP_WAIT behaves differently, there is a risk that people will clear the
wrong flags.  This patch renames __GFP_WAIT to __GFP_RECLAIM to clearly
indicate what it does -- setting it allows all reclaim activity, clearing
them prevents it.

[akpm@linux-foundation.org: fix build]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
fs: direct-io: don't dirtying pages for ITER_BVEC/ITER_KVEC direct read 2015-09-23T17:00:57+00:00 Ming Lei ming.lei@canonical.com 2015-08-17T02:31:46+00:00 53cbf3b157a0428d40989ab1c7df9228a1976fc2 When direct read IO is submitted from kernel, it is often unnecessary to dirty pages, for example of loop, dirtying pages have been considered in the upper filesystem(over loop) side already, and they don't need to be dirtied again. So this patch doesn't dirtying pages for ITER_BVEC/ITER_KVEC direct read, and loop should be the 1st case to use ITER_BVEC/ITER_KVEC for direct read I/O. The patch is based on previous Dave's patch. Reviewed-by: Dave Kleikamp <dave.kleikamp@oracle.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Jens Axboe <axboe@fb.com> 
When direct read IO is submitted from kernel, it is often
unnecessary to dirty pages, for example of loop, dirtying pages
have been considered in the upper filesystem(over loop) side
already, and they don't need to be dirtied again.

So this patch doesn't dirtying pages for ITER_BVEC/ITER_KVEC
direct read, and loop should be the 1st case to use ITER_BVEC/ITER_KVEC
for direct read I/O.

The patch is based on previous Dave's patch.

Reviewed-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
block: remove bio_get_nr_vecs() 2015-08-13T18:32:04+00:00 Kent Overstreet kent.overstreet@gmail.com 2015-05-19T12:31:01+00:00 b54ffb73cadcdcff9cc1ae0e11f502407e3e2e4c We can always fill up the bio now, no need to estimate the possible size based on queue parameters. Acked-by: Steven Whitehouse <swhiteho@redhat.com> Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com> [hch: rebased and wrote a changelog] Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Ming Lin <ming.l@ssi.samsung.com> Signed-off-by: Jens Axboe <axboe@fb.com> 
We can always fill up the bio now, no need to estimate the possible
size based on queue parameters.

Acked-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Kent Overstreet <kent.overstreet@gmail.com>
[hch: rebased and wrote a changelog]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ming Lin <ming.l@ssi.samsung.com>
Signed-off-by: Jens Axboe <axboe@fb.com>