* [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 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 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 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 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
* 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
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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.