Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   David Hildenbrand <david@redhat.com>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH v2 1/2] mm/memory_hotplug: simplify calculation of number of pages in __remove_pages()
Date:   Sun, 29 Mar 2020 22:17:46 +0200
Message-Id: <DFA2A279-A6B4-4F0C-A8B9-38E1A7A6B400@redhat.com>
References: <CAHk-=wjEk_smqiRh4-JosHsRxzhedJddGf5EQV0JxqZtHYMdkA@mail.gmail.com>
Cc:     David Hildenbrand <david@redhat.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux-MM <linux-mm@kvack.org>,
        Segher Boessenkool <segher@kernel.crashing.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Oscar Salvador <osalvador@suse.de>,
        Michal Hocko <mhocko@kernel.org>, Baoquan He <bhe@redhat.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Wei Yang <richardw.yang@linux.intel.com>
In-Reply-To: <CAHk-=wjEk_smqiRh4-JosHsRxzhedJddGf5EQV0JxqZtHYMdkA@mail.gmail.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> Am 29.03.2020 um 22:10 schrieb Linus Torvalds <torvalds@linux-foundation.o=
rg>:
>=20
> =EF=BB=BFOn Sun, Mar 29, 2020 at 12:19 PM David Hildenbrand <david@redhat.=
com> wrote:
>>=20
>> This patch seems to have another of these weird MIME crap in it. (my
>> other patches in -next seem to be fine)
>>=20
>> See
>>=20
>> https://lore.kernel.org/linux-mm/20200228095819.10750-2-david@redhat.com/=
raw
>=20
> That email actually looks fine.
>=20
> Yes, it has that
>=20
>   fro=3D
>   m
>=20
> pattern, but it also has
>=20
>   Content-Transfer-Encoding: quoted-printable
>=20
> so the recipient should be doing the right thing with that pattern.
>=20
> The patch itself also has MIME encoding in it:
>=20
>   - cur_nr_pages =3D3D min(end_pfn - pfn, -(pfn | PAGE_SECTION_MASK));
>   + cur_nr_pages =3D3D min(end_pfn - pfn,
>=20
> so the patch wouldn't even apply unless the recipient did the proper
> MIME decode of the message.
>=20
> That's also why the non-raw message looks fine:
>=20
>  https://lore.kernel.org/linux-mm/20200228095819.10750-2-david@redhat.com/=

>=20
> because the raw message data has the proper encoding information.
>=20
> In contrast, look at the email that Andrew sent me and that I complained a=
bout:
>=20
>   https://lore.kernel.org/linux-mm/20200329021719.MBKzW0xSl%25akpm@linux-f=
oundation.org/
>=20
> and notice how that *non-raw* email has that
>=20
>   Withou=3D
>   t
>=20
> pattern in it. And when you look at the raw one:
>=20
>  https://lore.kernel.org/linux-mm/20200329021719.MBKzW0xSl%25akpm@linux-fo=
undation.org/raw
>=20
> it has no content transfer encoding line in the headers.

Interesting, at least the patch in -next is messed up. I remember Andrew ada=
pted some scripts, maybe this is a leftover.

Cheers!

>=20
>                 Linus
>=20