From: Rakie Kim <rakie.kim@sk.com>
To: akpm@linux-foundation.org
Cc: gourry@gourry.net, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org,
joshua.hahnjy@gmail.com, ying.huang@linux.alibaba.com,
david@redhat.com, Jonathan.Cameron@huawei.com, osalvador@suse.de,
kernel_team@skhynix.com, honggyu.kim@sk.com, yunjeong.mun@sk.com,
rakie.kim@sk.com, Dan Williams <dan.j.williams@intel.com>
Subject: Re: [PATCH v7 2/3] mm/mempolicy: Prepare weighted interleave sysfs for memory hotplug
Date: Thu, 10 Apr 2025 17:06:19 +0900 [thread overview]
Message-ID: <20250410080629.564-1-rakie.kim@sk.com> (raw)
In-Reply-To: <20250410075341.549-1-rakie.kim@sk.com>
On Thu, 10 Apr 2025 16:53:33 +0900 Rakie Kim <rakie.kim@sk.com> wrote:
> On Wed, 9 Apr 2025 11:51:36 -0700 Dan Williams <dan.j.williams@intel.com> wrote:
> > Rakie Kim wrote:
> > > > > > +static void sysfs_wi_node_delete(int nid)
> > > > > > {
> > > > > > - if (!node_attr)
> > > > > > + if (!wi_group->nattrs[nid])
> > > > > > return;
> > > > > > - sysfs_remove_file(parent, &node_attr->kobj_attr.attr);
> > > > > > - kfree(node_attr->kobj_attr.attr.name);
> > > > > > - kfree(node_attr);
> > > > > > +
> > > > > > + sysfs_remove_file(&wi_group->wi_kobj,
> > > > > > + &wi_group->nattrs[nid]->kobj_attr.attr);
> > > > >
> > > > > This still looks broken to me, but I think this is more a problem that
> > > > > was present in the original code.
> > > > >
> > > > > At this point @wi_group's reference count is zero because
> > > > > sysfs_wi_release() has been called. However, it can only be zero if it has
> > > > > properly transitioned through kobject_del() and final kobject_put(). It
> > > > > follows that kobject_del() arranges for kobj->sd to be NULL. That means
> > > > > that this *should* be hitting the WARN() in kernfs_remove_by_name_ns()
> > > > > for the !parent case.
> > > > >
> > > > > So, either you are not triggering that path, or testing that path, but
> > > > > sys_remove_file() of the child attributes should be happening *before*
> > > > > sysfs_wi_release().
> > > > >
> > > > > Did I miss something?
> > > >
> > > > I think the missing change is that sysfs_wi_node_add() failures need to
> > > > be done with a sysfs_wi_node_delete() of the added attrs *before* the
> > > > kobject_del() of @wi_group.
> > >
> > > Hi Dan Williams
> > >
> > > Thank you very much for identifying this potential issue in the code.
> > >
> > > As you pointed out, this seems to be a problem that was already present in
> > > the original implementation, and I agree that it needs to be addressed.
> > >
> > > However, since this issue existed prior to the changes in this patch
> > > series, I believe it would be more appropriate to fix it in a separate
> > > follow-up patch rather than include it here.
> >
> > I tend to disagree. The whole motivation of this series is to get the
> > kobject lifetime handling correct in order to add the new dynamic
> > capability. The claimed correctness fixups are incomplete. There is time
> > to respin this (we are only at -rc1) and get it right before landing the
> > new dynamic capability.
> >
> > One of the outcomes of the "MM Process" topic at LSF/MM was that Andrew
> > wanted more feedback on when patches are not quite ready for prime-time
> > and I think this is an example of a patch set that deserves another spin
> > to meet the stated goals.
> >
> > > I will start preparing a new patch to address this problem, and I would
> > > greatly appreciate it if you could review it once it's ready.
> >
> > Will definitely review it. I will leave to Andrew if he wants an
> > incremental fixup on top of this series, or rebase on top of a fully
> > fixed baseline. My preference is finish fixing all the old kobject()
> > issues and then rebase the new dynamic work on top. Either way, do not
> > be afraid to ask Andrew to replace a series in -mm, that's a sign of the
> > process working as expected.
>
> Thank you very much for your advice, and I completely agree with your
> recommendation. I will immediately ask Andrew to remove this patch series
> from -mm. Then, I will prepare a new version, v8, which properly addresses
> the kobject-related issues you pointed out.
>
> Once again, I sincerely appreciate your thoughtful and detailed feedback.
>
> Rakie
>
To Andrew
I sincerely apologize for the inconvenience. It appears that this commit still
requires additional corrections. I would appreciate it if you could drop the
changes you merged into -mm, mm-new branch yesterday.
<1>
The patch titled
Subject: mm/mempolicy: fix memory leaks in weighted interleave sysfs has been added to the -mm mm-new branch. Its filename is
mm-mempolicy-fix-memory-leaks-in-weighted-interleave-sysfs.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-mempolicy-fix-memory-leaks-in-weighted-interleave-sysfs.patch
<2>
The patch titled
Subject: mm/mempolicy: prepare weighted interleave sysfs for memory hotplug has been added to the -mm mm-new branch. Its filename is
mm-mempolicy-prepare-weighted-interleave-sysfs-for-memory-hotplug.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-mempolicy-prepare-weighted-interleave-sysfs-for-memory-hotplug.patch
<3>
The patch titled
Subject: mm/mempolicy: support memory hotplug in weighted interleave has been added to the -mm mm-new branch. Its filename is
mm-mempolicy-support-memory-hotplug-in-weighted-interleave.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-mempolicy-support-memory-hotplug-in-weighted-interleave.patch
Rakie
next prev parent reply other threads:[~2025-04-10 8:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 7:32 [PATCH v7 0/3] Enhance sysfs handling for memory hotplug in weighted interleave Rakie Kim
2025-04-08 7:32 ` [PATCH v7 1/3] mm/mempolicy: Fix memory leaks in weighted interleave sysfs Rakie Kim
2025-04-08 13:45 ` Joshua Hahn
2025-04-15 15:41 ` Jonathan Cameron
2025-04-08 7:32 ` [PATCH v7 2/3] mm/mempolicy: Prepare weighted interleave sysfs for memory hotplug Rakie Kim
2025-04-08 13:49 ` Joshua Hahn
2025-04-09 3:43 ` Dan Williams
2025-04-09 3:54 ` Dan Williams
2025-04-09 5:56 ` Rakie Kim
2025-04-09 18:51 ` Dan Williams
2025-04-10 7:53 ` Rakie Kim
2025-04-10 8:06 ` Rakie Kim [this message]
2025-04-11 3:11 ` Andrew Morton
2025-04-11 7:21 ` Rakie Kim
2025-04-11 22:24 ` Dan Williams
2025-04-08 7:32 ` [PATCH v7 3/3] mm/mempolicy: Support memory hotplug in weighted interleave Rakie Kim
2025-04-08 13:52 ` Joshua Hahn
2025-04-08 14:45 ` Gregory Price
2025-04-09 9:05 ` David Hildenbrand
2025-04-09 11:39 ` Honggyu Kim
2025-04-09 11:52 ` David Hildenbrand
2025-04-10 7:53 ` Rakie Kim
2025-04-10 13:25 ` Honggyu Kim
2025-04-10 13:41 ` David Hildenbrand
2025-04-15 16:00 ` Jonathan Cameron
2025-04-16 4:04 ` Honggyu Kim
2025-04-16 7:37 ` Honggyu Kim
2025-04-16 7:49 ` Rakie Kim
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=20250410080629.564-1-rakie.kim@sk.com \
--to=rakie.kim@sk.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@redhat.com \
--cc=gourry@gourry.net \
--cc=honggyu.kim@sk.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel_team@skhynix.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=osalvador@suse.de \
--cc=ying.huang@linux.alibaba.com \
--cc=yunjeong.mun@sk.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox