From: Pratyush Yadav <pratyush@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Pratyush Yadav <pratyush@kernel.org>,
akpm@linux-foundation.org, brauner@kernel.org, corbet@lwn.net,
graf@amazon.com, jgg@ziepe.ca, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-mm@kvack.org,
masahiroy@kernel.org, ojeda@kernel.org, rdunlap@infradead.org,
rppt@kernel.org, tj@kernel.org
Subject: Re: [PATCHv7 3/7] kho: drop notifiers
Date: Fri, 24 Oct 2025 18:32:09 +0200 [thread overview]
Message-ID: <mafs0frb8dzw6.fsf@kernel.org> (raw)
In-Reply-To: <CA+CK2bB_xPAsHXU62Hd5iBt-+Jf2BiXQM4M-QEL=AA_Xu-APhg@mail.gmail.com> (Pasha Tatashin's message of "Fri, 24 Oct 2025 12:15:32 -0400")
On Fri, Oct 24 2025, Pasha Tatashin wrote:
> On Fri, Oct 24, 2025 at 11:52 AM Pratyush Yadav <pratyush@kernel.org> wrote:
>>
>> On Fri, Oct 24 2025, Pratyush Yadav wrote:
>>
>> > On Fri, Oct 24 2025, Pasha Tatashin wrote:
>> >
>> >>> > -int kho_add_subtree(struct kho_serialization *ser, const char *name, void *fdt)
>> >>> > +int kho_add_subtree(const char *name, void *fdt)
>> >>> > {
>> >>> > - int err = 0;
>> >>> > - u64 phys = (u64)virt_to_phys(fdt);
>> >>> > - void *root = page_to_virt(ser->fdt);
>> >>> > + struct kho_sub_fdt *sub_fdt;
>> >>> > + int err;
>> >>> >
>> >>> > - err |= fdt_begin_node(root, name);
>> >>> > - err |= fdt_property(root, PROP_SUB_FDT, &phys, sizeof(phys));
>> >>> > - err |= fdt_end_node(root);
>> >>> > + sub_fdt = kmalloc(sizeof(*sub_fdt), GFP_KERNEL);
>> >>> > + if (!sub_fdt)
>> >>> > + return -ENOMEM;
>> >>> >
>> >>> > - if (err)
>> >>> > - return err;
>> >>> > + INIT_LIST_HEAD(&sub_fdt->l);
>> >>> > + sub_fdt->name = name;
>> >>> > + sub_fdt->fdt = fdt;
>> >>> >
>> >>> > - return kho_debugfs_fdt_add(&kho_out.dbg, name, fdt, false);
>> >>> > + mutex_lock(&kho_out.fdts_lock);
>> >>> > + list_add_tail(&sub_fdt->l, &kho_out.sub_fdts);
>> >>> > + err = kho_debugfs_fdt_add(&kho_out.dbg, name, fdt, false);
>> >>>
>> >>> I think you should remove sub_fdt from the list and kfree() it on error
>> >>> here. Otherwise we signal an error to the caller and they might free
>> >>> sub_fdt->fdt, which will later result in a use-after-free at
>> >>> __kho_finalize().
>> >>
>> >> I think, it is better to simply do:
>> >> WARN_ON_ONCE(kho_debugfs_fdt_add(...));
>> >> Now debugfs is optional, and there is no reason to return an error to
>> >> a caller if kho_debugfs_fdt_add() fails
>> >
>> > Yeah, that works too.
>>
>> On a second thought, maybe pr_warn() instead of WARN_ON()? This isn't an
>> assertion since the debugfs creation can fail for many reasons. It isn't
>> expected to always succeed. So a full WARN_ON() splat seems overkill.
>
> I sent it with WARN_ON_ONCE(), I can change it to pr_warn_once() if
> there is another revision, otherwise we can just send a separate patch
> to make the change it is not that important.
Yep, makes sense.
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2025-10-24 16:32 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 0:57 [PATCHv7 0/7] liveupdate: Rework KHO for in-kernel users Pasha Tatashin
2025-10-22 0:57 ` [PATCHv7 1/7] kho: allow to drive kho from within kernel Pasha Tatashin
2025-10-23 7:13 ` Mike Rapoport
2025-10-22 0:57 ` [PATCHv7 2/7] kho: make debugfs interface optional Pasha Tatashin
2025-10-22 10:31 ` Pratyush Yadav
2025-10-22 0:57 ` [PATCHv7 3/7] kho: drop notifiers Pasha Tatashin
2025-10-22 11:01 ` Pratyush Yadav
2025-10-24 6:16 ` Mike Rapoport
2025-10-24 9:39 ` Pratyush Yadav
2025-10-24 13:11 ` Pasha Tatashin
2025-10-24 15:50 ` Pratyush Yadav
2025-10-24 15:52 ` Pratyush Yadav
2025-10-24 16:15 ` Pasha Tatashin
2025-10-24 16:32 ` Pratyush Yadav [this message]
2025-10-22 0:57 ` [PATCHv7 4/7] kho: add interfaces to unpreserve folios and page ranges Pasha Tatashin
2025-10-22 11:10 ` Pratyush Yadav
2025-10-24 13:18 ` Pasha Tatashin
2025-10-23 7:17 ` Mike Rapoport
2025-10-22 0:57 ` [PATCHv7 5/7] kho: don't unpreserve memory during abort Pasha Tatashin
2025-10-22 11:15 ` Pratyush Yadav
2025-10-23 7:20 ` Mike Rapoport
2025-10-24 13:28 ` Pasha Tatashin
2025-10-24 15:27 ` Pratyush Yadav
2025-10-24 15:33 ` Pasha Tatashin
2025-10-24 15:48 ` Pratyush Yadav
2025-10-22 0:57 ` [PATCHv7 6/7] liveupdate: kho: move to kernel/liveupdate Pasha Tatashin
2025-10-22 0:57 ` [PATCHv7 7/7] liveupdate: kho: move kho debugfs directory to liveupdate Pasha Tatashin
2025-10-23 7:32 ` Mike Rapoport
2025-10-24 13:33 ` Pasha Tatashin
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=mafs0frb8dzw6.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=graf@amazon.com \
--cc=jgg@ziepe.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=masahiroy@kernel.org \
--cc=ojeda@kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=rdunlap@infradead.org \
--cc=rppt@kernel.org \
--cc=tj@kernel.org \
/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.