From: Pratyush Yadav <pratyush@kernel.org>
To: David Matlack <dmatlack@google.com>
Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>
Subject: Re: [PATCH 0/2] liveupdate: Small FLB fixes
Date: Fri, 10 Jul 2026 11:57:53 +0200 [thread overview]
Message-ID: <2vxzcxwvkvz2.fsf@kernel.org> (raw)
In-Reply-To: <CALzav=diio783dFmPGYp9Uvov2HBWv_EQLoNjnM=qBWzwU5tCA@mail.gmail.com> (David Matlack's message of "Thu, 9 Jul 2026 13:51:40 -0700")
On Thu, Jul 09 2026, David Matlack wrote:
> On Thu, May 28, 2026 at 10:41 AM David Matlack <dmatlack@google.com> wrote:
>>
>> This series has 2 small fixes to how FLBs are managed. First is to
>> increase the outgoing FLB refcount during liveupdate_flb_get_outgoing()
>> so it cannot be freed while the caller is using it, and to align with
>> the semantics of liveupdate_flb_get_incoming(). The second is to prevent
>> FLB retrieve() from being called multiple times if the first attempt
>> fails.
>>
>> Both of these changes are needed for the correctness of the PCI core
>> support for Live Update:
>>
>> https://lore.kernel.org/linux-pci/20260522202410.3104264-1-dmatlack@google.com/
>
> I'm wondering if we still want this series. After discussions with
> Pratyush and Sami (some on-list, some off-list) the v7 of the PCI
> series (which I haven't sent yet) does not depend on these changes for
> correctness.
>
> Patch 1: PCI core no longer calls get_outgoing() outside the scope of
> file handler callbacks. So there is no need to increment the reference
> count. We could still keep this to make get_outgoing behave the same
> way as get_incoming for consisteny at the cost of some extra
> complexity to manage outgoing FLB refcoutn.
I'm neutral on this one. I'll leave it up to Pasha's preference.
>
> Patch 2: PCI core panics if retrieve fails (proceeding without the PCI
> FLB can lead to memory corruption due to ongoing DMA). So the behavior
> of LUO on retrieve() errors does not matter.
This patch is useful for sure. Sure, PCI might panic, but other FLB
users like HugeTLB won't. And this patch fixes a real problem for those
cases.
The patch applies cleanly on liveupdate/next. So Mike, would you mind
applying patch 2/2 now? We can wait for Pasha to chime in for 1/2.
>
> Should we drop this series?
--
Regards,
Pratyush Yadav
prev parent reply other threads:[~2026-07-10 9:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 17:41 [PATCH 0/2] liveupdate: Small FLB fixes David Matlack
2026-05-28 17:41 ` [PATCH 1/2] liveupdate: Reference count outgoing FLB data David Matlack
2026-06-02 17:15 ` Pratyush Yadav
2026-06-02 17:25 ` David Matlack
2026-06-08 14:19 ` Pratyush Yadav
2026-06-08 23:37 ` David Matlack
2026-06-09 2:17 ` Pasha Tatashin
2026-06-09 13:33 ` Pratyush Yadav
2026-06-03 3:36 ` Pasha Tatashin
2026-05-28 17:41 ` [PATCH 2/2] liveupdate: Remember FLB retrieve() status David Matlack
2026-06-02 17:18 ` Pratyush Yadav
2026-06-03 3:36 ` Pasha Tatashin
2026-06-04 5:28 ` [PATCH 0/2] liveupdate: Small FLB fixes Mike Rapoport
2026-06-05 13:09 ` Pratyush Yadav
2026-07-09 20:51 ` David Matlack
2026-07-10 9:57 ` Pratyush Yadav [this message]
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=2vxzcxwvkvz2.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dmatlack@google.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=rppt@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.