| Message ID | 20220401135820.1453829-1-zi.yan@sent.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] mm: page_alloc: simplify pageblock migratetype check in __free_one_page(). | expand |
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.
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
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)
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.
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.
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 :)
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
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.
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.
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);