| Message ID | 20241205085217.2086353-1-david@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mm: don't use __GFP_HARDWALL when migrating remote pages | expand |
On Thu, Dec 05, 2024 at 03:43:54PM +0100, Vlastimil Babka wrote: > On 12/5/24 13:12, David Hildenbrand wrote: > > On 05.12.24 09:52, David Hildenbrand wrote: > >> Sending this via the RH SMTP first, because IT doesn't see any obvious > >> problems why the mails shouldn't be reaching linux-mm, so let's see if > >> the problems are gone now. If this doesn't work, I'll resend them > >> using the known-working gmail SMTP. Sorry already for the noise ... > > > > I talked to RH IT, and it looks like the mails get delivered to > > linux-mm@kvack.org just fine, and linux-mm decides to silently drop them. Messages were being dumped into a spam folder as the upstream spam filtering service used for kvack.org was incorrectly tagging them as spam. The folder where these messages were being quarantined in was not the one being checked for the last few months due to the spam tagging changing back on September 8th. > > Does anybody know who maintains linux-mm@kvack.org? Use owner-linux-mm@kvack.org, which has been in place since the mailing list was first created. That is the sender of every mailing list message. Unfortunately, the issue was not flagged to me until today. The mailing list footers that used to let people know about the mailing list contact info previously had to be removed due to the implementation of DKIM enforcement. Even sending emails to majordomo@ per the List-Subscribe: and List-Unsubscribe: headers would have gotten my attention. > > I wrote a mail to > > mbot@kvack.org, but I am pretty sure that is the wrong address. mbot@kvack.org is a spam trap. Do not send emails there unless you want to be marked as a spam sender. > AFAIK it's Benjamin, CC'd It should now be fixed as I have tweaked the spam filtering rules. The messages misfiled as spam since September 8th have now been delivered. I'm shocked that nobody bothered reporting this until now. Please do not report mailing list issues to the mailing list. I simply do not have the time / energy to scan the thousands of messages that fly by every week. Cheers, -ben
On 05.12.24 16:42, Benjamin LaHaise wrote: > On Thu, Dec 05, 2024 at 03:43:54PM +0100, Vlastimil Babka wrote: >> On 12/5/24 13:12, David Hildenbrand wrote: >>> On 05.12.24 09:52, David Hildenbrand wrote: >>>> Sending this via the RH SMTP first, because IT doesn't see any obvious >>>> problems why the mails shouldn't be reaching linux-mm, so let's see if >>>> the problems are gone now. If this doesn't work, I'll resend them >>>> using the known-working gmail SMTP. Sorry already for the noise ... >>> >>> I talked to RH IT, and it looks like the mails get delivered to >>> linux-mm@kvack.org just fine, and linux-mm decides to silently drop them. > > Messages were being dumped into a spam folder as the upstream spam > filtering service used for kvack.org was incorrectly tagging them as spam. > The folder where these messages were being quarantined in was not the one > being checked for the last few months due to the spam tagging changing > back on September 8th. Ah that explains it, > >>> Does anybody know who maintains linux-mm@kvack.org? > > Use owner-linux-mm@kvack.org, which has been in place since the mailing > list was first created. That is the sender of every mailing list message. Ah! > > Unfortunately, the issue was not flagged to me until today. The mailing > list footers that used to let people know about the mailing list contact > info previously had to be removed due to the implementation of DKIM > enforcement. Even sending emails to majordomo@ per the List-Subscribe: > and List-Unsubscribe: headers would have gotten my attention. Yeah, I tried hard finding a contact, and apparently ... > >>> I wrote a mail to >>> mbot@kvack.org, but I am pretty sure that is the wrong address. > > mbot@kvack.org is a spam trap. Do not send emails there unless you want > to be marked as a spam sender. ... all I found was a trap :) (guess I'm now a swam sender ;) ) > >> AFAIK it's Benjamin, CC'd > > It should now be fixed as I have tweaked the spam filtering rules. Thanks! > The > messages misfiled as spam since September 8th have now been delivered. > I'm shocked that nobody bothered reporting this until now. Hm, I sent quite a bunch of patches after September 8th, and I think they mostly got delivered. For me, it started ~1 week ago. > Please do not > report mailing list issues to the mailing list. I simply do not have the > time / energy to scan the thousands of messages that fly by every week. Now that I know how to contact you, that will obviously be my first choice. Thanks!
Sending this via the RH SMTP first, because IT doesn't see any obvious problems why the mails shouldn't be reaching linux-mm, so let's see if the problems are gone now. If this doesn't work, I'll resend them using the known-working gmail SMTP. Sorry already for the noise ... --- __GFP_HARDWALL means that we will be respecting the cpuset of the caller when allocating a page. However, when we are migrating remote allocations (pages allocated from other context), the cpuset of the current context is irrelevant. For memory offlining + alloc_contig_*(), this is rather obvious. There might be other such page migration users, let's start with the obvious ones. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Oscar Salvador <osalvador@suse.de> Cc: Zi Yan <ziy@nvidia.com> David Hildenbrand (2): mm/page_alloc: don't use __GFP_HARDWALL when migrating pages via alloc_contig*() mm/memory_hotplug: don't use __GFP_HARDWALL when migrating pages via memory offlining mm/memory_hotplug.c | 2 +- mm/page_alloc.c | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-)