[PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().

[PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().

[Zi Yan]

From: Zi Yan <ziy@nvidia.com>

Move pageblock migratetype check code in the while loop to simplify the
logic. It also saves redundant buddy page checking code.

Suggested-by: Vlastimil Babka <vbabka@suse.cz>
Link: https://lore.kernel.org/linux-mm/27ff69f9-60c5-9e59-feb2-295250077551@suse.cz/
Signed-off-by: Zi Yan <ziy@nvidia.com>
---
 mm/page_alloc.c | 46 +++++++++++++++++-----------------------------
 1 file changed, 17 insertions(+), 29 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 856473e54155..2ea106146686 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1054,7 +1054,6 @@ static inline void __free_one_page(struct page *page,
 		int migratetype, fpi_t fpi_flags)
 {
 	struct capture_control *capc = task_capc(zone);
-	unsigned int max_order = pageblock_order;
 	unsigned long buddy_pfn;
 	unsigned long combined_pfn;
 	struct page *buddy;
@@ -1070,8 +1069,7 @@ static inline void __free_one_page(struct page *page,
 	VM_BUG_ON_PAGE(pfn & ((1 << order) - 1), page);
 	VM_BUG_ON_PAGE(bad_range(zone, page), page);
 
-continue_merging:
-	while (order < max_order) {
+	while (order < MAX_ORDER - 1) {
 		if (compaction_capture(capc, page, order, migratetype)) {
 			__mod_zone_freepage_state(zone, -(1 << order),
 								migratetype);
@@ -1082,6 +1080,22 @@ static inline void __free_one_page(struct page *page,
 
 		if (!page_is_buddy(page, buddy, order))
 			goto done_merging;
+
+		if (unlikely(order >= pageblock_order)) {
+			/*
+			 * We want to prevent merge between freepages on pageblock
+			 * without fallbacks and normal pageblock. Without this,
+			 * pageblock isolation could cause incorrect freepage or CMA
+			 * accounting or HIGHATOMIC accounting.
+			 */
+			int buddy_mt = get_pageblock_migratetype(buddy);
+
+			if (migratetype != buddy_mt
+					&& (!migratetype_is_mergeable(migratetype) ||
+						!migratetype_is_mergeable(buddy_mt)))
+				goto done_merging;
+		}
+
 		/*
 		 * Our buddy is free or it is CONFIG_DEBUG_PAGEALLOC guard page,
 		 * merge with it and move up one order.
@@ -1095,32 +1109,6 @@ static inline void __free_one_page(struct page *page,
 		pfn = combined_pfn;
 		order++;
 	}
-	if (order < MAX_ORDER - 1) {
-		/* If we are here, it means order is >= pageblock_order.
-		 * We want to prevent merge between freepages on pageblock
-		 * without fallbacks and normal pageblock. Without this,
-		 * pageblock isolation could cause incorrect freepage or CMA
-		 * accounting or HIGHATOMIC accounting.
-		 *
-		 * We don't want to hit this code for the more frequent
-		 * low-order merging.
-		 */
-		int buddy_mt;
-
-		buddy_pfn = __find_buddy_pfn(pfn, order);
-		buddy = page + (buddy_pfn - pfn);
-
-		if (!page_is_buddy(page, buddy, order))
-			goto done_merging;
-		buddy_mt = get_pageblock_migratetype(buddy);
-
-		if (migratetype != buddy_mt
-				&& (!migratetype_is_mergeable(migratetype) ||
-					!migratetype_is_mergeable(buddy_mt)))
-			goto done_merging;
-		max_order = order + 1;
-		goto continue_merging;
-	}
 
 done_merging:
 	set_buddy_order(page, order);
-- 
2.35.1

[PATCH 2/2] mm: wrap __find_buddy_pfn() with a necessary buddy page validation.

[Zi Yan]

From: Zi Yan <ziy@nvidia.com>

Whenever the buddy of a page is found from __find_buddy_pfn(),
page_is_buddy() should be used to check its validity. Add a helper
function find_buddy_page_pfn() to find the buddy page and do the check
together.

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/linux-mm/CAHk-=wji_AmYygZMTsPMdJ7XksMt7kOur8oDfDdniBRMjm4VkQ@mail.gmail.com/
Signed-off-by: Zi Yan <ziy@nvidia.com>
---
 mm/internal.h       | 24 ++---------------
 mm/page_alloc.c     | 63 ++++++++++++++++++++++++++++++++++++++-------
 mm/page_isolation.c |  9 +++----
 3 files changed, 59 insertions(+), 37 deletions(-)

diff --git a/mm/internal.h b/mm/internal.h
index 876e66237c89..791653c95bf1 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -211,28 +211,8 @@ struct alloc_context {
 	bool spread_dirty_pages;
 };
 
-/*
- * Locate the struct page for both the matching buddy in our
- * pair (buddy1) and the combined O(n+1) page they form (page).
- *
- * 1) Any buddy B1 will have an order O twin B2 which satisfies
- * the following equation:
- *     B2 = B1 ^ (1 << O)
- * For example, if the starting buddy (buddy2) is #8 its order
- * 1 buddy is #10:
- *     B2 = 8 ^ (1 << 1) = 8 ^ 2 = 10
- *
- * 2) Any buddy B will have an order O+1 parent P which
- * satisfies the following equation:
- *     P = B & ~(1 << O)
- *
- * Assumption: *_mem_map is contiguous at least up to MAX_ORDER
- */
-static inline unsigned long
-__find_buddy_pfn(unsigned long page_pfn, unsigned int order)
-{
-	return page_pfn ^ (1 << order);
-}
+extern bool find_buddy_page_pfn(struct page *page, unsigned int order,
+				struct page **buddy, unsigned long *buddy_pfn);
 
 extern struct page *__pageblock_pfn_to_page(unsigned long start_pfn,
 				unsigned long end_pfn, struct zone *zone);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 2ea106146686..89490b9a19ef 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -998,6 +998,54 @@ static inline void del_page_from_free_list(struct page *page, struct zone *zone,
 	zone->free_area[order].nr_free--;
 }
 
+/*
+ * Locate the struct page for both the matching buddy in our
+ * pair (buddy1) and the combined O(n+1) page they form (page).
+ *
+ * 1) Any buddy B1 will have an order O twin B2 which satisfies
+ * the following equation:
+ *     B2 = B1 ^ (1 << O)
+ * For example, if the starting buddy (buddy2) is #8 its order
+ * 1 buddy is #10:
+ *     B2 = 8 ^ (1 << 1) = 8 ^ 2 = 10
+ *
+ * 2) Any buddy B will have an order O+1 parent P which
+ * satisfies the following equation:
+ *     P = B & ~(1 << O)
+ *
+ * Assumption: *_mem_map is contiguous at least up to MAX_ORDER
+ */
+static inline unsigned long
+__find_buddy_pfn(unsigned long page_pfn, unsigned int order)
+{
+	return page_pfn ^ (1 << order);
+}
+
+
+/*
+ * Find the buddy of @page and validate it.
+ * @page: The input page
+ * @order: Order of the input page
+ * @buddy: Output pointer to the buddy page
+ * @buddy_pfn: Output pointer to the buddy pfn
+ *
+ * The found buddy can be a non PageBuddy, out of @page's zone, or its order is
+ * not the same as @page. The validation is necessary before use it.
+ *
+ * Return: true if the found buddy page is valid or false if not.
+ *
+ */
+bool find_buddy_page_pfn(struct page *page, unsigned int order,
+			 struct page **buddy, unsigned long *buddy_pfn)
+{
+	unsigned long pfn = page_to_pfn(page);
+
+	*buddy_pfn = __find_buddy_pfn(pfn, order);
+	*buddy = page + (*buddy_pfn - pfn);
+
+	return page_is_buddy(page, *buddy, order);
+}
+
 /*
  * If this is not the largest possible page, check if the buddy
  * of the next-highest order is free. If it is, it's possible
@@ -1011,17 +1059,16 @@ buddy_merge_likely(unsigned long pfn, unsigned long buddy_pfn,
 		   struct page *page, unsigned int order)
 {
 	struct page *higher_page, *higher_buddy;
-	unsigned long combined_pfn;
+	unsigned long higher_page_pfn;
 
 	if (order >= MAX_ORDER - 2)
 		return false;
 
-	combined_pfn = buddy_pfn & pfn;
-	higher_page = page + (combined_pfn - pfn);
-	buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
-	higher_buddy = higher_page + (buddy_pfn - combined_pfn);
+	higher_page_pfn = buddy_pfn & pfn;
+	higher_page = page + (higher_page_pfn - pfn);
 
-	return page_is_buddy(higher_page, higher_buddy, order + 1);
+	return find_buddy_page_pfn(higher_page, order + 1,
+			&higher_buddy, &buddy_pfn);
 }
 
 /*
@@ -1075,10 +1122,8 @@ static inline void __free_one_page(struct page *page,
 								migratetype);
 			return;
 		}
-		buddy_pfn = __find_buddy_pfn(pfn, order);
-		buddy = page + (buddy_pfn - pfn);
 
-		if (!page_is_buddy(page, buddy, order))
+		if (!find_buddy_page_pfn(page, order, &buddy, &buddy_pfn))
 			goto done_merging;
 
 		if (unlikely(order >= pageblock_order)) {
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index f67c4c70f17f..743c52f489f5 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -70,7 +70,7 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype)
 	unsigned long flags, nr_pages;
 	bool isolated_page = false;
 	unsigned int order;
-	unsigned long pfn, buddy_pfn;
+	unsigned long buddy_pfn;
 	struct page *buddy;
 
 	zone = page_zone(page);
@@ -89,11 +89,8 @@ static void unset_migratetype_isolate(struct page *page, unsigned migratetype)
 	if (PageBuddy(page)) {
 		order = buddy_order(page);
 		if (order >= pageblock_order && order < MAX_ORDER - 1) {
-			pfn = page_to_pfn(page);
-			buddy_pfn = __find_buddy_pfn(pfn, order);
-			buddy = page + (buddy_pfn - pfn);
-
-			if (!is_migrate_isolate_page(buddy)) {
+			if (find_buddy_page_pfn(page, order, &buddy, &buddy_pfn) &&
+			    !is_migrate_isolate_page(buddy)) {
 				isolated_page = !!__isolate_free_page(page, order);
 				/*
 				 * Isolating a free page in an isolated pageblock
-- 
2.35.1

Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().

[David Hildenbrand]

On 01.04.22 15:58, Zi Yan wrote:

It's weird, your mails arrive on my end as empty body with attachment. I
first suspected Thunderbird, but I get the same result on the google
mail web client.

Not sure why that happens.


-- 
Thanks,

David / dhildenb

Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().

[Zi Yan]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

On 1 Apr 2022, at 10:12, David Hildenbrand wrote:

> On 01.04.22 15:58, Zi Yan wrote:
>
> It's weird, your mails arrive on my end as empty body with attachment. I
> first suspected Thunderbird, but I get the same result on the google
> mail web client.
>
> Not sure why that happens.

No idea. They look fine (except mangled links by outlook) on my outlook
desk client and web client on my side. lore looks OK too:
https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/

--
Best Regards,
Yan, Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().

[David Hildenbrand]

On 01.04.22 16:19, Zi Yan wrote:
> On 1 Apr 2022, at 10:12, David Hildenbrand wrote:
> 
>> On 01.04.22 15:58, Zi Yan wrote:
>>
>> It's weird, your mails arrive on my end as empty body with attachment. I
>> first suspected Thunderbird, but I get the same result on the google
>> mail web client.
>>
>> Not sure why that happens.
> 
> No idea. They look fine (except mangled links by outlook) on my outlook
> desk client and web client on my side. lore looks OK too:
> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/

I can spot in the raw mail I receive

"Content-Type: application/octet-stream; x-default=true"

But that seems to differ to the lore mail:

https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/raw


Maybe something in my mail server chain decides to do some nasty
conversion (grml, wouldn't be the first time)

-- 
Thanks,

David / dhildenb

Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().

[David Hildenbrand]

On 01.04.22 16:22, David Hildenbrand wrote:
> On 01.04.22 16:19, Zi Yan wrote:
>> On 1 Apr 2022, at 10:12, David Hildenbrand wrote:
>>
>>> On 01.04.22 15:58, Zi Yan wrote:
>>>
>>> It's weird, your mails arrive on my end as empty body with attachment. I
>>> first suspected Thunderbird, but I get the same result on the google
>>> mail web client.
>>>
>>> Not sure why that happens.
>>
>> No idea. They look fine (except mangled links by outlook) on my outlook
>> desk client and web client on my side. lore looks OK too:
>> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/
> 
> I can spot in the raw mail I receive
> 
> "Content-Type: application/octet-stream; x-default=true"
> 
> But that seems to differ to the lore mail:
> 
> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/raw
> 
> 
> Maybe something in my mail server chain decides to do some nasty
> conversion (grml, wouldn't be the first time)
> 

Weird thing is that this only happens with your mails. I opened an
internal ticket, sorry for the noise.

-- 
Thanks,

David / dhildenb

Re: [PATCH 2/2] mm: wrap __find_buddy_pfn() with a necessary buddy page validation.

[Linus Torvalds]

On Fri, Apr 1, 2022 at 6:58 AM Zi Yan <zi.yan@sent.com> wrote:
>
> +extern bool find_buddy_page_pfn(struct page *page, unsigned int order,
> +                               struct page **buddy, unsigned long *buddy_pfn);

Wouldn't it make more sense to just return the 'struct page *buddy'
here, instead of the 'bool'?

So a NULL buddy means the obvious "no buddy found".

I dislike those "pass return value by reference" in general, and the
above has _two_ of them.

We can get rid of at least one very obviously.

           Linus

Re: [PATCH 2/2] mm: wrap __find_buddy_pfn() with a necessary buddy page validation.

[Zi Yan]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On 1 Apr 2022, at 12:31, Linus Torvalds wrote:

> On Fri, Apr 1, 2022 at 6:58 AM Zi Yan <zi.yan@sent.com> wrote:
>>
>> +extern bool find_buddy_page_pfn(struct page *page, unsigned int order,
>> +                               struct page **buddy, unsigned long *buddy_pfn);
>
> Wouldn't it make more sense to just return the 'struct page *buddy'
> here, instead of the 'bool'?
>
> So a NULL buddy means the obvious "no buddy found".
>
> I dislike those "pass return value by reference" in general, and the
> above has _two_ of them.
>
> We can get rid of at least one very obviously.

Sure. We can get rid of both and calculate buddy_pfn from buddy after
a successful call.


--
Best Regards,
Yan, Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().

[Kalle Valo]

David Hildenbrand <david@redhat.com> writes:

> On 01.04.22 16:22, David Hildenbrand wrote:
>> On 01.04.22 16:19, Zi Yan wrote:
>>> On 1 Apr 2022, at 10:12, David Hildenbrand wrote:
>>>
>>>> On 01.04.22 15:58, Zi Yan wrote:
>>>>
>>>> It's weird, your mails arrive on my end as empty body with attachment. I
>>>> first suspected Thunderbird, but I get the same result on the google
>>>> mail web client.
>>>>
>>>> Not sure why that happens.
>>>
>>> No idea. They look fine (except mangled links by outlook) on my outlook
>>> desk client and web client on my side. lore looks OK too:
>>> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/
>> 
>> I can spot in the raw mail I receive
>> 
>> "Content-Type: application/octet-stream; x-default=true"
>> 
>> But that seems to differ to the lore mail:
>> 
>> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/raw
>> 
>> 
>> Maybe something in my mail server chain decides to do some nasty
>> conversion (grml, wouldn't be the first time)
>> 
>
> Weird thing is that this only happens with your mails. I opened an
> internal ticket, sorry for the noise.

Zi's patch emails I received didn't have Content-Type, that might have
something to do with this. (But his reply later in the thread did have
one.) Also last week I got one patch email with no Content-Type either
and my Gnus decided to convert it to octet-stream, I guess to be on the
safe side. No idea if something similar is happening to you, but wanted
to mention it anyway.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().

[Kalle Valo]

Kalle Valo <kvalo@kernel.org> writes:

> David Hildenbrand <david@redhat.com> writes:
>
>> On 01.04.22 16:22, David Hildenbrand wrote:
>>> On 01.04.22 16:19, Zi Yan wrote:
>>>> On 1 Apr 2022, at 10:12, David Hildenbrand wrote:
>>>>
>>>>> On 01.04.22 15:58, Zi Yan wrote:
>>>>>
>>>>> It's weird, your mails arrive on my end as empty body with attachment. I
>>>>> first suspected Thunderbird, but I get the same result on the google
>>>>> mail web client.
>>>>>
>>>>> Not sure why that happens.
>>>>
>>>> No idea. They look fine (except mangled links by outlook) on my outlook
>>>> desk client and web client on my side. lore looks OK too:
>>>> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/
>>> 
>>> I can spot in the raw mail I receive
>>> 
>>> "Content-Type: application/octet-stream; x-default=true"
>>> 
>>> But that seems to differ to the lore mail:
>>> 
>>> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/raw
>>> 
>>> 
>>> Maybe something in my mail server chain decides to do some nasty
>>> conversion (grml, wouldn't be the first time)
>>> 
>>
>> Weird thing is that this only happens with your mails. I opened an
>> internal ticket, sorry for the noise.
>
> Zi's patch emails I received didn't have Content-Type, that might have
> something to do with this. (But his reply later in the thread did have
> one.) Also last week I got one patch email with no Content-Type either
> and my Gnus decided to convert it to octet-stream, I guess to be on the
> safe side. No idea if something similar is happening to you, but wanted
> to mention it anyway.

Just to clarify, I assumed Gnus was doing the conversion to octet-stream
but I never verified that.

Heh, interestingly enough that patch was sent from redhat.com:

https://lore.kernel.org/all/877d8eyz61.fsf@kernel.org/

Is that just a coincidence or are Redhat servers doing something
strange? If you find out, do let me know. I'm very curious :)

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().

[Zi Yan]

[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]

On 2 Apr 2022, at 3:52, Kalle Valo wrote:

> Kalle Valo <kvalo@kernel.org> writes:
>
>> David Hildenbrand <david@redhat.com> writes:
>>
>>> On 01.04.22 16:22, David Hildenbrand wrote:
>>>> On 01.04.22 16:19, Zi Yan wrote:
>>>>> On 1 Apr 2022, at 10:12, David Hildenbrand wrote:
>>>>>
>>>>>> On 01.04.22 15:58, Zi Yan wrote:
>>>>>>
>>>>>> It's weird, your mails arrive on my end as empty body with attachment. I
>>>>>> first suspected Thunderbird, but I get the same result on the google
>>>>>> mail web client.
>>>>>>
>>>>>> Not sure why that happens.
>>>>>
>>>>> No idea. They look fine (except mangled links by outlook) on my outlook
>>>>> desk client and web client on my side. lore looks OK too:
>>>>> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/
>>>>
>>>> I can spot in the raw mail I receive
>>>>
>>>> "Content-Type: application/octet-stream; x-default=true"
>>>>
>>>> But that seems to differ to the lore mail:
>>>>
>>>> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/raw
>>>>
>>>>
>>>> Maybe something in my mail server chain decides to do some nasty
>>>> conversion (grml, wouldn't be the first time)
>>>>
>>>
>>> Weird thing is that this only happens with your mails. I opened an
>>> internal ticket, sorry for the noise.
>>
>> Zi's patch emails I received didn't have Content-Type, that might have
>> something to do with this. (But his reply later in the thread did have
>> one.) Also last week I got one patch email with no Content-Type either
>> and my Gnus decided to convert it to octet-stream, I guess to be on the
>> safe side. No idea if something similar is happening to you, but wanted
>> to mention it anyway.

The emails I got from linux-mm mailing list do not have Content-Type either,
but the ones I got directly from my git-send-email have it. David is in the
cc list, so the emails sent to him should have Content-Type.

FYI, I sent the emails using git 2.35.1 via fastmail.com and have
transferEncoding=quoted-printable.

>
> Just to clarify, I assumed Gnus was doing the conversion to octet-stream
> but I never verified that.
>
> Heh, interestingly enough that patch was sent from redhat.com:
>
> https://lore.kernel.org/all/877d8eyz61.fsf@kernel.org/
>
> Is that just a coincidence or are Redhat servers doing something
> strange? If you find out, do let me know. I'm very curious :)

--
Best Regards,
Yan, Zi

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 854 bytes --]

Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().

[David Hildenbrand]

On 02.04.22 09:52, Kalle Valo wrote:
> Kalle Valo <kvalo@kernel.org> writes:
> 
>> David Hildenbrand <david@redhat.com> writes:
>>
>>> On 01.04.22 16:22, David Hildenbrand wrote:
>>>> On 01.04.22 16:19, Zi Yan wrote:
>>>>> On 1 Apr 2022, at 10:12, David Hildenbrand wrote:
>>>>>
>>>>>> On 01.04.22 15:58, Zi Yan wrote:
>>>>>>
>>>>>> It's weird, your mails arrive on my end as empty body with attachment. I
>>>>>> first suspected Thunderbird, but I get the same result on the google
>>>>>> mail web client.
>>>>>>
>>>>>> Not sure why that happens.
>>>>>
>>>>> No idea. They look fine (except mangled links by outlook) on my outlook
>>>>> desk client and web client on my side. lore looks OK too:
>>>>> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/
>>>>
>>>> I can spot in the raw mail I receive
>>>>
>>>> "Content-Type: application/octet-stream; x-default=true"
>>>>
>>>> But that seems to differ to the lore mail:
>>>>
>>>> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/raw
>>>>
>>>>
>>>> Maybe something in my mail server chain decides to do some nasty
>>>> conversion (grml, wouldn't be the first time)
>>>>
>>>
>>> Weird thing is that this only happens with your mails. I opened an
>>> internal ticket, sorry for the noise.
>>
>> Zi's patch emails I received didn't have Content-Type, that might have
>> something to do with this. (But his reply later in the thread did have
>> one.) Also last week I got one patch email with no Content-Type either
>> and my Gnus decided to convert it to octet-stream, I guess to be on the
>> safe side. No idea if something similar is happening to you, but wanted
>> to mention it anyway.
> 
> Just to clarify, I assumed Gnus was doing the conversion to octet-stream
> but I never verified that.
> 
> Heh, interestingly enough that patch was sent from redhat.com:
> 
> https://lore.kernel.org/all/877d8eyz61.fsf@kernel.org/
> 
> Is that just a coincidence or are Redhat servers doing something
> strange? If you find out, do let me know. I'm very curious :)
> 

It is strange. Also mails from Andrew result in the same,
unusable/unreadable mails in my inbox. :(

Right now I assume that Mimecast servers try to auto-detecting and
adding "Content-type:", and somehow mess up. And I do think that it
doesn't always mess up; some patch content (encoding?) seems to trigger
that.


-- 
Thanks,

David / dhildenb

Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().

[David Hildenbrand]

On 02.04.22 14:00, Zi Yan wrote:
> On 2 Apr 2022, at 3:52, Kalle Valo wrote:
> 
>> Kalle Valo <kvalo@kernel.org> writes:
>>
>>> David Hildenbrand <david@redhat.com> writes:
>>>
>>>> On 01.04.22 16:22, David Hildenbrand wrote:
>>>>> On 01.04.22 16:19, Zi Yan wrote:
>>>>>> On 1 Apr 2022, at 10:12, David Hildenbrand wrote:
>>>>>>
>>>>>>> On 01.04.22 15:58, Zi Yan wrote:
>>>>>>>
>>>>>>> It's weird, your mails arrive on my end as empty body with attachment. I
>>>>>>> first suspected Thunderbird, but I get the same result on the google
>>>>>>> mail web client.
>>>>>>>
>>>>>>> Not sure why that happens.
>>>>>>
>>>>>> No idea. They look fine (except mangled links by outlook) on my outlook
>>>>>> desk client and web client on my side. lore looks OK too:
>>>>>> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/
>>>>>
>>>>> I can spot in the raw mail I receive
>>>>>
>>>>> "Content-Type: application/octet-stream; x-default=true"
>>>>>
>>>>> But that seems to differ to the lore mail:
>>>>>
>>>>> https://lore.kernel.org/linux-mm/20220401135820.1453829-1-zi.yan@sent.com/raw
>>>>>
>>>>>
>>>>> Maybe something in my mail server chain decides to do some nasty
>>>>> conversion (grml, wouldn't be the first time)
>>>>>
>>>>
>>>> Weird thing is that this only happens with your mails. I opened an
>>>> internal ticket, sorry for the noise.
>>>
>>> Zi's patch emails I received didn't have Content-Type, that might have
>>> something to do with this. (But his reply later in the thread did have
>>> one.) Also last week I got one patch email with no Content-Type either
>>> and my Gnus decided to convert it to octet-stream, I guess to be on the
>>> safe side. No idea if something similar is happening to you, but wanted
>>> to mention it anyway.
> 
> The emails I got from linux-mm mailing list do not have Content-Type either,
> but the ones I got directly from my git-send-email have it. David is in the
> cc list, so the emails sent to him should have Content-Type.

I assume I received them without a Content-type, or mail servers
stripped them, and Mimecast servers (which RH uses) fail to auto-detect
and add a wrong Content-type. Wouldn't be the first time that Mimecast
messed with mail encodings etc, unfortunately.


-- 
Thanks,

David / dhildenb