From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] Fix zero_user_segments() with start > end
Date: Sat, 27 Feb 2021 12:36:04 +0900 [thread overview]
Message-ID: <87zgzq89nf.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <20210226205139.GI2723601@casper.infradead.org> (Matthew Wilcox's message of "Fri, 26 Feb 2021 20:51:39 +0000")
Matthew Wilcox <willy@infradead.org> writes:
> On Sat, Feb 27, 2021 at 01:11:35AM +0900, OGAWA Hirofumi wrote:
>> zero_user_segments() is used from __block_write_begin_int(), for
>> example like the following
>>
>> zero_user_segments(page, 4096, 1024, 512, 918)
>>
>> But new zero_user_segments() implements for HIGMEM + TRANSPARENT_HUGEPAGE
>> doesn't handle "start > end" case correctly, and hits BUG_ON(). (we
>> can fix __block_write_begin_int() instead though, it is the old and
>> multiple usage)
>
> Why don't we just take out the BUG_ON instead? The function doesn't
> actually do the wrong thing.
end1 is underflow with
if (start1 >= PAGE_SIZE) {
start1 -= PAGE_SIZE;
end1 -= PAGE_SIZE;
}
>> Also it calls kmap_atomic() unnecessary while start == end == 0.
>
> I'm OK with that. It always used to do that.
Old one is only one page, so it is always necessary if start1/end1 or
start2/end2 is valid range. But this one is multiple pages, so there are
completely unnecessary pages possibly.
>> Cc: <stable@vger.kernel.org>
>> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>
> Fixes: 0060ef3b4e6d ("mm: support THPs in zero_user_segments")
OK.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
prev parent reply other threads:[~2021-02-27 3:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-26 16:11 [PATCH] Fix zero_user_segments() with start > end OGAWA Hirofumi
2021-02-26 20:51 ` Matthew Wilcox
2021-02-27 3:36 ` OGAWA Hirofumi [this message]
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=87zgzq89nf.fsf@mail.parknet.co.jp \
--to=hirofumi@mail.parknet.co.jp \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.