Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 3 Oct 2022 23:18:37 +0100
From:   Al Viro <viro@zeniv.linux.org.uk>
To:     Ira Weiny <ira.weiny@intel.com>
Cc:     "J. R. Okajima" <hooanon05g@gmail.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH][CFT] [coredump] don't use __kernel_write() on
 kmap_local_page()
Message-ID: <YztfvaAFOe2kGvDz@ZenIV>
References: <YzN+ZYLjK6HI1P1C@ZenIV>
 <YzSSl1ItVlARDvG3@ZenIV>
 <YzpcXU2WO8e22Cmi@iweiny-desk3>
 <7714.1664794108@jrobl>
 <Yzs4mL3zrrC0/vN+@iweiny-mobl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Yzs4mL3zrrC0/vN+@iweiny-mobl>
Sender: Al Viro <viro@ftp.linux.org.uk>
Precedence: bulk

On Mon, Oct 03, 2022 at 12:31:36PM -0700, Ira Weiny wrote:
> On Mon, Oct 03, 2022 at 07:48:28PM +0900, J. R. Okajima wrote:
> > Ira Weiny:
> > > On Wed, Sep 28, 2022 at 07:29:43PM +0100, Al Viro wrote:
> > > > On Tue, Sep 27, 2022 at 11:51:17PM +0100, Al Viro wrote:
> > > > > [I'm going to send a pull request tomorrow if nobody yells;
> > > > > please review and test - it seems to work fine here, but extra
> > > > > eyes and extra testing would be very welcome]
> > 
> > I tried gdb backtrace 'bt' command with the new core by v6.0, and it
> > doesn't show the call trace correctly. Is it related to this commit?
> >
> 
> Are you also getting something like this?
> 
> BFD: warning: /mnt/9p/test-okajima/core is truncated: expected core file size >= 225280, found: 76616
> 
> I did not see that before.  I'm running through this patch vs a fix to
> kmap_to_page()[1] and I may have gotten the 2 crossed up.  So I'm retesting
> with your test below.

Argh....  Try this:

fix coredump breakage caused by badly tested "[coredump] don't use __kernel_write() on kmap_local_page()"

Let me count the ways I'd screwed up:

* when emitting a page, handling of gaps in coredump should happen
before fetching the current file position.
* fix for problem that occurs on rather uncommon setups (and hadn't
been observed in the wild) sent very late in the cycle.
* ... with badly insufficient testing, introducing an easily
reproducable breakage.  Without giving it time to soak in -next.

Fucked-up-by: Al Viro <viro@zeniv.linux.org.uk>
Fixes: 06bbaa6dc53c "[coredump] don't use __kernel_write() on kmap_local_page()"
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/fs/coredump.c b/fs/coredump.c
index 1ab4f5b76a1e..3538f3a63965 100644
--- a/fs/coredump.c
+++ b/fs/coredump.c
@@ -841,7 +841,7 @@ static int dump_emit_page(struct coredump_params *cprm, struct page *page)
 	};
 	struct iov_iter iter;
 	struct file *file = cprm->file;
-	loff_t pos = file->f_pos;
+	loff_t pos;
 	ssize_t n;
 
 	if (cprm->to_skip) {
@@ -853,6 +853,7 @@ static int dump_emit_page(struct coredump_params *cprm, struct page *page)
 		return 0;
 	if (dump_interrupted())
 		return 0;
+	pos = file->f_pos;
 	iov_iter_bvec(&iter, WRITE, &bvec, 1, PAGE_SIZE);
 	n = __kernel_write_iter(cprm->file, &iter, &pos);
 	if (n != PAGE_SIZE)