From: Oscar Salvador <osalvador@suse.de>
To: David Hildenbrand <david@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Vlastimil Babka <vbabka@suse.cz>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Harry Yoo <harry.yoo@oracle.com>, Rakie Kim <rakie.kim@sk.com>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 03/10] mm,memory_hotplug: Implement numa node notifier
Date: Mon, 16 Jun 2025 10:30:19 +0200 [thread overview]
Message-ID: <aE_WG6bnjtLBzCp8@localhost.localdomain> (raw)
In-Reply-To: <2bec8b53-f788-493e-a76e-1f804ed3aa0c@redhat.com>
On Tue, Jun 10, 2025 at 10:10:21AM +0200, David Hildenbrand wrote:
> On 09.06.25 11:21, Oscar Salvador wrote:
> > +The first argument of the callback function (self) is a pointer to the block
> > +of the notifier chain that points to the callback function itself.
> > +The second argument (action) is one of the event types described above.
> > +The third argument (arg) passes a pointer of struct node_notify::
> > +
> > + struct node_notify {
> > + int nid;
> > + }
> > +
> > +- nid is the node we are adding or removing memory to.
> > +
> > + If nid >= 0, callback should create/discard structures for the
> > + node if necessary.
>
> Likely that should be removed?
Yes, indeed.
>
> It' probably worth mentioning that one might get notified about
> NODE_CANCEL_ADDING_FIRST_MEMORY even though never notified for
> NODE_ADDING_FIRST_MEMORY. (same for removing)
>
> I recall this can happen if one of the NODE_ADDING_FIRST_MEMORY notifiers
> fails.
>
> (same applies to MEM_CANCEL_*)
>
> Consequently, we might simplify the cancel_mem_notifier_on_err etc stuff,
> simply unconditionally calling the cancel counterparts.
So, I managed to do another respin with all feedback included, but I
left this one for the end, and here I'm.
It's true, currently users can get notified about e.g: MEM_CANCE_ONLINE without
going through MEM_GOING_ONLINE if another user fails for the latter, but I'm
trying to workaround the fact why that's not a problem.
Because assume you have a user of MEM_CANCEL_ONLINE, who thinks it got called
for MEM_GOING_ONLINE, while in fact it didn't because some other user fail on
it, and it tries to free some memory it thinks it initialized during MEM_GOING_ONLINE.
Isn't this a bit shaky? I mean, yes, I guess we can put the burden on the users of
the notifiers to not assume anything, but then yes, I think we should document this
as it can lead to potential misbeliefs.
--
Oscar Salvador
SUSE Labs
next prev parent reply other threads:[~2025-06-16 8:30 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-09 9:21 [PATCH v6 00/10] Implement numa node notifier Oscar Salvador
2025-06-09 9:21 ` [PATCH v6 01/10] mm,slub: Do not special case N_NORMAL nodes for slab_nodes Oscar Salvador
2025-06-09 9:21 ` [PATCH v6 02/10] mm,memory_hotplug: Remove status_change_nid_normal and update documentation Oscar Salvador
2025-06-09 9:21 ` [PATCH v6 03/10] mm,memory_hotplug: Implement numa node notifier Oscar Salvador
2025-06-10 8:10 ` David Hildenbrand
2025-06-16 8:30 ` Oscar Salvador [this message]
2025-06-16 8:39 ` David Hildenbrand
2025-06-16 8:50 ` Oscar Salvador
2025-06-16 8:52 ` David Hildenbrand
2025-06-16 11:45 ` Oscar Salvador
2025-06-16 12:21 ` David Hildenbrand
2025-06-16 12:32 ` Oscar Salvador
2025-06-16 12:35 ` David Hildenbrand
2025-06-16 12:55 ` Oscar Salvador
2025-06-09 9:21 ` [PATCH v6 04/10] mm,slub: Use node-notifier instead of memory-notifier Oscar Salvador
2025-06-10 7:50 ` David Hildenbrand
2025-06-09 9:21 ` [PATCH v6 05/10] mm,memory-tiers: " Oscar Salvador
2025-06-10 7:51 ` David Hildenbrand
2025-06-09 9:21 ` [PATCH v6 06/10] drivers,cxl: " Oscar Salvador
2025-06-10 7:51 ` David Hildenbrand
2025-06-09 9:21 ` [PATCH v6 07/10] drivers,hmat: " Oscar Salvador
2025-06-10 7:52 ` David Hildenbrand
2025-06-09 9:21 ` [PATCH v6 08/10] kernel,cpuset: " Oscar Salvador
2025-06-09 9:21 ` [PATCH v6 09/10] mm,mempolicy: " Oscar Salvador
2025-06-10 7:52 ` David Hildenbrand
2025-06-09 9:21 ` [PATCH v6 10/10] mm,memory_hotplug: Drop status_change_nid parameter from memory_notify Oscar Salvador
2025-06-10 7:55 ` David Hildenbrand
2025-06-10 8:02 ` Oscar Salvador
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aE_WG6bnjtLBzCp8@localhost.localdomain \
--to=osalvador@suse.de \
--cc=42.hyeyoo@gmail.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=harry.yoo@oracle.com \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rakie.kim@sk.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.