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: 28+ 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 19:07 ` Matthew Wilcox
2022-12-17 23:33 ` Ira Weiny [this message]
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-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-16 20:53 ` [PATCH 5/8] reiserfs: Convert do_journal_end() " Matthew Wilcox (Oracle)
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 18:34 ` Matthew Wilcox
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-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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).