linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Song Liu <song@kernel.org>
Cc: live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
	jpoimboe@kernel.org, jikos@kernel.org, mbenes@suse.cz,
	x86@kernel.org, joe.lawrence@redhat.com,
	linuxppc-dev@lists.ozlabs.org,
	Josh Poimboeuf <jpoimboe@redhat.com>
Subject: Re: [PATCH v6] livepatch: Clear relocation targets on a module removal
Date: Fri, 9 Dec 2022 14:54:10 +0100	[thread overview]
Message-ID: <Y5M+AoKHDK4rn6/i@alley> (raw)
In-Reply-To: <CAPhsuW4qYpX7wzHn5J5Hn9cnOFSZwwQPCjTM_HPTt_zbBS03ww@mail.gmail.com>

On Mon 2022-11-28 17:57:06, Song Liu wrote:
> On Fri, Nov 18, 2022 at 8:24 AM Petr Mladek <pmladek@suse.com> wrote:
> > > --- a/kernel/livepatch/core.c
> > > +++ b/kernel/livepatch/core.c
> > > @@ -316,6 +316,45 @@ int klp_apply_section_relocs(struct module *pmod, Elf_Shdr *sechdrs,
> > >       return apply_relocate_add(sechdrs, strtab, symndx, secndx, pmod);
> > >  }
> > >
> > > +static void klp_clear_object_relocations(struct module *pmod,
> > > +                                     struct klp_object *obj)
> > > +{
> > > +     int i, cnt;
> > > +     const char *objname, *secname;
> > > +     char sec_objname[MODULE_NAME_LEN];
> > > +     Elf_Shdr *sec;
> > > +
> > > +     objname = klp_is_module(obj) ? obj->name : "vmlinux";
> > > +
> > > +     /* For each klp relocation section */
> > > +     for (i = 1; i < pmod->klp_info->hdr.e_shnum; i++) {
> > > +             sec = pmod->klp_info->sechdrs + i;
> > > +             secname = pmod->klp_info->secstrings + sec->sh_name;

secname = ...

> > > +             if (!(sec->sh_flags & SHF_RELA_LIVEPATCH))
> > > +                     continue;
> > > +
> > > +             /*
> > > +              * Format: .klp.rela.sec_objname.section_name
> > > +              * See comment in klp_resolve_symbols() for an explanation
> > > +              * of the selected field width value.
> > > +              */
> > > +             secname = pmod->klp_info->secstrings + sec->sh_name;

secname = ...    same a above.

> > > +             cnt = sscanf(secname, ".klp.rela.%55[^.]", sec_objname);
> > > +             if (cnt != 1) {
> > > +                     pr_err("section %s has an incorrectly formatted name\n",
> > > +                            secname);
> > > +                     continue;
> > > +             }
> 
> Actually, I think we don't need the cnt check here. Once it is removed,
> there isn't much duplicated logic.

Seriously?

A section with this error was skipped in klp_apply_section_relocs().
I did not cause rejecting the module! Why is it suddenly safe to
process it, please?


I see that you removed also:

	if (strcmp(objname ? objname : "vmlinux", sec_objname))
		return 0;

This is another bug in your "simplification".


> > > +
> > > +             if (strcmp(objname, sec_objname))
> > > +                     continue;
> > > +
> > > +             clear_relocate_add(pmod->klp_info->sechdrs,
> > > +                                pmod->core_kallsyms.strtab,
> > > +                                pmod->klp_info->symndx, i, pmod);
> > > +     }
> > > +}
> >
> > Huh, this duplicates a lot of tricky code.
> >
> > It is even worse because this squashed code from two functions
> > klp_apply_section_relocs() and klp_apply_object_relocs()
> > into a single function. As a result, the code duplication is not
> > even obvious.
> >
> > Also the suffix "_reloacations() does not match the suffix of
> > the related funciton:
> >
> >         + klp_apply_object_relocs()             (existing)
> >         + klp_clear_object_relocations()        (new)
> >
> > This all would complicate maintenance of the code.
> >
> > Please, implement a common:
> >
> > int klp_write_section_relocs(struct module *pmod, Elf_Shdr *sechdrs,
> >                              const char *shstrtab, const char *strtab,
> >                              unsigned int symndx, unsigned int secndx,
> >                              const char *objname, bool apply);
> >
> > and
> >
> > int klp_write_object_relocs(struct klp_patch *patch,
> >                             struct klp_object *obj,
> >                             bool apply);
> >
> > and add the respective wrappers:
> >
> > int klp_apply_section_relocs();   /* also needed in module/main.c */
> > int klp_apply_object_relocs();
> > void klp_clear_object_relocs();
> 
> With the above simplification (removing cnt check), do we still need
> all these wrappers? Personally, I think they will make the code more
> difficult to follow..

Sigh.

klp_apply_section_relocs() has 25 lines of code.
klp_apply_object_relocs() has 18 lines of code.

The only difference should be that klp_clear_object_relocs():

   + does not need to call klp_resolve_symbols()
   + need to call clear_relocate_add() instead of apply_relocate_add()

It is 7 different lines from in the existing 25 + 18 = 43 lines.
The duplication does not look like a good deal even from this POV.

If we introduce update_relocate_add(..., bool apply) parameter
then we could call update_relocate_add() in both situations.

Let me repeat from the last mail. klp_clear_object_relocs() even
reshuffled the duplicated code. It was even harder to find differences.

Do I still need to explain how bad idea was the code duplication,
please?

Best Regards,
Petr

  parent reply	other threads:[~2022-12-09 13:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01 17:12 [PATCH v6] livepatch: Clear relocation targets on a module removal Song Liu
2022-11-17 22:06 ` Song Liu
2022-11-18 16:24 ` Petr Mladek
2022-11-18 17:14   ` Song Liu
2022-11-21 15:32     ` Joe Lawrence
2022-11-21 16:32       ` Song Liu
2022-11-29  1:57   ` Song Liu
2022-12-09 11:41     ` powerpc-part: was: " Petr Mladek
2022-12-09 19:59       ` Song Liu
2022-12-12 17:11         ` Petr Mladek
2022-12-12 22:22           ` Song Liu
2022-12-13  8:13           ` Song Liu
2022-12-13 13:29             ` Petr Mladek
2022-12-13 22:19               ` Joe Lawrence
2022-12-13 19:31       ` Song Liu
2022-12-09 12:36     ` x86 part: " Petr Mladek
2022-12-09 12:49     ` Miroslav Benes
2022-12-09 13:54     ` Petr Mladek [this message]
2022-12-09 14:20       ` Petr Mladek
2022-12-09 18:21       ` Song Liu
2022-12-09 12:55 ` Miroslav Benes
2022-12-09 18:30   ` Song Liu
2022-12-09 18:51     ` Christophe Leroy
2022-12-09 19:24       ` Song Liu
2022-12-12  8:16     ` Miroslav Benes
2022-12-13  8:28   ` Song Liu
2022-12-13 14:37     ` Petr Mladek

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=Y5M+AoKHDK4rn6/i@alley \
    --to=pmladek@suse.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=song@kernel.org \
    --cc=x86@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 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).