linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Petr Mladek <pmladek@suse.com>
Cc: Nicolai Stange <nstange@suse.de>,
	Marcos Paulo de Souza <mpdesouza@suse.com>,
	linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
	jpoimboe@redhat.com, joe.lawrence@redhat.com
Subject: Re: [PATCH v2 4/4] livepatch/shadow: Add garbage collection of shadow variables
Date: Mon, 7 Nov 2022 17:32:09 -0800	[thread overview]
Message-ID: <20221108013209.eqrxs3xqtat6kksm@treble> (raw)
In-Reply-To: <Y2TooogxxLTIkBcj@alley>

On Fri, Nov 04, 2022 at 11:25:38AM +0100, Petr Mladek wrote:
> > I get the feeling the latter would be easier to implement (no reference
> > counting; also maybe can be auto-detected with THIS_MODULE?) and harder
> > for the patch author to mess up (by accidentally omitting an object
> > which uses it).
> 
> I am not sure how you mean it. I guess that you suggest to store
> the name of the livepatch module into the shadow variable.
> And use the variable only when the livepatch module is still loaded.

Actually I was thinking the klp_patch could have references to all the
shadow variables (or shadow variable types?) it owns.

Instead of reference counting, the livepatch atomic replace code could
just migrate any previously owned shadow variables to the new klp_patch.

This of course adds the restriction that such garbage-collected shadow
variables couldn't be shared across non-replace livepatches.  But I
wouldn't expect that to be much of a problem.

Additionally, I was wondering if "which klp_patch owns which shadow
variables" could be auto-detected somehow.

For example:

1) add 'struct module *owner' or 'struct klp_patch *owner' to klp_shadow

2) add klp_shadow_alloc_gc() and klp_shadow_get_or_alloc_gc(), which are
   similar to their non-gc counterparts, with a few additional
   arguments: the klp module owner (THIS_MODULE for the caller); and a
   destructor to be used later for the garbage collection

3) When atomic replacing a patch, iterate through the klp_shadow_hash
   and, for each klp_shadow which previously had an owner, change it to
   be owned by the new patch

4) When unloading/freeing a patch, free all its associated klp_shadows
   (also calling destructors where applicable)


I'm thinking this would be easier for the patch author, and also simpler
overall.  I could work up a patch.

-- 
Josh

  reply	other threads:[~2022-11-08  1:33 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-26 19:41 [PATCH v2 0/4] livepatch: Add garbage collection for shadow variables Marcos Paulo de Souza
2022-10-26 19:41 ` [PATCH v2 1/4] livepatch/shadow: Separate code to get or use pre-allocated shadow variable Marcos Paulo de Souza
2022-10-31 15:44   ` Petr Mladek
2022-10-26 19:41 ` [PATCH v2 2/4] livepatch/shadow: Separate code removing all shadow variables for a given id Marcos Paulo de Souza
2022-10-26 19:41 ` [PATCH v2 3/4] livepatch/shadow: Introduce klp_shadow_type structure Marcos Paulo de Souza
2022-10-31 16:02   ` Petr Mladek
2023-01-31  4:36   ` Josh Poimboeuf
2022-10-26 19:41 ` [PATCH v2 4/4] livepatch/shadow: Add garbage collection of shadow variables Marcos Paulo de Souza
2022-11-04  1:03   ` Josh Poimboeuf
2022-11-04 10:25     ` Petr Mladek
2022-11-08  1:32       ` Josh Poimboeuf [this message]
2022-11-08  9:14         ` Petr Mladek
2022-11-08 18:44           ` Josh Poimboeuf
2022-11-09 14:36             ` Petr Mladek
2023-02-04 23:59               ` Josh Poimboeuf
2023-02-17 16:22                 ` Petr Mladek
2022-11-11  9:20       ` Nicolai Stange
2022-11-11  9:55         ` Petr Mladek
2022-11-13 18:51           ` Josh Poimboeuf
2023-01-17 15:01             ` Petr Mladek
2023-01-25 23:22               ` Josh Poimboeuf
2023-01-26  9:36                 ` Petr Mladek
2023-02-04 19:34                 ` Josh Poimboeuf
2023-01-31  4:40   ` Josh Poimboeuf
2023-01-31 14:23     ` Petr Mladek
2023-01-31 21:17       ` Josh Poimboeuf
2023-02-02 13:58         ` Petr Mladek
2023-02-01  0:18   ` Josh Poimboeuf
2023-02-02 10:14     ` Petr Mladek
2023-02-04 17:37       ` Josh Poimboeuf
2022-11-01 10:43 ` [PATCH v2 0/4] livepatch: Add garbage collection for " Petr Mladek
2023-01-23 17:33   ` Marcos Paulo de Souza
2023-01-24 15:51     ` Petr Mladek
2023-01-26 16:35       ` Petr Mladek
2023-01-26 17:05         ` Joe Lawrence
2023-01-26 18:30           ` Josh Poimboeuf
2023-01-27 10:51             ` Petr Mladek
2023-01-27 11:08           ` Marcos Paulo de Souza

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=20221108013209.eqrxs3xqtat6kksm@treble \
    --to=jpoimboe@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mpdesouza@suse.com \
    --cc=nstange@suse.de \
    --cc=pmladek@suse.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;
as well as URLs for NNTP newsgroup(s).