* [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().
@ 2022-04-01 13:58 Zi Yan
2022-04-01 13:58 ` [PATCH 2/2] mm: wrap __find_buddy_pfn() with a necessary buddy page validation Zi Yan
2022-04-01 14:12 ` [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page() David Hildenbrand
0 siblings, 2 replies; 13+ messages in thread
From: Zi Yan @ 2022-04-01 13:58 UTC (permalink / raw)
To: linux-mm
Cc: Linus Torvalds, Steven Rostedt, David Hildenbrand,
Vlastimil Babka, Mel Gorman, Mike Rapoport, Oscar Salvador,
Andrew Morton, linux-kernel, 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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 2/2] mm: wrap __find_buddy_pfn() with a necessary buddy page validation.
2022-04-01 13:58 [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page() Zi Yan
@ 2022-04-01 13:58 ` Zi Yan
2022-04-01 16:31 ` Linus Torvalds
2022-04-01 14:12 ` [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page() David Hildenbrand
1 sibling, 1 reply; 13+ messages in thread
From: Zi Yan @ 2022-04-01 13:58 UTC (permalink / raw)
To: linux-mm
Cc: Linus Torvalds, Steven Rostedt, David Hildenbrand,
Vlastimil Babka, Mel Gorman, Mike Rapoport, Oscar Salvador,
Andrew Morton, linux-kernel, 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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().
2022-04-01 13:58 [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page() Zi Yan
2022-04-01 13:58 ` [PATCH 2/2] mm: wrap __find_buddy_pfn() with a necessary buddy page validation Zi Yan
@ 2022-04-01 14:12 ` David Hildenbrand
2022-04-01 14:19 ` Zi Yan
1 sibling, 1 reply; 13+ messages in thread
From: David Hildenbrand @ 2022-04-01 14:12 UTC (permalink / raw)
To: Zi Yan, linux-mm
Cc: Linus Torvalds, Steven Rostedt, Vlastimil Babka, Mel Gorman,
Mike Rapoport, Oscar Salvador, Andrew Morton, linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().
2022-04-01 14:12 ` [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page() David Hildenbrand
@ 2022-04-01 14:19 ` Zi Yan
2022-04-01 14:22 ` David Hildenbrand
0 siblings, 1 reply; 13+ messages in thread
From: Zi Yan @ 2022-04-01 14:19 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-mm, Linus Torvalds, Steven Rostedt, Vlastimil Babka,
Mel Gorman, Mike Rapoport, Oscar Salvador, Andrew Morton,
linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().
2022-04-01 14:19 ` Zi Yan
@ 2022-04-01 14:22 ` David Hildenbrand
2022-04-01 14:32 ` David Hildenbrand
0 siblings, 1 reply; 13+ messages in thread
From: David Hildenbrand @ 2022-04-01 14:22 UTC (permalink / raw)
To: Zi Yan
Cc: linux-mm, Linus Torvalds, Steven Rostedt, Vlastimil Babka,
Mel Gorman, Mike Rapoport, Oscar Salvador, Andrew Morton,
linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().
2022-04-01 14:22 ` David Hildenbrand
@ 2022-04-01 14:32 ` David Hildenbrand
2022-04-02 7:45 ` Kalle Valo
0 siblings, 1 reply; 13+ messages in thread
From: David Hildenbrand @ 2022-04-01 14:32 UTC (permalink / raw)
To: Zi Yan
Cc: linux-mm, Linus Torvalds, Steven Rostedt, Vlastimil Babka,
Mel Gorman, Mike Rapoport, Oscar Salvador, Andrew Morton,
linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] mm: wrap __find_buddy_pfn() with a necessary buddy page validation.
2022-04-01 13:58 ` [PATCH 2/2] mm: wrap __find_buddy_pfn() with a necessary buddy page validation Zi Yan
@ 2022-04-01 16:31 ` Linus Torvalds
2022-04-01 16:37 ` Zi Yan
0 siblings, 1 reply; 13+ messages in thread
From: Linus Torvalds @ 2022-04-01 16:31 UTC (permalink / raw)
To: Zi Yan
Cc: Linux-MM, Steven Rostedt, David Hildenbrand, Vlastimil Babka,
Mel Gorman, Mike Rapoport, Oscar Salvador, Andrew Morton,
Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/2] mm: wrap __find_buddy_pfn() with a necessary buddy page validation.
2022-04-01 16:31 ` Linus Torvalds
@ 2022-04-01 16:37 ` Zi Yan
0 siblings, 0 replies; 13+ messages in thread
From: Zi Yan @ 2022-04-01 16:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux-MM, Steven Rostedt, David Hildenbrand, Vlastimil Babka,
Mel Gorman, Mike Rapoport, Oscar Salvador, Andrew Morton,
Linux Kernel Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().
2022-04-01 14:32 ` David Hildenbrand
@ 2022-04-02 7:45 ` Kalle Valo
2022-04-02 7:52 ` Kalle Valo
0 siblings, 1 reply; 13+ messages in thread
From: Kalle Valo @ 2022-04-02 7:45 UTC (permalink / raw)
To: David Hildenbrand
Cc: Zi Yan, linux-mm, Linus Torvalds, Steven Rostedt,
Vlastimil Babka, Mel Gorman, Mike Rapoport, Oscar Salvador,
Andrew Morton, linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().
2022-04-02 7:45 ` Kalle Valo
@ 2022-04-02 7:52 ` Kalle Valo
2022-04-02 12:00 ` Zi Yan
2022-04-04 8:43 ` David Hildenbrand
0 siblings, 2 replies; 13+ messages in thread
From: Kalle Valo @ 2022-04-02 7:52 UTC (permalink / raw)
To: David Hildenbrand
Cc: Zi Yan, linux-mm, Linus Torvalds, Steven Rostedt,
Vlastimil Babka, Mel Gorman, Mike Rapoport, Oscar Salvador,
Andrew Morton, linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().
2022-04-02 7:52 ` Kalle Valo
@ 2022-04-02 12:00 ` Zi Yan
2022-04-04 8:46 ` David Hildenbrand
2022-04-04 8:43 ` David Hildenbrand
1 sibling, 1 reply; 13+ messages in thread
From: Zi Yan @ 2022-04-02 12:00 UTC (permalink / raw)
To: Kalle Valo
Cc: David Hildenbrand, linux-mm, Linus Torvalds, Steven Rostedt,
Vlastimil Babka, Mel Gorman, Mike Rapoport, Oscar Salvador,
Andrew Morton, linux-kernel
[-- 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 --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().
2022-04-02 7:52 ` Kalle Valo
2022-04-02 12:00 ` Zi Yan
@ 2022-04-04 8:43 ` David Hildenbrand
1 sibling, 0 replies; 13+ messages in thread
From: David Hildenbrand @ 2022-04-04 8:43 UTC (permalink / raw)
To: Kalle Valo
Cc: Zi Yan, linux-mm, Linus Torvalds, Steven Rostedt,
Vlastimil Babka, Mel Gorman, Mike Rapoport, Oscar Salvador,
Andrew Morton, linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page().
2022-04-02 12:00 ` Zi Yan
@ 2022-04-04 8:46 ` David Hildenbrand
0 siblings, 0 replies; 13+ messages in thread
From: David Hildenbrand @ 2022-04-04 8:46 UTC (permalink / raw)
To: Zi Yan, Kalle Valo
Cc: linux-mm, Linus Torvalds, Steven Rostedt, Vlastimil Babka,
Mel Gorman, Mike Rapoport, Oscar Salvador, Andrew Morton,
linux-kernel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-04-04 8:46 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-01 13:58 [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page() Zi Yan
2022-04-01 13:58 ` [PATCH 2/2] mm: wrap __find_buddy_pfn() with a necessary buddy page validation Zi Yan
2022-04-01 16:31 ` Linus Torvalds
2022-04-01 16:37 ` Zi Yan
2022-04-01 14:12 ` [PATCH 1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page() David Hildenbrand
2022-04-01 14:19 ` Zi Yan
2022-04-01 14:22 ` David Hildenbrand
2022-04-01 14:32 ` David Hildenbrand
2022-04-02 7:45 ` Kalle Valo
2022-04-02 7:52 ` Kalle Valo
2022-04-02 12:00 ` Zi Yan
2022-04-04 8:46 ` David Hildenbrand
2022-04-04 8:43 ` David Hildenbrand
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).