* linux-next: manual merge of the folio tree with the btrfs tree
@ 2022-05-10 8:39 Stephen Rothwell
2022-05-10 9:43 ` Filipe Manana
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Rothwell @ 2022-05-10 8:39 UTC (permalink / raw)
To: Matthew Wilcox, David Sterba
Cc: David Sterba, Filipe Manana, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]
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
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.
--
Cheers,
Stephen Rothwell
diff --cc fs/btrfs/send.c
index 8e8e4ab59930,8985d115559d..000000000000
--- a/fs/btrfs/send.c
+++ b/fs/btrfs/send.c
@@@ -4905,13 -4984,14 +4905,14 @@@ static int put_file_data(struct send_ct
}
}
- if (PageReadahead(page)) {
- page_cache_async_readahead(inode->i_mapping, &sctx->ra,
- NULL, page_folio(page), index,
- last_index + 1 - index);
- }
+ if (PageReadahead(page))
+ page_cache_async_readahead(sctx->cur_inode->i_mapping,
- &sctx->ra, NULL, page, index,
++ &sctx->ra, NULL,
++ page_folio(page), index,
+ last_index + 1 - index);
if (!PageUptodate(page)) {
- btrfs_readpage(NULL, page);
+ btrfs_read_folio(NULL, page_folio(page));
lock_page(page);
if (!PageUptodate(page)) {
unlock_page(page);
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: linux-next: manual merge of the folio tree with the btrfs tree
2022-05-10 8:39 linux-next: manual merge of the folio tree with the btrfs tree Stephen Rothwell
@ 2022-05-10 9:43 ` Filipe Manana
2022-05-10 15:04 ` Matthew Wilcox
0 siblings, 1 reply; 6+ messages in thread
From: Filipe Manana @ 2022-05-10 9:43 UTC (permalink / raw)
To: Stephen Rothwell, Matthew Wilcox, David Sterba
Cc: David Sterba, Linux Kernel Mailing List, Linux Next Mailing List
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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: linux-next: manual merge of the folio tree with the btrfs tree
2022-05-10 9:43 ` Filipe Manana
@ 2022-05-10 15:04 ` Matthew Wilcox
2022-05-10 15:06 ` Filipe Manana
0 siblings, 1 reply; 6+ messages in thread
From: Matthew Wilcox @ 2022-05-10 15:04 UTC (permalink / raw)
To: Filipe Manana
Cc: Stephen Rothwell, David Sterba, David Sterba,
Linux Kernel Mailing List, Linux Next Mailing List
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: linux-next: manual merge of the folio tree with the btrfs tree
2022-05-10 15:04 ` Matthew Wilcox
@ 2022-05-10 15:06 ` Filipe Manana
0 siblings, 0 replies; 6+ messages in thread
From: Filipe Manana @ 2022-05-10 15:06 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Stephen Rothwell, David Sterba, David Sterba,
Linux Kernel Mailing List, Linux Next Mailing List
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.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* linux-next: manual merge of the folio tree with the btrfs tree
@ 2022-06-14 3:34 Stephen Rothwell
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Rothwell @ 2022-06-14 3:34 UTC (permalink / raw)
To: Matthew Wilcox, David Sterba
Cc: David Sterba, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]
Hi all,
Today's linux-next merge of the folio tree got a conflict in:
fs/btrfs/disk-io.c
between commit:
fe9b88cb7288 ("btrfs: use preallocated page for super block write")
from the btrfs tree and commit:
020ae1ea6060 ("btrfs: Use a folio in wait_dev_supers()")
from the folio tree.
I fixed it up (I did not know how to fix this up, so I used the former -
effectively reverting the latter) 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.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* linux-next: manual merge of the folio tree with the btrfs tree
@ 2022-05-02 7:43 Stephen Rothwell
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Rothwell @ 2022-05-02 7:43 UTC (permalink / raw)
To: Matthew Wilcox, David Sterba
Cc: Christoph Hellwig, David Sterba, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2429 bytes --]
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 <sfr@canb.auug.org.au>
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 <sfr@canb.auug.org.au>
---
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-06-14 3:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-10 8:39 linux-next: manual merge of the folio tree with the btrfs tree Stephen Rothwell
2022-05-10 9:43 ` Filipe Manana
2022-05-10 15:04 ` Matthew Wilcox
2022-05-10 15:06 ` Filipe Manana
-- strict thread matches above, loose matches on Subject: below --
2022-06-14 3:34 Stephen Rothwell
2022-05-02 7:43 Stephen Rothwell
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).