From: Ira Weiny <[email protected]>
I am submitting these for 5.13.
Further work to remove more kmap() calls in favor of the kmap_local_page() this
series converts those calls which required more than a common pattern which
were covered in my previous series[1]. This is the second of what I hope to be
3 series to fully convert btrfs. However, the 3rd series is going to be an RFC
because I need to have more eyes on it before I'm sure about what to do. For
now this series should be good to go for 5.13.
Also this series converts the kmaps in the raid5/6 code which required a fix to
the kmap'ings which was submitted in [2].
Thanks,
Ira
[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://lore.kernel.org/lkml/[email protected]/
Ira Weiny (4):
fs/btrfs: Convert kmap to kmap_local_page() using coccinelle
fs/btrfs: Convert raid5/6 kmaps to kmap_local_page()
fs/btrfs: Use kmap_local_page() in __btrfsic_submit_bio()
fs/btrfs: Convert block context kmap's to kmap_local_page()
fs/btrfs/check-integrity.c | 12 ++++----
fs/btrfs/compression.c | 4 +--
fs/btrfs/inode.c | 4 +--
fs/btrfs/lzo.c | 9 +++---
fs/btrfs/raid56.c | 61 +++++++++++++++++++-------------------
5 files changed, 44 insertions(+), 46 deletions(-)
--
2.28.0.rc0.12.gb6a658bd00c9
From: Ira Weiny <[email protected]>
Again there is an array of pointers which must be unmapped in the correct
order.
Convert the kmap()'s to kmap_local_page() and adjust the unmapping
to work backwards through the unmapping loop.
Signed-off-by: Ira Weiny <[email protected]>
---
fs/btrfs/check-integrity.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index 6ff44e53814c..726eb894be8b 100644
--- a/fs/btrfs/check-integrity.c
+++ b/fs/btrfs/check-integrity.c
@@ -2677,7 +2677,7 @@ static void __btrfsic_submit_bio(struct bio *bio)
dev_state = btrfsic_dev_state_lookup(bio_dev(bio) + bio->bi_partno);
if (NULL != dev_state &&
(bio_op(bio) == REQ_OP_WRITE) && bio_has_data(bio)) {
- unsigned int i = 0;
+ int i = 0;
u64 dev_bytenr;
u64 cur_bytenr;
struct bio_vec bvec;
@@ -2702,7 +2702,7 @@ static void __btrfsic_submit_bio(struct bio *bio)
bio_for_each_segment(bvec, bio, iter) {
BUG_ON(bvec.bv_len != PAGE_SIZE);
- mapped_datav[i] = kmap(bvec.bv_page);
+ mapped_datav[i] = kmap_local_page(bvec.bv_page);
i++;
if (dev_state->state->print_mask &
@@ -2715,8 +2715,8 @@ static void __btrfsic_submit_bio(struct bio *bio)
mapped_datav, segs,
bio, &bio_is_patched,
bio->bi_opf);
- bio_for_each_segment(bvec, bio, iter)
- kunmap(bvec.bv_page);
+ for (--i; i >= 0; i--)
+ kunmap_local(mapped_datav[i]);
kfree(mapped_datav);
} else if (NULL != dev_state && (bio->bi_opf & REQ_PREFLUSH)) {
if (dev_state->state->print_mask &
--
2.28.0.rc0.12.gb6a658bd00c9
From: Ira Weiny <[email protected]>
btrfsic_read_block() (which calls kmap()) and
btrfsic_release_block_ctx() (which calls kunmap()) are always called
within a single thread of execution.
Therefore the mappings created within these calls can be a thread local
mapping.
Convert the kmap() of bloc_ctx->pagev to kmap_local_page(). Luckily the
unmap loops backwards through the array pointer so no adjustment needs
to be made to the unmapping order.
Signed-off-by: Ira Weiny <[email protected]>
---
fs/btrfs/check-integrity.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index 726eb894be8b..1ff9e19508a7 100644
--- a/fs/btrfs/check-integrity.c
+++ b/fs/btrfs/check-integrity.c
@@ -1558,7 +1558,7 @@ static void btrfsic_release_block_ctx(struct btrfsic_block_data_ctx *block_ctx)
while (num_pages > 0) {
num_pages--;
if (block_ctx->datav[num_pages]) {
- kunmap(block_ctx->pagev[num_pages]);
+ kunmap_local(block_ctx->datav[num_pages]);
block_ctx->datav[num_pages] = NULL;
}
if (block_ctx->pagev[num_pages]) {
@@ -1637,7 +1637,7 @@ static int btrfsic_read_block(struct btrfsic_state *state,
i = j;
}
for (i = 0; i < num_pages; i++)
- block_ctx->datav[i] = kmap(block_ctx->pagev[i]);
+ block_ctx->datav[i] = kmap_local_page(block_ctx->pagev[i]);
return block_ctx->len;
}
--
2.28.0.rc0.12.gb6a658bd00c9
On Tue, Feb 16, 2021 at 06:48:22PM -0800, 'Ira Weiny' wrote:
> From: Ira Weiny <[email protected]>
>
> I am submitting these for 5.13.
Just a friendly ping on this set.
Ira
>
> Further work to remove more kmap() calls in favor of the kmap_local_page() this
> series converts those calls which required more than a common pattern which
> were covered in my previous series[1]. This is the second of what I hope to be
> 3 series to fully convert btrfs. However, the 3rd series is going to be an RFC
> because I need to have more eyes on it before I'm sure about what to do. For
> now this series should be good to go for 5.13.
>
> Also this series converts the kmaps in the raid5/6 code which required a fix to
> the kmap'ings which was submitted in [2].
>
> Thanks,
> Ira
>
> [1] https://lore.kernel.org/lkml/[email protected]/
> [2] https://lore.kernel.org/lkml/[email protected]/
>
>
> Ira Weiny (4):
> fs/btrfs: Convert kmap to kmap_local_page() using coccinelle
> fs/btrfs: Convert raid5/6 kmaps to kmap_local_page()
> fs/btrfs: Use kmap_local_page() in __btrfsic_submit_bio()
> fs/btrfs: Convert block context kmap's to kmap_local_page()
>
> fs/btrfs/check-integrity.c | 12 ++++----
> fs/btrfs/compression.c | 4 +--
> fs/btrfs/inode.c | 4 +--
> fs/btrfs/lzo.c | 9 +++---
> fs/btrfs/raid56.c | 61 +++++++++++++++++++-------------------
> 5 files changed, 44 insertions(+), 46 deletions(-)
>
> --
> 2.28.0.rc0.12.gb6a658bd00c9
>
On Tue, Feb 16, 2021 at 06:48:22PM -0800, [email protected] wrote:
> From: Ira Weiny <[email protected]>
>
> I am submitting these for 5.13.
>
> Further work to remove more kmap() calls in favor of the kmap_local_page() this
> series converts those calls which required more than a common pattern which
> were covered in my previous series[1]. This is the second of what I hope to be
> 3 series to fully convert btrfs. However, the 3rd series is going to be an RFC
> because I need to have more eyes on it before I'm sure about what to do. For
> now this series should be good to go for 5.13.
>
> Also this series converts the kmaps in the raid5/6 code which required a fix to
> the kmap'ings which was submitted in [2].
Branch added to for-next and will be moved to the devel queue next week.
I've added some comments about the ordering requirement, that's
something not obvious. There's a comment under 1st patch but that's
trivial to fix if needed. Thanks.
On Fri, Mar 12, 2021 at 08:41:41PM +0100, David Sterba wrote:
> On Tue, Feb 16, 2021 at 06:48:22PM -0800, [email protected] wrote:
> > From: Ira Weiny <[email protected]>
> >
> > I am submitting these for 5.13.
> >
> > Further work to remove more kmap() calls in favor of the kmap_local_page() this
> > series converts those calls which required more than a common pattern which
> > were covered in my previous series[1]. This is the second of what I hope to be
> > 3 series to fully convert btrfs. However, the 3rd series is going to be an RFC
> > because I need to have more eyes on it before I'm sure about what to do. For
> > now this series should be good to go for 5.13.
> >
> > Also this series converts the kmaps in the raid5/6 code which required a fix to
> > the kmap'ings which was submitted in [2].
>
> Branch added to for-next and will be moved to the devel queue next week.
> I've added some comments about the ordering requirement, that's
> something not obvious. There's a comment under 1st patch but that's
> trivial to fix if needed. Thanks.
I've replied to the first patch. LMK if you want me to respin it.
Thanks!
Ira
On Tue, Mar 16, 2021 at 12:07:24PM +0100, David Sterba wrote:
> On Fri, Mar 12, 2021 at 12:05:00PM -0800, Ira Weiny wrote:
> > On Fri, Mar 12, 2021 at 08:41:41PM +0100, David Sterba wrote:
> > > On Tue, Feb 16, 2021 at 06:48:22PM -0800, [email protected] wrote:
> > > > From: Ira Weiny <[email protected]>
> > > >
> > > > I am submitting these for 5.13.
> > > >
> > > > Further work to remove more kmap() calls in favor of the kmap_local_page() this
> > > > series converts those calls which required more than a common pattern which
> > > > were covered in my previous series[1]. This is the second of what I hope to be
> > > > 3 series to fully convert btrfs. However, the 3rd series is going to be an RFC
> > > > because I need to have more eyes on it before I'm sure about what to do. For
> > > > now this series should be good to go for 5.13.
> > > >
> > > > Also this series converts the kmaps in the raid5/6 code which required a fix to
> > > > the kmap'ings which was submitted in [2].
> > >
> > > Branch added to for-next and will be moved to the devel queue next week.
> > > I've added some comments about the ordering requirement, that's
> > > something not obvious. There's a comment under 1st patch but that's
> > > trivial to fix if needed. Thanks.
> >
> > I've replied to the first patch. LMK if you want me to respin it.
>
> No need to respin, patchset now in misc-next. Thanks.
Sweet! Thanks!
Ira
On Fri, Mar 12, 2021 at 12:05:00PM -0800, Ira Weiny wrote:
> On Fri, Mar 12, 2021 at 08:41:41PM +0100, David Sterba wrote:
> > On Tue, Feb 16, 2021 at 06:48:22PM -0800, [email protected] wrote:
> > > From: Ira Weiny <[email protected]>
> > >
> > > I am submitting these for 5.13.
> > >
> > > Further work to remove more kmap() calls in favor of the kmap_local_page() this
> > > series converts those calls which required more than a common pattern which
> > > were covered in my previous series[1]. This is the second of what I hope to be
> > > 3 series to fully convert btrfs. However, the 3rd series is going to be an RFC
> > > because I need to have more eyes on it before I'm sure about what to do. For
> > > now this series should be good to go for 5.13.
> > >
> > > Also this series converts the kmaps in the raid5/6 code which required a fix to
> > > the kmap'ings which was submitted in [2].
> >
> > Branch added to for-next and will be moved to the devel queue next week.
> > I've added some comments about the ordering requirement, that's
> > something not obvious. There's a comment under 1st patch but that's
> > trivial to fix if needed. Thanks.
>
> I've replied to the first patch. LMK if you want me to respin it.
No need to respin, patchset now in misc-next. Thanks.