All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Marcos Paulo de Souza <mpdesouza@suse.com>
Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
	jpoimboe@redhat.com, joe.lawrence@redhat.com
Subject: Re: [PATCH v2 3/4] livepatch/shadow: Introduce klp_shadow_type structure
Date: Mon, 31 Oct 2022 17:02:47 +0100	[thread overview]
Message-ID: <Y1/xp7OBgu3qGUKz@alley> (raw)
In-Reply-To: <20221026194122.11761-4-mpdesouza@suse.com>

On Wed 2022-10-26 16:41:21, Marcos Paulo de Souza wrote:
> The shadow variable type will be used in klp_shadow_alloc/get/free
> functions instead of id/ctor/dtor parameters. As a result, all callers
> use the same callbacks consistently[*][**].
> 
> The structure will be used in the next patch that will manage the
> lifetime of shadow variables and execute garbage collection automatically.
> 
> [*] From the user POV, it might have been easier to pass $id instead
>     of pointer to struct klp_shadow_type.
> 
>     It would require registering the klp_shadow_type so that
>     the klp_shadow API could find ctor/dtor for the given id.
>     It actually will be needed for the garbage collection anyway
>     because it will define the lifetime of the variables.
> 
>     The bigger problem is that the same klp_shadow_type might be
>     used by more livepatch modules. Each livepatch module need
>     to duplicate the definition of klp_shadow_type and ctor/dtor
>     callbacks. The klp_shadow API would need to choose one registered
>     copy.
> 
>     The definitions should be compatible and they should stay as long
>     as the type is registered. But it still feels more safe when
>     klp_shadow API callers use struct klp_shadow_type and ctor/dtor
>     callbacks defined in the same livepatch module.
> 
>     This problem is gone when each livepatch explicitly uses its
>     own struct klp_shadow_type pointing to its own callbacks.

This paragraph seems redundant. It more or less repeats what
is said in the previous one.


> [**] test_klp_shadow_vars.c uses a custom @dtor to show that it was called.
>     The message must be disabled when called via klp_shadow_free_all()
>     because the ordering of freed variables is not well defined there.
>     It has to be done using another hack after switching to
>     klp_shadow_types.
> 
> Co-developed-by: Petr Mladek <pmladek@suse.com>
> Signed-off-by: Petr Mladek <pmladek@suse.com>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>

I am never sure how the co-authoring should be done ;-) But I believe
that the author should always be the first one. And the other author
should be listed either by Co-developer-by: or by Signed-off-by: but
not by both tags. So, it should be:

Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Co-developed-by: Petr Mladek <pmladek@suse.com>


With the removed paragraph and updated tags:

Reviewed-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr


PS: No need to resend the patch. I could do the two changes
    when pushing it.

  reply	other threads:[~2022-10-31 16:02 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 [this message]
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
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=Y1/xp7OBgu3qGUKz@alley \
    --to=pmladek@suse.com \
    --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 \
    /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.