From: Ira Weiny <ira.weiny@intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: reiserfs-devel@vger.kernel.org, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org,
"Fabio M. De Francesco" <fmdefrancesco@gmail.com>
Subject: Re: [PATCH 2/8] reiserfs: use kmap_local_folio() in _get_block_create_0()
Date: Sat, 17 Dec 2022 15:33:05 -0800 [thread overview]
Message-ID: <Y55RsbPJDZQi1BeC@iweiny-mobl> (raw)
In-Reply-To: <Y54TYOqbPuKlfiHk@casper.infradead.org>
On Sat, Dec 17, 2022 at 07:07:12PM +0000, Matthew Wilcox wrote:
> On Sat, Dec 17, 2022 at 09:14:05AM -0800, Ira Weiny wrote:
> > On Fri, Dec 16, 2022 at 08:53:41PM +0000, Matthew Wilcox (Oracle) wrote:
> > > Switch from the deprecated kmap() to kmap_local_folio(). For the
> > > kunmap_local(), I subtract off 'chars' to prevent the possibility that
> > > p has wrapped into the next page.
> >
> > Thanks for tackling this one. I think the conversion is mostly safe because I
> > don't see any reason the mapping is passed to another thread.
> >
> > But comments like this make me leary:
> >
> > "But, this means the item might move if kmap schedules"
> >
> > What does that mean? That seems to imply there is something wrong with the
> > base code separate from the kmapping.
>
> I should probably have deleted that comment. I'm pretty sure what it
> refers to is that we don't hold a lock that prevents the item from
> moving. When ReiserFS was written, we didn't have CONFIG_PREEMPT, so
> if kmap() scheduled, that was a point at which the item could move.
> I don't think I introduced any additional brokenness by converting
> from kmap() to kmap_local().
Agreed. I only said mostly safe because of the question about chars below.
> Maybe I'm wrong and somebody who
> understands ReiserFS can explain.
Yep.
>
> > To the patch, I think subtracting chars might be an issue. If chars > offset
> > and the loop takes the first 'if (done) break;' path then p will end up
> > pointing at the previous page wouldn't it?
>
> I thought about that and managed to convince myself that chars was
> always < offset. But now I'm not sure again. Easiest way to fix
> this is actually to move the p += chars before the if (done) break;.
I thought about that too. So yea that is fine.
>
> I also need to rev this patch because it assumes that b_folio is a
> single page.
>
> diff --git a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
> index 008855ddb365..be13ce7a38e1 100644
> --- a/fs/reiserfs/inode.c
> +++ b/fs/reiserfs/inode.c
> @@ -295,7 +295,6 @@ static int _get_block_create_0(struct inode *inode, sector_t block,
> int ret;
> int result;
> int done = 0;
> - unsigned long offset;
>
> /* prepare the key to look for the 'block'-th block of file */
> make_cpu_key(&key, inode,
> @@ -380,17 +379,16 @@ static int _get_block_create_0(struct inode *inode, sector_t block,
> set_buffer_uptodate(bh_result);
> goto finished;
> }
> - /* read file tail into part of page */
> - offset = (cpu_key_k_offset(&key) - 1) & (PAGE_SIZE - 1);
> copy_item_head(&tmp_ih, ih);
>
> /*
> * we only want to kmap if we are reading the tail into the page.
> * this is not the common case, so we don't kmap until we are
> - * sure we need to. But, this means the item might move if
> - * kmap schedules
> + * sure we need to.
> */
> - p = kmap_local_folio(bh_result->b_folio, offset);
> + p = kmap_local_folio(bh_result->b_folio,
> + offset_in_folio(bh_result->b_folio,
> + cpu_key_k_offset(&key) - 1));
Yes good addition.
With these changes:
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> memset(p, 0, inode->i_sb->s_blocksize);
> do {
> if (!is_direct_le_ih(ih)) {
> @@ -413,12 +411,11 @@ static int _get_block_create_0(struct inode *inode, sector_t block,
> chars = ih_item_len(ih) - path.pos_in_item;
> }
> memcpy(p, ih_item_body(bh, ih) + path.pos_in_item, chars);
> + p += chars;
>
> if (done)
> break;
>
> - p += chars;
> -
> /*
> * we done, if read direct item is not the last item of
> * node FIXME: we could try to check right delimiting key
WARNING: multiple messages have this Message-ID (diff)
From: Ira Weiny <ira.weiny@intel.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: <reiserfs-devel@vger.kernel.org>, Jan Kara <jack@suse.cz>,
<linux-fsdevel@vger.kernel.org>,
"Fabio M. De Francesco" <fmdefrancesco@gmail.com>
Subject: Re: [PATCH 2/8] reiserfs: use kmap_local_folio() in _get_block_create_0()
Date: Sat, 17 Dec 2022 15:33:05 -0800 [thread overview]
Message-ID: <Y55RsbPJDZQi1BeC@iweiny-mobl> (raw)
In-Reply-To: <Y54TYOqbPuKlfiHk@casper.infradead.org>
On Sat, Dec 17, 2022 at 07:07:12PM +0000, Matthew Wilcox wrote:
> On Sat, Dec 17, 2022 at 09:14:05AM -0800, Ira Weiny wrote:
> > On Fri, Dec 16, 2022 at 08:53:41PM +0000, Matthew Wilcox (Oracle) wrote:
> > > Switch from the deprecated kmap() to kmap_local_folio(). For the
> > > kunmap_local(), I subtract off 'chars' to prevent the possibility that
> > > p has wrapped into the next page.
> >
> > Thanks for tackling this one. I think the conversion is mostly safe because I
> > don't see any reason the mapping is passed to another thread.
> >
> > But comments like this make me leary:
> >
> > "But, this means the item might move if kmap schedules"
> >
> > What does that mean? That seems to imply there is something wrong with the
> > base code separate from the kmapping.
>
> I should probably have deleted that comment. I'm pretty sure what it
> refers to is that we don't hold a lock that prevents the item from
> moving. When ReiserFS was written, we didn't have CONFIG_PREEMPT, so
> if kmap() scheduled, that was a point at which the item could move.
> I don't think I introduced any additional brokenness by converting
> from kmap() to kmap_local().
Agreed. I only said mostly safe because of the question about chars below.
> Maybe I'm wrong and somebody who
> understands ReiserFS can explain.
Yep.
>
> > To the patch, I think subtracting chars might be an issue. If chars > offset
> > and the loop takes the first 'if (done) break;' path then p will end up
> > pointing at the previous page wouldn't it?
>
> I thought about that and managed to convince myself that chars was
> always < offset. But now I'm not sure again. Easiest way to fix
> this is actually to move the p += chars before the if (done) break;.
I thought about that too. So yea that is fine.
>
> I also need to rev this patch because it assumes that b_folio is a
> single page.
>
> diff --git a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
> index 008855ddb365..be13ce7a38e1 100644
> --- a/fs/reiserfs/inode.c
> +++ b/fs/reiserfs/inode.c
> @@ -295,7 +295,6 @@ static int _get_block_create_0(struct inode *inode, sector_t block,
> int ret;
> int result;
> int done = 0;
> - unsigned long offset;
>
> /* prepare the key to look for the 'block'-th block of file */
> make_cpu_key(&key, inode,
> @@ -380,17 +379,16 @@ static int _get_block_create_0(struct inode *inode, sector_t block,
> set_buffer_uptodate(bh_result);
> goto finished;
> }
> - /* read file tail into part of page */
> - offset = (cpu_key_k_offset(&key) - 1) & (PAGE_SIZE - 1);
> copy_item_head(&tmp_ih, ih);
>
> /*
> * we only want to kmap if we are reading the tail into the page.
> * this is not the common case, so we don't kmap until we are
> - * sure we need to. But, this means the item might move if
> - * kmap schedules
> + * sure we need to.
> */
> - p = kmap_local_folio(bh_result->b_folio, offset);
> + p = kmap_local_folio(bh_result->b_folio,
> + offset_in_folio(bh_result->b_folio,
> + cpu_key_k_offset(&key) - 1));
Yes good addition.
With these changes:
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
> memset(p, 0, inode->i_sb->s_blocksize);
> do {
> if (!is_direct_le_ih(ih)) {
> @@ -413,12 +411,11 @@ static int _get_block_create_0(struct inode *inode, sector_t block,
> chars = ih_item_len(ih) - path.pos_in_item;
> }
> memcpy(p, ih_item_body(bh, ih) + path.pos_in_item, chars);
> + p += chars;
>
> if (done)
> break;
>
> - p += chars;
> -
> /*
> * we done, if read direct item is not the last item of
> * node FIXME: we could try to check right delimiting key
next prev parent reply other threads:[~2022-12-17 23:33 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 20:53 [PATCH 0/8] Convert reiserfs from b_page to b_folio Matthew Wilcox (Oracle)
2022-12-16 20:53 ` [PATCH 1/8] reiserfs: use b_folio instead of b_page in some obvious cases Matthew Wilcox (Oracle)
2022-12-16 20:53 ` [PATCH 2/8] reiserfs: use kmap_local_folio() in _get_block_create_0() Matthew Wilcox (Oracle)
2022-12-17 17:14 ` Ira Weiny
2022-12-17 17:14 ` Ira Weiny
2022-12-17 19:07 ` Matthew Wilcox
2022-12-17 23:33 ` Ira Weiny [this message]
2022-12-17 23:33 ` Ira Weiny
2022-12-19 10:42 ` Jan Kara
2022-12-16 20:53 ` [PATCH 3/8] reiserfs: Convert direct2indirect() to call folio_zero_range() Matthew Wilcox (Oracle)
2022-12-17 21:08 ` Ira Weiny
2022-12-17 21:08 ` Ira Weiny
2022-12-16 20:53 ` [PATCH 4/8] reiserfs: Convert reiserfs_delete_item() to use kmap_local_folio() Matthew Wilcox (Oracle)
2022-12-17 23:44 ` Ira Weiny
2022-12-17 23:44 ` Ira Weiny
2022-12-16 20:53 ` [PATCH 5/8] reiserfs: Convert do_journal_end() " Matthew Wilcox (Oracle)
2022-12-17 23:52 ` Ira Weiny
2022-12-17 23:52 ` Ira Weiny
2022-12-20 9:35 ` Matthew Wilcox
2022-12-20 11:18 ` Jan Kara
2022-12-20 16:58 ` Ira Weiny
2022-12-20 16:58 ` Ira Weiny
2022-12-20 18:34 ` Matthew Wilcox
2022-12-20 23:59 ` Ira Weiny
2022-12-20 23:59 ` Ira Weiny
2022-12-21 19:04 ` Matthew Wilcox
2022-12-22 10:37 ` Jan Kara
2022-12-16 20:53 ` [PATCH 6/8] reiserfs: Convert map_block_for_writepage() " Matthew Wilcox (Oracle)
2022-12-18 0:02 ` Ira Weiny
2022-12-18 0:02 ` Ira Weiny
2022-12-16 20:53 ` [PATCH 7/8] reiserfs: Convert convert_tail_for_hole() to use folios Matthew Wilcox (Oracle)
2022-12-16 20:53 ` [PATCH 8/8] reiserfs: Use flush_dcache_folio() in reiserfs_quota_write() Matthew Wilcox (Oracle)
2022-12-17 20:43 ` [PATCH 0/8] Convert reiserfs from b_page to b_folio Fabio M. De Francesco
2022-12-17 23:39 ` Ira Weiny
2022-12-17 23:39 ` Ira Weiny
2022-12-18 8:09 ` Fabio M. De Francesco
2022-12-18 17:59 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y55RsbPJDZQi1BeC@iweiny-mobl \
--to=ira.weiny@intel.com \
--cc=fmdefrancesco@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=reiserfs-devel@vger.kernel.org \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.