public inbox for linux-next@vger.kernel.org 
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb•auug.org.au>
To: "Darrick J. Wong" <darrick.wong@oracle•com>
Cc: Linux Next Mailing List <linux-next@vger•kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger•kernel.org>,
	Christoph Hellwig <hch@lst•de>, Jens Axboe <axboe@kernel•dk>,
	Ming Lei <ming.lei@redhat•com>
Subject: linux-next: manual merge of the iomap tree with Linus' tree
Date: Wed, 10 Jul 2019 11:25:03 +1000	[thread overview]
Message-ID: <20190710112503.30e2ad08@canb.auug.org.au> (raw)

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

Hi all,

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

  fs/iomap.c

between commits:

  147a60538d91 ("iomap: use bio_release_pages in iomap_dio_bio_end_io")
  ff896738be38 ("block: return from __bio_try_merge_page if merging occured in the same page")
  79d08f89bb1b ("block: fix .bi_size overflow")

from Linus' tree and commits:

  c8934e8fa92f ("iomap: move the direct IO code into a separate file")
  66148f9b8b2e ("iomap: move the buffered read code into a separate file")
  79d08f89bb1b ("block: fix .bi_size overflow")

from the iomap tree.

I fixed it up (I removed the file and applied the following merge fix
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: Wed, 10 Jul 2019 11:18:41 +1000
Subject: [PATCH] iomap: fix for block changes and split of iomap.c

Signed-off-by: Stephen Rothwell <sfr@canb•auug.org.au>
---
 fs/iomap/direct-io.c |  8 +-------
 fs/iomap/read.c      | 14 +++++++++-----
 2 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
index 33d303cf0e59..6885450496c9 100644
--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -174,13 +174,7 @@ static void iomap_dio_bio_end_io(struct bio *bio)
 	if (should_dirty) {
 		bio_check_pages_dirty(bio);
 	} else {
-		if (!bio_flagged(bio, BIO_NO_PAGE_REF)) {
-			struct bvec_iter_all iter_all;
-			struct bio_vec *bvec;
-
-			bio_for_each_segment_all(bvec, bio, iter_all)
-				put_page(bvec->bv_page);
-		}
+		bio_release_pages(bio, false);
 		bio_put(bio);
 	}
 }
diff --git a/fs/iomap/read.c b/fs/iomap/read.c
index 117626cd7ead..6478436fd05a 100644
--- a/fs/iomap/read.c
+++ b/fs/iomap/read.c
@@ -143,7 +143,7 @@ iomap_readpage_actor(struct inode *inode, loff_t pos, loff_t length, void *data,
 	struct iomap_readpage_ctx *ctx = data;
 	struct page *page = ctx->cur_page;
 	struct iomap_page *iop = iomap_page_create(inode, page);
-	bool is_contig = false;
+	bool same_page = false, is_contig = false;
 	loff_t orig_pos = pos;
 	unsigned poff, plen;
 	sector_t sector;
@@ -171,10 +171,14 @@ iomap_readpage_actor(struct inode *inode, loff_t pos, loff_t length, void *data,
 	 * Try to merge into a previous segment if we can.
 	 */
 	sector = iomap_sector(iomap, pos);
-	if (ctx->bio && bio_end_sector(ctx->bio) == sector) {
-		if (__bio_try_merge_page(ctx->bio, page, plen, poff, true))
-			goto done;
+	if (ctx->bio && bio_end_sector(ctx->bio) == sector)
 		is_contig = true;
+
+	if (is_contig &&
+	    __bio_try_merge_page(ctx->bio, page, plen, poff, &same_page)) {
+		if (!same_page && iop)
+			atomic_inc(&iop->read_count);
+		goto done;
 	}
 
 	/*
@@ -185,7 +189,7 @@ iomap_readpage_actor(struct inode *inode, loff_t pos, loff_t length, void *data,
 	if (iop)
 		atomic_inc(&iop->read_count);
 
-	if (!ctx->bio || !is_contig || bio_full(ctx->bio)) {
+	if (!ctx->bio || !is_contig || bio_full(ctx->bio, plen)) {
 		gfp_t gfp = mapping_gfp_constraint(page->mapping, GFP_KERNEL);
 		int nr_vecs = (length + PAGE_SIZE - 1) >> PAGE_SHIFT;
 
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell

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

                 reply	other threads:[~2019-07-10  1:25 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20190710112503.30e2ad08@canb.auug.org.au \
    --to=sfr@canb$(echo .)auug.org.au \
    --cc=axboe@kernel$(echo .)dk \
    --cc=darrick.wong@oracle$(echo .)com \
    --cc=hch@lst$(echo .)de \
    --cc=linux-kernel@vger$(echo .)kernel.org \
    --cc=linux-next@vger$(echo .)kernel.org \
    --cc=ming.lei@redhat$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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