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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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?

Jan Kara <jack@xxxxxxxx>

[Index of Archives]     [Linux File System Development]     [Linux BTRFS]     [Linux NFS]     [Linux Filesystems]     [Ext4 Filesystem]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Resources]

  Powered by Linux