In commit 52fb87c81f11 ("mm/memory_hotplug: cleanup __remove_pages()"),
we cleaned up __remove_pages(), and introduced a shorter variant to
calculate the number of pages to the next section boundary.
Turns out we can make this calculation easier to read. We always want to
have the number of pages (> 0) to the next section boundary, starting from
the current pfn.
We'll clean up __remove_pages() in a follow-up patch and directly make
use of this computation.
Suggested-by: Segher Boessenkool <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Oscar Salvador <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Baoquan He <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Wei Yang <[email protected]>
Signed-off-by: David Hildenbrand <[email protected]>
---
mm/memory_hotplug.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 4a9b3f6c6b37..8fe7e32dad48 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -534,7 +534,8 @@ void __remove_pages(unsigned long pfn, unsigned long nr_pages,
for (; pfn < end_pfn; pfn += cur_nr_pages) {
cond_resched();
/* Select all remaining pages up to the next section boundary */
- cur_nr_pages = min(end_pfn - pfn, -(pfn | PAGE_SECTION_MASK));
+ cur_nr_pages = min(end_pfn - pfn,
+ SECTION_ALIGN_UP(pfn + 1) - pfn);
__remove_section(pfn, cur_nr_pages, map_offset, altmap);
map_offset = 0;
}
--
2.24.1
On 02/28/20 at 10:58am, David Hildenbrand wrote:
> In commit 52fb87c81f11 ("mm/memory_hotplug: cleanup __remove_pages()"),
> we cleaned up __remove_pages(), and introduced a shorter variant to
> calculate the number of pages to the next section boundary.
>
> Turns out we can make this calculation easier to read. We always want to
> have the number of pages (> 0) to the next section boundary, starting from
> the current pfn.
>
> We'll clean up __remove_pages() in a follow-up patch and directly make
> use of this computation.
>
> Suggested-by: Segher Boessenkool <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Cc: Oscar Salvador <[email protected]>
> Cc: Michal Hocko <[email protected]>
> Cc: Baoquan He <[email protected]>
> Cc: Dan Williams <[email protected]>
> Cc: Wei Yang <[email protected]>
> Signed-off-by: David Hildenbrand <[email protected]>
> ---
> mm/memory_hotplug.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 4a9b3f6c6b37..8fe7e32dad48 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -534,7 +534,8 @@ void __remove_pages(unsigned long pfn, unsigned long nr_pages,
> for (; pfn < end_pfn; pfn += cur_nr_pages) {
> cond_resched();
> /* Select all remaining pages up to the next section boundary */
> - cur_nr_pages = min(end_pfn - pfn, -(pfn | PAGE_SECTION_MASK));
> + cur_nr_pages = min(end_pfn - pfn,
> + SECTION_ALIGN_UP(pfn + 1) - pfn);
Reviewed-by: Baoquan He <[email protected]>
On Fri, Feb 28, 2020 at 10:58:18AM +0100, David Hildenbrand wrote:
>In commit 52fb87c81f11 ("mm/memory_hotplug: cleanup __remove_pages()"),
>we cleaned up __remove_pages(), and introduced a shorter variant to
>calculate the number of pages to the next section boundary.
>
>Turns out we can make this calculation easier to read. We always want to
>have the number of pages (> 0) to the next section boundary, starting from
>the current pfn.
>
>We'll clean up __remove_pages() in a follow-up patch and directly make
>use of this computation.
>
>Suggested-by: Segher Boessenkool <[email protected]>
>Cc: Andrew Morton <[email protected]>
>Cc: Oscar Salvador <[email protected]>
>Cc: Michal Hocko <[email protected]>
>Cc: Baoquan He <[email protected]>
>Cc: Dan Williams <[email protected]>
>Cc: Wei Yang <[email protected]>
>Signed-off-by: David Hildenbrand <[email protected]>
Reviewed-by: Wei Yang <[email protected]>
>---
> mm/memory_hotplug.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>index 4a9b3f6c6b37..8fe7e32dad48 100644
>--- a/mm/memory_hotplug.c
>+++ b/mm/memory_hotplug.c
>@@ -534,7 +534,8 @@ void __remove_pages(unsigned long pfn, unsigned long nr_pages,
> for (; pfn < end_pfn; pfn += cur_nr_pages) {
> cond_resched();
> /* Select all remaining pages up to the next section boundary */
>- cur_nr_pages = min(end_pfn - pfn, -(pfn | PAGE_SECTION_MASK));
>+ cur_nr_pages = min(end_pfn - pfn,
>+ SECTION_ALIGN_UP(pfn + 1) - pfn);
> __remove_section(pfn, cur_nr_pages, map_offset, altmap);
> map_offset = 0;
> }
>--
>2.24.1
--
Wei Yang
Help you, Help me
On 28.02.20 10:58, David Hildenbrand wrote:
> In commit 52fb87c81f11 ("mm/memory_hotplug: cleanup __remove_pages()"),
> we cleaned up __remove_pages(), and introduced a shorter variant to
> calculate the number of pages to the next section boundary.
>
> Turns out we can make this calculation easier to read. We always want to
> have the number of pages (> 0) to the next section boundary, starting from
> the current pfn.
@Andrew
This patch seems to have another of these weird MIME crap in it. (my
other patches in -next seem to be fine)
See
https://lore.kernel.org/linux-mm/[email protected]/raw
"
... fro=
m"
should simply be "... from"
--
Thanks,
David / dhildenb
On Sun, Mar 29, 2020 at 12:19 PM David Hildenbrand <[email protected]> wrote:
>
> This patch seems to have another of these weird MIME crap in it. (my
> other patches in -next seem to be fine)
>
> See
>
> https://lore.kernel.org/linux-mm/[email protected]/raw
That email actually looks fine.
Yes, it has that
fro=
m
pattern, but it also has
Content-Transfer-Encoding: quoted-printable
so the recipient should be doing the right thing with that pattern.
The patch itself also has MIME encoding in it:
- cur_nr_pages =3D min(end_pfn - pfn, -(pfn | PAGE_SECTION_MASK));
+ cur_nr_pages =3D min(end_pfn - pfn,
so the patch wouldn't even apply unless the recipient did the proper
MIME decode of the message.
That's also why the non-raw message looks fine:
https://lore.kernel.org/linux-mm/[email protected]/
because the raw message data has the proper encoding information.
In contrast, look at the email that Andrew sent me and that I complained about:
https://lore.kernel.org/linux-mm/20200329021719.MBKzW0xSl%[email protected]/
and notice how that *non-raw* email has that
Withou=
t
pattern in it. And when you look at the raw one:
https://lore.kernel.org/linux-mm/20200329021719.MBKzW0xSl%[email protected]/raw
it has no content transfer encoding line in the headers.
Linus
On Sun, Mar 29, 2020 at 1:09 PM Linus Torvalds
<[email protected]> wrote:
>
> In contrast, look at the email that Andrew sent me and that I complained about:
>
> https://lore.kernel.org/linux-mm/20200329021719.MBKzW0xSl%[email protected]/
Hmm. I'm trying to figure out how and where Andrew got the original from you.
There's
https://lore.kernel.org/linux-mm/[email protected]/raw
but again, that one actually looks fine. It has that
Content-Transfer-Encoding: quoted-printable
header line, but it doesn't even have the "=\n" pattern in the text at
all. It does have MIME encoding in the patch, but that's all fine.
Then there's a new version:
https://lore.kernel.org/linux-mm/[email protected]/raw
and that one *does* have the "Withou=\nt" pattern in it. But it still
has the proper
Content-Transfer-Encoding: quoted-printable
in it, so the recipient should decode it just fine (and again, you can
see that in the non-raw email - it looks just fine).
So your emails on lore look fine. I'm not seeing how that got corrupted.
Linus
On Sun, Mar 29, 2020 at 1:17 PM David Hildenbrand <[email protected]> wrote:
>
> Interesting, at least the patch in -next is messed up. I remember Andrew adapted some scripts, maybe this is a leftover.
It does look like s broken MIME decoding script somewhere.
But it's odd, because as mentioned, Andrew definitely handles MIME in
other places correctly - including your messages when it comes to the
patch data itself. It's only the message above the patch that hasn't
been properly decoded.
Curious.
Linus
> Am 29.03.2020 um 22:10 schrieb Linus Torvalds <[email protected]>:
>
> On Sun, Mar 29, 2020 at 12:19 PM David Hildenbrand <[email protected]> wrote:
>>
>> This patch seems to have another of these weird MIME crap in it. (my
>> other patches in -next seem to be fine)
>>
>> See
>>
>> https://lore.kernel.org/linux-mm/[email protected]/raw
>
> That email actually looks fine.
>
> Yes, it has that
>
> fro=
> m
>
> pattern, but it also has
>
> Content-Transfer-Encoding: quoted-printable
>
> so the recipient should be doing the right thing with that pattern.
>
> The patch itself also has MIME encoding in it:
>
> - cur_nr_pages =3D min(end_pfn - pfn, -(pfn | PAGE_SECTION_MASK));
> + cur_nr_pages =3D min(end_pfn - pfn,
>
> so the patch wouldn't even apply unless the recipient did the proper
> MIME decode of the message.
>
> That's also why the non-raw message looks fine:
>
> https://lore.kernel.org/linux-mm/[email protected]/
>
> because the raw message data has the proper encoding information.
>
> In contrast, look at the email that Andrew sent me and that I complained about:
>
> https://lore.kernel.org/linux-mm/20200329021719.MBKzW0xSl%[email protected]/
>
> and notice how that *non-raw* email has that
>
> Withou=
> t
>
> pattern in it. And when you look at the raw one:
>
> https://lore.kernel.org/linux-mm/20200329021719.MBKzW0xSl%[email protected]/raw
>
> it has no content transfer encoding line in the headers.
Interesting, at least the patch in -next is messed up. I remember Andrew adapted some scripts, maybe this is a leftover.
Cheers!
>
> Linus
>
> Am 29.03.2020 um 22:19 schrieb Linus Torvalds <[email protected]>:
>
> On Sun, Mar 29, 2020 at 1:09 PM Linus Torvalds
> <[email protected]> wrote:
>>
>> In contrast, look at the email that Andrew sent me and that I complained about:
>>
>> https://lore.kernel.org/linux-mm/20200329021719.MBKzW0xSl%[email protected]/
>
> Hmm. I'm trying to figure out how and where Andrew got the original from you.
>
> There's
>
> https://lore.kernel.org/linux-mm/[email protected]/raw
>
> but again, that one actually looks fine. It has that
>
> Content-Transfer-Encoding: quoted-printable
>
> header line, but it doesn't even have the "=\n" pattern in the text at
> all. It does have MIME encoding in the patch, but that's all fine.
>
> Then there's a new version:
>
> https://lore.kernel.org/linux-mm/[email protected]/raw
>
> and that one *does* have the "Withou=\nt" pattern in it. But it still
> has the proper
>
> Content-Transfer-Encoding: quoted-printable
>
> in it, so the recipient should decode it just fine (and again, you can
> see that in the non-raw email - it looks just fine).
>
> So your emails on lore look fine. I'm not seeing how that got corrupted.
*maybe* Andrew updated only the patch description, copying the raw content. Eventually he converts MIME only when importing, so the description got corrupted.
... or the mail he received via cc got messed up by my mailing infrastructure.
Cheers
On Sun, 29 Mar 2020 22:41:18 +0200 David Hildenbrand <[email protected]> wrote:
> > https://lore.kernel.org/linux-mm/[email protected]/raw
> >
> > and that one *does* have the "Withou=\nt" pattern in it. But it still
> > has the proper
> >
> > Content-Transfer-Encoding: quoted-printable
> >
> > in it, so the recipient should decode it just fine (and again, you can
> > see that in the non-raw email - it looks just fine).
> >
> > So your emails on lore look fine. I'm not seeing how that got corrupted.
>
> *maybe* Andrew updated only the patch description, copying the raw content. Eventually he converts MIME only when importing, so the description got corrupted.
>
> ... or the mail he received via cc got messed up by my mailing infrastructure.
Something like that. It's sylpheed being weird. In some situations
(save as...) it will perform the mime conversion but in others (%f in
an action menu) it does not. So for David's patches I do save-as for
the patch and manually edit the mime out of changelog. It's basically
"only David" so I haven't got around to doing anything smarter.
My nightly check-all-the-patches-for-various-cruft script emails me
about =3D but I didn't' have a test for "o=$m". I just added one.
On Mon, Mar 30, 2020 at 3:14 PM Andrew Morton <[email protected]> wrote:
>
> My nightly check-all-the-patches-for-various-cruft script emails me
> about =3D but I didn't' have a test for "o=$m". I just added one.
=3D may be the common one, but =20 and =09 are others that end up
showing up when whitespace gets quoted for various reasons.
Another one is =46 for 'F'. Why? Because some mailers think that
"From" at the beginning of a line is the mbox beginning marker, and
they'll escape any line that begins with "From" to use "=46rom"
instead.
Those mailers are wrong (at a _minimum_ it's "From " with a space, and
you generally should be even stricter than that), but it happens.
And obviously, if there is real 8-bit stuff, you'll get all the real
odd hex noise.
Linus