Re: [PATCH 5/8] reiserfs: Convert do_journal_end() to use kmap_local_folio()

Jan Kara <[email protected]>
Newsgroups gmane.linux.file-systems,gmane.comp.file-systems.reiserfs.general
Message-ID <20221220111801.jhukawk3lbuonxs3@quack3>
On Tue 20-12-22 09:35:43, Matthew Wilcox wrote:
> But that doesn't solve the "What about fs block size > PAGE_SIZE"
> problem that we also want to solve.  Here's a concrete example:
> 
>  static __u32 jbd2_checksum_data(__u32 crc32_sum, struct buffer_head *bh)
>  {
> -       struct page *page = bh->b_page;
> +       struct folio *folio = bh->b_folio;
>         char *addr;
>         __u32 checksum;
>  
> -       addr = kmap_atomic(page);
> -       checksum = crc32_be(crc32_sum,
> -               (void *)(addr + offset_in_page(bh->b_data)), bh->b_size);
> -       kunmap_atomic(addr);
> +       BUG_ON(IS_ENABLED(CONFIG_HIGHMEM) && bh->b_size > PAGE_SIZE);
> +
> +       addr = kmap_local_folio(folio, offset_in_folio(folio, bh->b_data));
> +       checksum = crc32_be(crc32_sum, addr, bh->b_size);
> +       kunmap_local(addr);
>  
>         return checksum;
>  }
> 
> I don't want to add a lot of complexity to handle the case of b_size >
> PAGE_SIZE on a HIGHMEM machine since that's not going to benefit terribly
> many people.  I'd rather have the assertion that we don't support it.
> But if there's a good higher-level abstraction I'm missing here ...

Just out of curiosity: So far I was thinking folio is physically contiguous
chunk of memory. And if it is, then it does not seem as a huge overkill if
kmap_local_folio() just maps the whole folio? Or are you concerned about
the overhead of finding big enough hole in the vmap area?

								Honza
-- 
Jan Kara <[email protected]>
SUSE Labs, CR
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.