Re: [Cluster-devel] [PATCH v7 00/20] bio: check return values of bio_add_page
On Wed, 31 May 2023 04:50:23 -0700, Johannes Thumshirn wrote: > We have two functions for adding a page to a bio, __bio_add_page() which is > used to add a single page to a freshly created bio and bio_add_page() which is > used to add a page to an existing bio. > > While __bio_add_page() is expected to succeed, bio_add_page() can fail. > > This series converts the callers of bio_add_page() which can easily use > __bio_add_page() to using it and checks the return of bio_add_page() for > callers that don't work on a freshly created bio. > > [...] Applied, thanks! [01/20] swap: use __bio_add_page to add page to bio commit: cb58bf91b138c1a8b18cca9503308789e26e3522 [02/20] drbd: use __bio_add_page to add page to bio commit: 8f11f79f193c935da617375ba5ea4e768a73a094 [03/20] dm: dm-zoned: use __bio_add_page for adding single metadata page commit: fc8ac3e539561aff1c0a255d701d9412d425373c [04/20] fs: buffer: use __bio_add_page to add single page to bio commit: 741af75d4027b1229fc6e62f4e3c4378dfe04897 [05/20] md: use __bio_add_page to add single page commit: 3c383235c51dcd6198d37ac3ac06e2acad79f981 [06/20] md: raid5-log: use __bio_add_page to add single page commit: b0a2f17cad9d3fa564d67c543f5d19343401fefd [07/20] md: raid5: use __bio_add_page to add single page to new bio commit: 6eea4ff8528d6a5b9f0eeb47992e48a8f44b5b8f [08/20] jfs: logmgr: use __bio_add_page to add single page to bio commit: 2896db174ced7a800863223f9e74543b98271ba0 [09/20] gfs2: use __bio_add_page for adding single page to bio commit: effa7ddeeba782406c81b572791a142fbdaf6b05 [10/20] zonefs: use __bio_add_page for adding single page to bio commit: 0fa5b08cf6e17b0a64ffcc5894d8efe186691ab8 [11/20] zram: use __bio_add_page for adding single page to bio commit: 34848c910b911838e1e83e1370cb988b578c8860 [12/20] floppy: use __bio_add_page for adding single page to bio commit: 5225229b8fdfb3e65520c43547ecf9a737161c3f [13/20] md: check for failure when adding pages in alloc_behind_master_bio commit: 6473bc325644b9c8473e6c92bfb520a68dce1e12 [14/20] md: raid1: use __bio_add_page for adding single page to bio commit: 2f9848178cfa4ac68a5b46e63e5163a09b8bd80f [15/20] md: raid1: check if adding pages to resync bio fails commit: 2be32fe91ff54ff326b3a1608973544e835a [16/20] dm-crypt: use __bio_add_page to add single page to clone bio commit: 9be63ecfdd63f957b9ed25eaf85666d22a02d7a5 [17/20] block: mark bio_add_page as __must_check commit: 5b3e39c1cc8e1cf31a398830dd665eb15546b4f7 [18/20] block: add bio_add_folio_nofail commit: 42205551d1d43b1b42942fb7ef023cf954136cea [19/20] fs: iomap: use bio_add_folio_nofail where possible commit: f31c58ab3ddaf64503d7988197602d7443d5be37 [20/20] block: mark bio_add_folio as __must_check commit: 9320744e4dbe10df6059b2b6531946c200a0ba3b Best regards, -- Jens Axboe
Re: [Cluster-devel] [PATCH v5 00/20] bio: check return values of bio_add_page
On 5/26/23 12:37 AM, Johannes Thumshirn wrote: > On 24.05.23 17:02, Jens Axboe wrote: >> On 5/2/23 4:19?AM, Johannes Thumshirn wrote: >>> We have two functions for adding a page to a bio, __bio_add_page() which is >>> used to add a single page to a freshly created bio and bio_add_page() which >>> is >>> used to add a page to an existing bio. >>> >>> While __bio_add_page() is expected to succeed, bio_add_page() can fail. >>> >>> This series converts the callers of bio_add_page() which can easily use >>> __bio_add_page() to using it and checks the return of bio_add_page() for >>> callers that don't work on a freshly created bio. >>> >>> Lastly it marks bio_add_page() as __must_check so we don't have to go again >>> and audit all callers. >> >> Looks fine to me, though it would be nice if the fs and dm people could >> give this a quick look. Should not take long, any empty bio addition >> should, by definition, be able to use a non-checked page addition for >> the first page. >> > > I think the FS side is all covered. @Mike could you have a look at the dm > patches? Not the iomap one, that was my main concern. Not that this is tricky stuff, but still... -- Jens Axboe
Re: [Cluster-devel] [PATCH v5 00/20] bio: check return values of bio_add_page
On 5/2/23 4:19?AM, Johannes Thumshirn wrote: > We have two functions for adding a page to a bio, __bio_add_page() which is > used to add a single page to a freshly created bio and bio_add_page() which is > used to add a page to an existing bio. > > While __bio_add_page() is expected to succeed, bio_add_page() can fail. > > This series converts the callers of bio_add_page() which can easily use > __bio_add_page() to using it and checks the return of bio_add_page() for > callers that don't work on a freshly created bio. > > Lastly it marks bio_add_page() as __must_check so we don't have to go again > and audit all callers. Looks fine to me, though it would be nice if the fs and dm people could give this a quick look. Should not take long, any empty bio addition should, by definition, be able to use a non-checked page addition for the first page. -- Jens Axboe
Re: [Cluster-devel] [PATCH v5 00/20] bio: check return values of bio_add_page
On 5/5/23 2:09?AM, Johannes Thumshirn wrote: > On 02.05.23 12:20, Johannes Thumshirn wrote: >> We have two functions for adding a page to a bio, __bio_add_page() which is >> used to add a single page to a freshly created bio and bio_add_page() which >> is >> used to add a page to an existing bio. >> >> While __bio_add_page() is expected to succeed, bio_add_page() can fail. >> >> This series converts the callers of bio_add_page() which can easily use >> __bio_add_page() to using it and checks the return of bio_add_page() for >> callers that don't work on a freshly created bio. >> >> Lastly it marks bio_add_page() as __must_check so we don't have to go again >> and audit all callers. >> >> Changes to v4: >> - Rebased onto latest Linus' master >> - Dropped already merged patches >> - Added Sergey's Reviewed-by >> >> Changes to v3: >> - Added __bio_add_folio and use it in iomap (Willy) >> - Mark bio_add_folio must check (Willy) >> - s/GFS/GFS2/ (Andreas) >> >> Changes to v2: >> - Removed 'wont fail' comments pointed out by Song >> >> Changes to v1: >> - Removed pointless comment pointed out by Willy >> - Changed commit messages pointed out by Damien >> - Colledted Damien's Reviews and Acks > > Jens any comments on this? I'll take a look post -rc1. -- Jens Axboe
Re: [Cluster-devel] use block_device based APIs in block layer consumers v3
On Fri, 15 Apr 2022 06:52:31 +0200, Christoph Hellwig wrote:
> this series cleanups up the block layer API so that APIs consumed
> by file systems are (almost) only struct block_devic based, so that
> file systems don't have to poke into block layer internals like the
> request_queue.
>
> I also found a bunch of existing bugs related to partition offsets
> and discard so these are fixed while going along.
>
> [...]
Applied, thanks!
[01/27] target: remove an incorrect unmap zeroes data deduction
commit: 179d8609d8424529e95021df939ed7b0b82b37f1
[02/27] target: pass a block_device to target_configure_unmap_from_queue
commit: 817e8b51eb3d927ce6d56ecf9f48bc3c5b26168b
[03/27] target: fix discard alignment on partitions
commit: 968786b9ef56e75e0109158a4936ea962c1e
[04/27] drbd: remove assign_p_sizes_qlim
commit: 40349d0e16cedd0de561f59752c3249780fb749b
[05/27] drbd: use bdev based limit helpers in drbd_send_sizes
commit: 7a38acce229685968b770d1d9e64e01396b93643
[06/27] drbd: use bdev_alignment_offset instead of queue_alignment_offset
commit: c6f23b1a05441a26f765e59dd95e8ba7354f9388
[07/27] drbd: cleanup decide_on_discard_support
commit: 998e9cbcd615e5e6a7baa69e673ee845f812744e
[08/27] btrfs: use bdev_max_active_zones instead of open coding it
commit: c1e7b24416400ef13ff92a1c60c336c9a2834d7b
[09/27] ntfs3: use bdev_logical_block_size instead of open coding it
commit: f09dac9afb8e3ce4b6485dbc091a9b9c742db023
[10/27] mm: use bdev_is_zoned in claim_swapfile
commit: 9964e674559b02619fee2012a56839624143d02e
[11/27] block: add a bdev_nonrot helper
commit: 10f0d2a517796b8f6dc04fb0cc3e49003ae6b0bc
[12/27] block: add a bdev_write_cache helper
commit: 08e688fdb8f7e862092ae64cee20bc8b463d1046
[13/27] block: add a bdev_fua helper
commit: a557e82e5a01826f902bd94fc925c03f253cb712
[14/27] block: add a bdev_stable_writes helper
commit: 36d254893aa6a6e204075c3cce94bb572ac32c04
[15/27] block: add a bdev_max_zone_append_sectors helper
commit: 2aba0d19f4d8c8929b4b3b94a9cfde2aa20e6ee2
[16/27] block: use bdev_alignment_offset in part_alignment_offset_show
commit: 64dcc7c2717395b7c83ffb10f040d3be795d03c1
[17/27] block: use bdev_alignment_offset in disk_alignment_offset_show
commit: 640f2a23911b8388989547f89d055afbb910b88e
[18/27] block: move bdev_alignment_offset and queue_limit_alignment_offset out
of line
commit: 89098b075cb74a80083bc4ed6b71d0ee18b6898f
[19/27] block: remove queue_discard_alignment
commit: 4e1462ffe8998749884d61f91be251a7a8719677
[20/27] block: use bdev_discard_alignment in part_discard_alignment_show
commit: f0f975a4dde890bfe25ce17bf07a6495453988a4
[21/27] block: move {bdev,queue_limit}_discard_alignment out of line
commit: 5c4b4a5c6f11c869a57c6bd977143430bc9dc43d
[22/27] block: refactor discard bio size limiting
commit: e3cc28ea28b5f8794db2aed24f8a0282ad2e85a2
[23/27] block: add a bdev_max_discard_sectors helper
commit: cf0fbf894bb543f472f682c486be48298eccf199
[24/27] block: remove QUEUE_FLAG_DISCARD
commit: 70200574cc229f6ba038259e8142af2aa09e6976
[25/27] block: add a bdev_discard_granularity helper
commit: 7b47ef52d0a2025fd1408a8a0990933b8e1e510f
[26/27] block: decouple REQ_OP_SECURE_ERASE from REQ_OP_DISCARD
commit: 44abff2c0b970ae3d310b97617525dc01f248d7c
[27/27] direct-io: remove random prefetches
commit: c22198e78d523c8fa079bbb70b2523bb6aa51849
Best regards,
--
Jens Axboe
Re: [Cluster-devel] [dm-devel] [PATCH V15 00/18] block: support multi-page bvec
On 2/15/19 10:14 AM, Bart Van Assche wrote:
> On Fri, 2019-02-15 at 08:49 -0700, Jens Axboe wrote:
>> On 2/15/19 4:13 AM, Ming Lei wrote:
>>> This patchset brings multi-page bvec into block layer:
>>
>> Applied, thanks Ming. Let's hope it sticks!
>
> Hi Jens and Ming,
>
> Test nvmeof-mp/002 fails with Jens' for-next branch from this morning.
> I have not yet tried to figure out which patch introduced the failure.
> Anyway, this is what I see in the kernel log for test nvmeof-mp/002:
>
> [ 475.611363] BUG: unable to handle kernel NULL pointer dereference at
> 0020
> [ 475.621188] #PF error: [normal kernel read fault]
> [ 475.623148] PGD 0 P4D 0
> [ 475.624737] Oops: [#1] PREEMPT SMP KASAN
> [ 475.626628] CPU: 1 PID: 277 Comm: kworker/1:1H Tainted: GB
> 5.0.0-rc6-dbg+ #1
> [ 475.630232] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.10.2-1 04/01/2014
> [ 475.633855] Workqueue: kblockd blk_mq_requeue_work
> [ 475.635777] RIP: 0010:__blk_recalc_rq_segments+0xbe/0x590
> [ 475.670948] Call Trace:
> [ 475.693515] blk_recalc_rq_segments+0x2f/0x50
> [ 475.695081] blk_insert_cloned_request+0xbb/0x1c0
> [ 475.701142] dm_mq_queue_rq+0x3d1/0x770
> [ 475.707225] blk_mq_dispatch_rq_list+0x5fc/0xb10
> [ 475.717137] blk_mq_sched_dispatch_requests+0x256/0x300
> [ 475.721767] __blk_mq_run_hw_queue+0xd6/0x180
> [ 475.725920] __blk_mq_delay_run_hw_queue+0x25c/0x290
> [ 475.727480] blk_mq_run_hw_queue+0x119/0x1b0
> [ 475.732019] blk_mq_run_hw_queues+0x7b/0xa0
> [ 475.733468] blk_mq_requeue_work+0x2cb/0x300
> [ 475.736473] process_one_work+0x4f1/0xa40
> [ 475.739424] worker_thread+0x67/0x5b0
> [ 475.741751] kthread+0x1cf/0x1f0
> [ 475.746034] ret_from_fork+0x24/0x30
>
> (gdb) list *(__blk_recalc_rq_segments+0xbe)
> 0x816a152e is in __blk_recalc_rq_segments (block/blk-merge.c:366).
> 361 struct bio *bio)
> 362 {
> 363 struct bio_vec bv, bvprv = { NULL };
> 364 int prev = 0;
> 365 unsigned int seg_size, nr_phys_segs;
> 366 unsigned front_seg_size = bio->bi_seg_front_size;
> 367 struct bio *fbio, *bbio;
> 368 struct bvec_iter iter;
> 369
> 370 if (!bio)
Just ran a few tests, and it also seems to cause about a 5% regression
in per-core IOPS throughput. Prior to this work, I could get 1620K 4k
rand read IOPS out of core, now I'm at ~1535K. The cycler stealer seems
to be blk_queue_split() and blk_rq_map_sg().
--
Jens Axboe
Re: [Cluster-devel] [PATCH V15 00/18] block: support multi-page bvec
On 2/15/19 4:13 AM, Ming Lei wrote: > Hi, > > This patchset brings multi-page bvec into block layer: > > 1) what is multi-page bvec? > > Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages > which are physically contiguous instead of one single page used in linux > kernel for long time. > > 2) why is multi-page bvec introduced? > > Kent proposed the idea[1] first. > > As system's RAM becomes much bigger than before, and huge page, transparent > huge page and memory compaction are widely used, it is a bit easy now > to see physically contiguous pages from fs in I/O. On the other hand, from > block layer's view, it isn't necessary to store intermediate pages into bvec, > and it is enough to just store the physicallly contiguous 'segment' in each > io vector. > > Also huge pages are being brought to filesystem and swap [2][6], we can > do IO on a hugepage each time[3], which requires that one bio can transfer > at least one huge page one time. Turns out it isn't flexiable to change > BIO_MAX_PAGES simply[3][5]. Multipage bvec can fit in this case very well. > As we saw, if CONFIG_THP_SWAP is enabled, BIO_MAX_PAGES can be configured > as much bigger, such as 512, which requires at least two 4K pages for holding > the bvec table. > > With multi-page bvec: > > - Inside block layer, both bio splitting and sg map can become more > efficient than before by just traversing the physically contiguous > 'segment' instead of each page. > > - segment handling in block layer can be improved much in future since it > should be quite easy to convert multipage bvec into segment easily. For > example, we might just store segment in each bvec directly in future. > > - bio size can be increased and it should improve some high-bandwidth IO > case in theory[4]. > > - there is opportunity in future to improve memory footprint of bvecs. > > 3) how is multi-page bvec implemented in this patchset? > > Patch 1 ~ 3 parpares for supporting multi-page bvec. > > Patches 4 ~ 14 implement multipage bvec in block layer: > > - put all tricks into bvec/bio/rq iterators, and as far as > drivers and fs use these standard iterators, they are happy > with multipage bvec > > - introduce bio_for_each_bvec() to iterate over multipage bvec for > splitting > bio and mapping sg > > - keep current bio_for_each_segment*() to itereate over singlepage bvec > and > make sure current users won't be broken; especailly, convert to this > new helper prototype in single patch 21 given it is bascially a > mechanism > conversion > > - deal with iomap & xfs's sub-pagesize io vec in patch 13 > > - enalbe multipage bvec in patch 14 > > Patch 15 redefines BIO_MAX_PAGES as 256. > > Patch 16 documents usages of bio iterator helpers. > > Patch 17~18 kills NO_SG_MERGE. > > These patches can be found in the following git tree: > > git: https://github.com/ming1/linux.git v5.0-blk_mp_bvec_v14 ^^^ v15? > Lots of test(blktest, xfstests, ltp io, ...) have been run with this patchset, > and not see regression. > > Thanks Christoph for reviewing the early version and providing very good > suggestions, such as: introduce bio_init_with_vec_table(), remove another > unnecessary helpers for cleanup and so on. > > Thanks Chritoph and Omar for reviewing V10/V11/V12, and provides lots of > helpful comments. Applied, thanks Ming. Let's hope it sticks! -- Jens Axboe
Re: [Cluster-devel] [PATCH V13 00/19] block: support multi-page bvec
On 1/11/19 4:01 AM, Ming Lei wrote: > Hi, > > This patchset brings multi-page bvec into block layer: > > 1) what is multi-page bvec? > > Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages > which are physically contiguous instead of one single page used in linux > kernel for long time. > > 2) why is multi-page bvec introduced? > > Kent proposed the idea[1] first. > > As system's RAM becomes much bigger than before, and huge page, transparent > huge page and memory compaction are widely used, it is a bit easy now > to see physically contiguous pages from fs in I/O. On the other hand, from > block layer's view, it isn't necessary to store intermediate pages into bvec, > and it is enough to just store the physicallly contiguous 'segment' in each > io vector. > > Also huge pages are being brought to filesystem and swap [2][6], we can > do IO on a hugepage each time[3], which requires that one bio can transfer > at least one huge page one time. Turns out it isn't flexiable to change > BIO_MAX_PAGES simply[3][5]. Multipage bvec can fit in this case very well. > As we saw, if CONFIG_THP_SWAP is enabled, BIO_MAX_PAGES can be configured > as much bigger, such as 512, which requires at least two 4K pages for holding > the bvec table. > > With multi-page bvec: > > - Inside block layer, both bio splitting and sg map can become more > efficient than before by just traversing the physically contiguous > 'segment' instead of each page. > > - segment handling in block layer can be improved much in future since it > should be quite easy to convert multipage bvec into segment easily. For > example, we might just store segment in each bvec directly in future. > > - bio size can be increased and it should improve some high-bandwidth IO > case in theory[4]. > > - there is opportunity in future to improve memory footprint of bvecs. > > 3) how is multi-page bvec implemented in this patchset? > > Patch 1 ~ 4 parpares for supporting multi-page bvec. > > Patches 5 ~ 15 implement multipage bvec in block layer: > > - put all tricks into bvec/bio/rq iterators, and as far as > drivers and fs use these standard iterators, they are happy > with multipage bvec > > - introduce bio_for_each_bvec() to iterate over multipage bvec for > splitting > bio and mapping sg > > - keep current bio_for_each_segment*() to itereate over singlepage bvec > and > make sure current users won't be broken; especailly, convert to this > new helper prototype in single patch 21 given it is bascially a > mechanism > conversion > > - deal with iomap & xfs's sub-pagesize io vec in patch 13 > > - enalbe multipage bvec in patch 14 > > Patch 16 redefines BIO_MAX_PAGES as 256. > > Patch 17 documents usages of bio iterator helpers. > > Patch 18~19 kills NO_SG_MERGE. > > These patches can be found in the following git tree: > > git: https://github.com/ming1/linux.git for-4.21-block-mp-bvec-V12 > > Lots of test(blktest, xfstests, ltp io, ...) have been run with this patchset, > and not see regression. > > Thanks Christoph for reviewing the early version and providing very good > suggestions, such as: introduce bio_init_with_vec_table(), remove another > unnecessary helpers for cleanup and so on. > > Thanks Chritoph and Omar for reviewing V10/V11/V12, and provides lots of > helpful comments. Thanks for persisting in this endeavor, Ming, I've applied this for 5.1. -- Jens Axboe
Re: [Cluster-devel] [PATCH V12 00/20] block: support multi-page bvec
On 11/28/18 6:30 PM, Ming Lei wrote: >> I'm going back and forth on those one a bit. Any concerns with >> pushing this to 4.22? > > My only one concern is about the warning of > "blk_cloned_rq_check_limits: over max segments limit" on dm multipath, > and seems Ewan and Mike is waiting for this fix. Not familiar with this issue, can you post a link to it? I'd be fine working around anything until 4.22, it's not going to be a new issue. -- Jens Axboe
Re: [Cluster-devel] [PATCH V12 00/20] block: support multi-page bvec
On 11/25/18 7:17 PM, Ming Lei wrote: > Hi, > > This patchset brings multi-page bvec into block layer: > > 1) what is multi-page bvec? > > Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages > which are physically contiguous instead of one single page used in linux > kernel for long time. > > 2) why is multi-page bvec introduced? > > Kent proposed the idea[1] first. > > As system's RAM becomes much bigger than before, and huge page, transparent > huge page and memory compaction are widely used, it is a bit easy now > to see physically contiguous pages from fs in I/O. On the other hand, from > block layer's view, it isn't necessary to store intermediate pages into bvec, > and it is enough to just store the physicallly contiguous 'segment' in each > io vector. > > Also huge pages are being brought to filesystem and swap [2][6], we can > do IO on a hugepage each time[3], which requires that one bio can transfer > at least one huge page one time. Turns out it isn't flexiable to change > BIO_MAX_PAGES simply[3][5]. Multipage bvec can fit in this case very well. > As we saw, if CONFIG_THP_SWAP is enabled, BIO_MAX_PAGES can be configured > as much bigger, such as 512, which requires at least two 4K pages for holding > the bvec table. I'm pretty happy with this patchset at this point, looks like it just needs a respin to address the last comments. My only concern is whether it's a good idea to target this for 4.21, or if we should wait until 4.22. 4.21 has a fairly substantial amount of changes in terms of block already, it's not the best timing for something of this magnitude too. I'm going back and forth on those one a bit. Any concerns with pushing this to 4.22? -- Jens Axboe
Re: [Cluster-devel] [PATCH V10 01/19] block: introduce multi-page page bvec helpers
On 11/18/18 7:23 PM, Ming Lei wrote: > On Fri, Nov 16, 2018 at 02:13:05PM +0100, Christoph Hellwig wrote: >>> -#define bvec_iter_page(bvec, iter) \ >>> +#define mp_bvec_iter_page(bvec, iter) \ >>> (__bvec_iter_bvec((bvec), (iter))->bv_page) >>> >>> -#define bvec_iter_len(bvec, iter) \ >>> +#define mp_bvec_iter_len(bvec, iter) \ >> >> I'd much prefer if we would stick to the segment naming that >> we also use in the higher level helper. >> >> So segment_iter_page, segment_iter_len, etc. > > We discussed the naming problem before, one big problem is that the 'segment' > in bio_for_each_segment*() means one single page segment actually. > > If we use segment_iter_page() here for multi-page segment, it may > confuse people. > > Of course, I prefer to the naming of segment/page, > > And Jens didn't agree to rename bio_for_each_segment*() before. I didn't like frivolous renaming (and I still don't), but mp_ is horrible imho. Don't name these after the fact that they are done in conjunction with supporting multipage bvecs. That very fact will be irrelevant very soon -- Jens Axboe
Re: [Cluster-devel] [PATCH v7] blktrace: Fix potentail deadlock between delete & sysfs ops
On 09/20/2017 11:32 AM, Steven Rostedt wrote: > > Christoph, > > Can you give an acked-by for this patch? > > Jens, > > You want to take this through your tree, or do you want me to? > > If you want it, here's my: > > Acked-by: Steven Rostedt (VMware) I'll take it through my tree, and I'll prune some of that comment as well (which should be a commit message thing, not a code comment). -- Jens Axboe
Re: [Cluster-devel] [PATCH 0/25 v3] fs: Convert all embedded bdis into separate ones
On Wed, Apr 12 2017, Jan Kara wrote: > Hello, > > this is the third revision of the patch series which converts all embedded > occurences of struct backing_dev_info to use standalone dynamically allocated > structures. This makes bdi handling unified across all bdi users and generally > removes some boilerplate code from filesystems setting up their own bdi. It > also allows us to remove some code from generic bdi implementation. > > The patches were only compile-tested for most filesystems (I've tested > mounting only for NFS & btrfs) so fs maintainers please have a look whether > the changes look sound to you. > > This series is based on top of bdi fixes that were merged into linux-block > git tree into for-next branch. I have pushed out the result as a branch to > > git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git bdi > > Since all patches got reviewed by Christoph, can you please pick them up Jens? > Thanks! Yep, picked up for 4.12. Thanks Jan! -- Jens Axboe
