From: Matthew Wilcox <willy@infradead.org>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
Wang Yugui <wangyugui@e16-tech.com>,
Dave Chinner <david@fromorbit.com>,
Christoph Hellwig <hch@infradead.org>,
"Darrick J . Wong" <djwong@kernel.org>,
Kent Overstreet <kent.overstreet@linux.dev>
Subject: Re: [PATCH v4 1/9] iov_iter: Handle compound highmem pages in copy_page_from_iter_atomic()
Date: Tue, 11 Jul 2023 01:03:18 +0100 [thread overview]
Message-ID: <ZKycRh1ebCg+Yzue@casper.infradead.org> (raw)
In-Reply-To: <ZKyXp2NyoHy3K1qu@bombadil.infradead.org>
On Mon, Jul 10, 2023 at 04:43:35PM -0700, Luis Chamberlain wrote:
> > - }
> > - iterate_and_advance(i, bytes, base, len, off,
> > - copyin(p + off, base, len),
> > - memcpy_from_iter(i, p + off, base, len)
> > - )
> > - kunmap_atomic(kaddr);
> > - return bytes;
> > +
> > + do {
> > + char *p;
> > +
> > + n = bytes - copied;
> > + if (PageHighMem(page)) {
> > + page += offset / PAGE_SIZE;
>
> I don't quite follow here how before the page was not modified
> to get to the first kmap_atomic(page) and now immediately if we're
> on a PageHighMem(page) we're doing some arithmetic to the page
> address to get the first kmap_atomic(). The only thing I could
> think of is seems like an implicit assumption here that if its a compound
> highmem page then we always start off with offset with a value of
> 0, is that right? But that seems to not be correct either.
The important thing to know is that it was buggy before. If you called
copy_page_from_iter_atomic() with an offset larger than PAGE_SIZE, it
corrupted random memory! I can only assume that nobody was doing that.
next prev parent reply other threads:[~2023-07-11 0:03 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-10 13:02 [PATCH v4 0/9] Create large folios in iomap buffered write path Matthew Wilcox (Oracle)
2023-07-10 13:02 ` [PATCH v4 1/9] iov_iter: Handle compound highmem pages in copy_page_from_iter_atomic() Matthew Wilcox (Oracle)
2023-07-10 23:43 ` Luis Chamberlain
2023-07-11 0:03 ` Matthew Wilcox [this message]
2023-07-11 6:30 ` Christoph Hellwig
2023-07-11 20:05 ` Kent Overstreet
2023-07-13 4:42 ` Darrick J. Wong
2023-07-13 13:46 ` Matthew Wilcox
2023-07-10 13:02 ` [PATCH v4 2/9] iov_iter: Add copy_folio_from_iter_atomic() Matthew Wilcox (Oracle)
2023-07-11 6:31 ` Christoph Hellwig
2023-07-11 20:46 ` Matthew Wilcox
2023-07-24 15:56 ` Darrick J. Wong
2023-07-10 13:02 ` [PATCH v4 3/9] iomap: Remove large folio handling in iomap_invalidate_folio() Matthew Wilcox (Oracle)
2023-07-10 13:02 ` [PATCH v4 4/9] doc: Correct the description of ->release_folio Matthew Wilcox (Oracle)
2023-07-13 4:43 ` Darrick J. Wong
2023-07-10 13:02 ` [PATCH v4 5/9] iomap: Remove unnecessary test from iomap_release_folio() Matthew Wilcox (Oracle)
2023-07-13 4:45 ` Darrick J. Wong
2023-07-13 5:25 ` Ritesh Harjani
2023-07-13 5:33 ` Darrick J. Wong
2023-07-13 5:51 ` Ritesh Harjani
2023-07-10 13:02 ` [PATCH v4 6/9] filemap: Add fgf_t typedef Matthew Wilcox (Oracle)
2023-07-13 4:47 ` Darrick J. Wong
2023-07-13 5:08 ` Kent Overstreet
2023-07-10 13:02 ` [PATCH v4 7/9] filemap: Allow __filemap_get_folio to allocate large folios Matthew Wilcox (Oracle)
2023-07-10 23:58 ` Luis Chamberlain
2023-07-11 0:07 ` Matthew Wilcox
2023-07-11 0:21 ` Luis Chamberlain
2023-07-11 0:42 ` Matthew Wilcox
2023-07-11 0:47 ` Dave Chinner
2023-07-11 0:13 ` Kent Overstreet
2023-07-13 4:50 ` Darrick J. Wong
2023-07-13 5:04 ` Kent Overstreet
2023-07-13 14:42 ` Matthew Wilcox
2023-07-13 15:19 ` Kent Overstreet
2023-07-10 13:02 ` [PATCH v4 8/9] iomap: Create large folios in the buffered write path Matthew Wilcox (Oracle)
2023-07-13 4:56 ` Darrick J. Wong
2023-07-10 13:02 ` [PATCH v4 9/9] iomap: Copy larger chunks from userspace Matthew Wilcox (Oracle)
2023-07-13 4:58 ` Darrick J. Wong
2023-07-10 22:55 ` [PATCH v4 0/9] Create large folios in iomap buffered write path Luis Chamberlain
2023-07-10 23:53 ` Matthew Wilcox
2023-07-11 0:01 ` Dave Chinner
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=ZKycRh1ebCg+Yzue@casper.infradead.org \
--to=willy@infradead.org \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=wangyugui@e16-tech.com \
/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;
as well as URLs for NNTP newsgroup(s).