public inbox for linux-next@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Matthew Wilcox <willy@infradead.org>, Theodore Ts'o <tytso@mit.edu>
Cc: Jan Kara <jack@suse.cz>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: linux-next: manual merge of the folio tree with the ext4 tree
Date: Tue, 15 Mar 2022 20:40:07 +1100	[thread overview]
Message-ID: <20220315204007.05ad4817@canb.auug.org.au> (raw)

[-- Attachment #1: Type: text/plain, Size: 3378 bytes --]

Hi all,

Today's linux-next merge of the folio tree got a conflict in:

  fs/ext4/inode.c

between commit:

  2bb8dd401a4f ("ext4: warn when dirtying page w/o buffers in data=journal mode")

from the ext4 tree and commit:

  821405cf3ebb ("fs: Convert trivial uses of __set_page_dirty_nobuffers to filemap_dirty_folio")

from the folio tree.

I didn't know how to complete this fix up ans so just commented out the
new WARN_ON().

I fixed it up (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/ext4/inode.c
index 3d0ca48d20c8,436efd31cc27..000000000000
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@@ -3573,31 -3541,30 +3573,32 @@@ const struct iomap_ops ext4_iomap_repor
  };
  
  /*
-  * Whenever the page is being dirtied, corresponding buffers should already be
 - * Folios can be marked dirty completely asynchronously from ext4's
 - * journalling activity.  By filemap_sync_pte(), try_to_unmap_one(), etc.
 - * We cannot do much here because ->dirty_folio may be called with the
 - * page table lock held.  The folio is not necessarily locked.
++ * Whenever the folio is being dirtied, corresponding buffers should already be
 + * attached to the transaction (we take care of this in ext4_page_mkwrite() and
 + * ext4_write_begin()). However we cannot move buffers to dirty transaction
-  * lists here because ->set_page_dirty is called under VFS locks and the page
++ * lists here because ->dirty_folio is called under VFS locks and the folio
 + * is not necessarily locked.
   *
-  * We cannot just dirty the page and leave attached buffers clean, because the
+  * We cannot just dirty the folio and leave attached buffers clean, because the
   * buffers' dirty state is "definitive".  We cannot just set the buffers dirty
   * or jbddirty because all the journalling code will explode.
   *
-  * So what we do is to mark the page "pending dirty" and next time writepage
+  * So what we do is to mark the folio "pending dirty" and next time writepage
   * is called, propagate that into the buffers appropriately.
   */
- static int ext4_journalled_set_page_dirty(struct page *page)
+ static bool ext4_journalled_dirty_folio(struct address_space *mapping,
+ 		struct folio *folio)
  {
- 	WARN_ON_ONCE(!page_has_buffers(page));
- 	SetPageChecked(page);
- 	return __set_page_dirty_nobuffers(page);
++/*	WARN_ON_ONCE(!page_has_buffers(page)); */
+ 	folio_set_checked(folio);
+ 	return filemap_dirty_folio(mapping, folio);
  }
  
- static int ext4_set_page_dirty(struct page *page)
+ static bool ext4_dirty_folio(struct address_space *mapping, struct folio *folio)
  {
- 	WARN_ON_ONCE(!PageLocked(page) && !PageDirty(page));
- 	WARN_ON_ONCE(!page_has_buffers(page));
- 	return __set_page_dirty_buffers(page);
+ 	WARN_ON_ONCE(!folio_test_locked(folio) && !folio_test_dirty(folio));
+ 	WARN_ON_ONCE(!folio_buffers(folio));
+ 	return block_dirty_folio(mapping, folio);
  }
  
  static int ext4_iomap_swap_activate(struct swap_info_struct *sis,

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

             reply	other threads:[~2022-03-15  9:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-15  9:40 Stephen Rothwell [this message]
2022-03-15 11:25 ` linux-next: manual merge of the folio tree with the ext4 tree Jan Kara
2022-03-15 12:03   ` Stephen Rothwell
2022-03-15 17:44   ` Theodore Ts'o

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=20220315204007.05ad4817@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=tytso@mit.edu \
    --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