Hi all,
Today's linux-next merge of the folio tree got conflicts in:
fs/btrfs/ctree.h
fs/btrfs/inode.c
between commit:
a3e4d924b41d ("btrfs: move btrfs_readpage to extent_io.c")
from the btrfs tree and commit:
5a912a9c68ac ("btrfs: Convert btrfs to read_folio")
from the folio tree.
I fixed it up (I used the conflicting parts of the above files from the
former and applied the below patch) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
From: Stephen Rothwell <[email protected]>
Date: Mon, 2 May 2022 17:21:26 +1000
Subject: [PATCH] fix up for "btrfs: move btrfs_readpage to extent_io.c"
Signed-off-by: Stephen Rothwell <[email protected]>
---
fs/btrfs/extent_io.c | 3 ++-
fs/btrfs/extent_io.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 5de09556b1c3..aa8905a0d63a 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3792,8 +3792,9 @@ static int btrfs_do_readpage(struct page *page, struct extent_map **em_cached,
return ret;
}
-int btrfs_readpage(struct file *file, struct page *page)
+int btrfs_read_folio(struct file *file, struct folio *folio)
{
+ struct page *page = &folio->page;
struct btrfs_inode *inode = BTRFS_I(page->mapping->host);
u64 start = page_offset(page);
u64 end = start + PAGE_SIZE - 1;
diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
index 375a721c48eb..4a2205fd189a 100644
--- a/fs/btrfs/extent_io.h
+++ b/fs/btrfs/extent_io.h
@@ -166,7 +166,7 @@ typedef struct extent_map *(get_extent_t)(struct btrfs_inode *inode,
int try_release_extent_mapping(struct page *page, gfp_t mask);
int try_release_extent_buffer(struct page *page);
-int btrfs_readpage(struct file *file, struct page *page);
+int btrfs_read_folio(struct file *file, struct folio *folio);
int extent_write_full_page(struct page *page, struct writeback_control *wbc);
int extent_write_locked_range(struct inode *inode, u64 start, u64 end);
int extent_writepages(struct address_space *mapping,
--
2.35.1
--
Cheers,
Stephen Rothwell
On 10/05/22 09:39, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the folio tree got a conflict in:
>
> fs/btrfs/send.c
>
> between commit:
>
> d1a1a97304b4 ("btrfs: send: keep the current inode open while processing it")
>
> from the btrfs tree and commit:
>
> 2ebdd1df3166 ("mm/readahead: Convert page_cache_async_readahead to take a folio")
>
> from the folio tree.
>
> I fixed it up (I think - see below) and can carry the fix as
Looks correct to me.
Thanks.
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
>
On 10/05/22 16:04, Matthew Wilcox wrote:
> On Tue, May 10, 2022 at 10:43:07AM +0100, Filipe Manana wrote:
>> On 10/05/22 09:39, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the folio tree got a conflict in:
>>>
>>> fs/btrfs/send.c
>>>
>>> between commit:
>>>
>>> d1a1a97304b4 ("btrfs: send: keep the current inode open while processing it")
>>>
>>> from the btrfs tree and commit:
>>>
>>> 2ebdd1df3166 ("mm/readahead: Convert page_cache_async_readahead to take a folio")
>>>
>>> from the folio tree.
>>>
>>> I fixed it up (I think - see below) and can carry the fix as
>>
>> Looks correct to me.
>
> Me too. The patch this one enables is rather sad. It's yet another
> reminder that we suck at streaming workloads. But until we fix that,
> don't you want to use invalidate_inode_pages2_range() rather than
> truncate_inode_pages_range()? If your send conflicts with someone
> else's write(), you'll erase their write to the page cache.
Send operates only on readonly trees, so it can't happen.
Thanks.
>
On Tue, May 10, 2022 at 10:43:07AM +0100, Filipe Manana wrote:
> On 10/05/22 09:39, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the folio tree got a conflict in:
> >
> > fs/btrfs/send.c
> >
> > between commit:
> >
> > d1a1a97304b4 ("btrfs: send: keep the current inode open while processing it")
> >
> > from the btrfs tree and commit:
> >
> > 2ebdd1df3166 ("mm/readahead: Convert page_cache_async_readahead to take a folio")
> >
> > from the folio tree.
> >
> > I fixed it up (I think - see below) and can carry the fix as
>
> Looks correct to me.
Me too. The patch this one enables is rather sad. It's yet another
reminder that we suck at streaming workloads. But until we fix that,
don't you want to use invalidate_inode_pages2_range() rather than
truncate_inode_pages_range()? If your send conflicts with someone
else's write(), you'll erase their write to the page cache.