linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Song Liu <song@kernel.org>
To: Petr Mladek <pmladek@suse.com>
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 10:21:45 -0800	[thread overview]
Message-ID: <CAPhsuW6nsh4AZNhsE_r91rnHEgeRtuhjSa=5OpWvd5Po1dV9BA@mail.gmail.com> (raw)
In-Reply-To: <Y5M+AoKHDK4rn6/i@alley>

On Fri, Dec 9, 2022 at 5:54 AM Petr Mladek <pmladek@suse.com> wrote:
>
> 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?

Hmm.. I think you are right, we still need the check.

>
>
> 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?

No objections that code duplication is not ideal. It is just that sometimes
it is hard to follow the difference between functions with similar names.
Well, it is probably my own problem.

Thanks,
Song

  parent reply	other threads:[~2022-12-09 18:22 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
2022-12-09 14:20       ` Petr Mladek
2022-12-09 18:21       ` Song Liu [this message]
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='CAPhsuW6nsh4AZNhsE_r91rnHEgeRtuhjSa=5OpWvd5Po1dV9BA@mail.gmail.com' \
    --to=song@kernel.org \
    --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=pmladek@suse.com \
    --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).