Re: [patch 06/67] mm: factor out next_present_section_nr()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



More signs of your - or somebody elses - email scripts being broken:

On Tue, Feb 4, 2020 at 1:34 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> From: David Hildenbrand <david@xxxxxxxxxx>
> Subject: mm: factor out next_present_section_nr()
>
> Let's move it to the header and use the shorter variant from
> mm/page_alloc.c (the original one will also check
> "__highest_present_section_nr + 1", which is not necessary).  While at it,
> make the section_nr in next_pfn() const.
>
> In next_pfn(), we now return section_nr_to_pfn(-1) instead of -1 once we
> exceed __highest_present_section_nr, which doesn't make a difference i= n
> the caller as it is big enough (>=3D all sane end_pfn).

Here, look at that "i= n". It looks like it was a MIME line-break (so
"in" was MIME-encoded and turned into "i=\nn") followed by you or
David re-flowing the text without MIME-decoding it.

And note the ">=3D" thing. It should be just ">=" but again there is
left-over crud from using MIME-encoded data without decoding it.

I am noticing that this has apparently happened before too. And maybe
it's not you. Maybe it's David Hildenbrand that has sent you already
corrupted data.

Doing a

    git log --grep="=3D"

shows that this mistake has been done by others before. But it's not
_that_ common. I find 25 occurrences of that "=3D" thing in the logs
over the whole history of the kernel.

The "=\n" thing is much harder to grep for quite that trivially, or
the other "random utf8 encoded as MIME and never decoded properly"
stuff.

But the fact that I found at least _two_ of these cases in just this
series, and it had that broken coverletter too, makes me go "Hmm".

I tried to look for other cases, but those two emails (both from David
Hildenbrand, soo...) were the only ones I found in this series of 67.

I can fix them up, of course, but I really hate how somebody has some
workflow that generates this corruption.

MIME corruption in the patches themselves tends to be much more
obvious ("it doesn't apply" or "it no longer builds"). But in the
commit message it's not always clear. So please be *careful*.

I'm jetlagged in Cambridge UK and was going to apply this series since
I was awake anyway, but now I'm not sure I should do that.

At a minimum I want to know what the base commit was supposed to be..

             Linus




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux