All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: Pratyush Yadav <pratyush@kernel.org>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
	 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 17:52:26 +0200	[thread overview]
Message-ID: <mafs0jz0ke1qd.fsf@kernel.org> (raw)
In-Reply-To: <mafs0o6pwe1sy.fsf@kernel.org> (Pratyush Yadav's message of "Fri, 24 Oct 2025 17:50:53 +0200")

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.

[...]

-- 
Regards,
Pratyush Yadav

  reply	other threads:[~2025-10-24 15:52 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 [this message]
2025-10-24 16:15           ` Pasha Tatashin
2025-10-24 16:32             ` Pratyush Yadav
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=mafs0jz0ke1qd.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.