From: Josh Poimboeuf <jpoimboe-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Jessica Yu <jeyu-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>,
Seth Jennings <sjenning-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Jiri Kosina <jikos-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Vojtech Pavlik <vojtech-IBi9RG/b67k@public.gmane.org>,
Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>,
Miroslav Benes <mbenes-AlSwsSmVLrQ@public.gmane.org>,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
live-patching-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: livepatch: reuse module loader code to write relocations
Date: Thu, 10 Dec 2015 15:41:15 -0600 [thread overview]
Message-ID: <20151210214115.GD4934@treble.redhat.com> (raw)
In-Reply-To: <20151210213328.GA6553-N0bYjD2NfQ6k4hzjq3hgyGTy53QMssKEsp+A89P3RPuQWHG76I6BsA@public.gmane.org>
On Thu, Dec 10, 2015 at 04:33:29PM -0500, Jessica Yu wrote:
> +++ Josh Poimboeuf [10/12/15 08:28 -0600]:
> >On Wed, Dec 09, 2015 at 02:10:14PM -0500, Jessica Yu wrote:
> >>+++ Josh Poimboeuf [08/12/15 12:38 -0600]:
> >>>>+ /* For each __klp_rela section for this object */
> >>>>+ klp_for_each_reloc_sec(obj, reloc_sec) {
> >>>>+ relindex = reloc_sec->index;
> >>>>+ num_relas = pmod->sechdrs[relindex].sh_size / sizeof(Elf_Rela);
> >>>>+ rela = (Elf_Rela *) pmod->sechdrs[relindex].sh_addr;
> >>>>+
> >>>>+ /* For each rela in this __klp_rela section */
> >>>>+ for (i = 0; i < num_relas; i++, rela++) {
> >>>>+ sym = symtab + ELF_R_SYM(rela->r_info);
> >>>>+ symname = pmod->core_strtab + sym->st_name;
> >>>>+
> >>>>+ if (sym->st_shndx == SHN_LIVEPATCH) {
> >>>>+ if (sym->st_info == 'K')
> >>>>+ ret = klp_find_external_symbol(pmod, symname, &addr);
> >>>>+ else
> >>>>+ ret = klp_find_object_symbol(obj->name, symname, &addr);
> >>>>+ if (ret)
> >>>>+ return ret;
> >>>>+ sym->st_value = addr;
> >>>
> >>>So I think you're also working on removing the 'external' stuff. Any
> >>>idea how this code will handle that? Specifically I'm wondering how the
> >>>objname and sympos of the rela's symbol will be specified. Maybe it can
> >>>be encoded somehow in one of the symbol fields (st_value)?
> >>
> >>Thanks for bringing this up. I think we can just encode the symbol's
> >>position in kallsyms in the symbol's st_other field. It isn't used
> >>anywhere and has size char, which is plenty of bits to represent the
> >>small ints.
> >
> >st_other does seem to at least have some trivial usage in the kernel,
> >see print_absolute_symbols() and sym_visibility() in
> >arch/x86/tools/relocs.c. Two of the bits are used to specify the
> >"visibility" of a symbol. Also readelf shows a "Vis" column in the
> >symbol table.
>
> Yeah, for x86 it looks like st_other is used only for SHN_ABS symbols
> in print_absolute_symbols(). Technically SHN_LIVEPATCH symbols
> shouldn't be affected in this case...but despite its sparse usage in the
> kernel it does look like using st_other to encode sympos is out of the
> question as its meaning is architecture specific..
>
> >>For objname, the simplest solution might be to append ".klp.objname"
> >>to the symbol name, and extract out this suffix when resolving the
> >>symbol. Another way might be to have st_value contain the index into
> >>the strtab (or .kpatch.strings) that contains the objname. Then we'd
> >>access the objname just like how we access the symbol's name (strtab +
> >>sym->st_name). After we find the objname we can then overwrite
> >>st_value with the real address. I think this second method is cleaner.
> >>Thoughts?
> >
> >Yeah, I guess there are a lot of possibilities for ways to encode it.
> >
> >Personally I think it would be nice if the encoding were something that
> >could easily be seen when dumping the symbol table with readelf. So,
> >for example, the objname could be encoded in the symbol name (as you
> >suggested), and the sympos could be in st_value.
>
> Sure, that should be doable. So the new process might look like this:
>
> For every livepatch symbol referenced by a rela..
>
> 1) Save the sympos encoded in st_value
>
> 2) Save the sym_objname that is encoded in the symbol's name with the
> 'klp' suffix (Just to clarify: the sym_objname specifies the object
> in which the symbol lives, and recall that we need this to remove the
> need for the "external" flag)
>
> 3) Resolve the symbol by using its name (without the klp suffix),
> sympos, and sym_objname
>
> 4) Set st_value to the found address
Sounds right to me.
> >If we do that, it'd probably be good to keep the naming consistent with
> >the '__klp_rela_objname.symname' thing. So something like
> >'_klp_sym_objname.symname'.
>
> How about 'symname.klp.objname', and renaming the klp reloc sections
> to '.klp.objname.rela.section_name'? Special symbol suffixes and
> section names seem to always use '.', so maybe this would look better?
> :-) But we can keep the underscores if people like that more. Both
> naming methods would work, it is only a matter of preference.
It's your patches, so I'd say you get to pick ;-) My only request would
be some consistency between the symbol names and the rela section names.
> >But... would there be any side effects associated with renaming it? For
> >example, would it cause problems with the s390 PLT?
Just to verify, did you see this question? :-)
--
Josh
WARNING: multiple messages have this Message-ID (diff)
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Jessica Yu <jeyu@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
Seth Jennings <sjenning@redhat.com>,
Jiri Kosina <jikos@kernel.org>, Vojtech Pavlik <vojtech@suse.com>,
Jonathan Corbet <corbet@lwn.net>, Miroslav Benes <mbenes@suse.cz>,
linux-api@vger.kernel.org, live-patching@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-s390@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: livepatch: reuse module loader code to write relocations
Date: Thu, 10 Dec 2015 15:41:15 -0600 [thread overview]
Message-ID: <20151210214115.GD4934@treble.redhat.com> (raw)
In-Reply-To: <20151210213328.GA6553@packer-debian-8-amd64.digitalocean.com>
On Thu, Dec 10, 2015 at 04:33:29PM -0500, Jessica Yu wrote:
> +++ Josh Poimboeuf [10/12/15 08:28 -0600]:
> >On Wed, Dec 09, 2015 at 02:10:14PM -0500, Jessica Yu wrote:
> >>+++ Josh Poimboeuf [08/12/15 12:38 -0600]:
> >>>>+ /* For each __klp_rela section for this object */
> >>>>+ klp_for_each_reloc_sec(obj, reloc_sec) {
> >>>>+ relindex = reloc_sec->index;
> >>>>+ num_relas = pmod->sechdrs[relindex].sh_size / sizeof(Elf_Rela);
> >>>>+ rela = (Elf_Rela *) pmod->sechdrs[relindex].sh_addr;
> >>>>+
> >>>>+ /* For each rela in this __klp_rela section */
> >>>>+ for (i = 0; i < num_relas; i++, rela++) {
> >>>>+ sym = symtab + ELF_R_SYM(rela->r_info);
> >>>>+ symname = pmod->core_strtab + sym->st_name;
> >>>>+
> >>>>+ if (sym->st_shndx == SHN_LIVEPATCH) {
> >>>>+ if (sym->st_info == 'K')
> >>>>+ ret = klp_find_external_symbol(pmod, symname, &addr);
> >>>>+ else
> >>>>+ ret = klp_find_object_symbol(obj->name, symname, &addr);
> >>>>+ if (ret)
> >>>>+ return ret;
> >>>>+ sym->st_value = addr;
> >>>
> >>>So I think you're also working on removing the 'external' stuff. Any
> >>>idea how this code will handle that? Specifically I'm wondering how the
> >>>objname and sympos of the rela's symbol will be specified. Maybe it can
> >>>be encoded somehow in one of the symbol fields (st_value)?
> >>
> >>Thanks for bringing this up. I think we can just encode the symbol's
> >>position in kallsyms in the symbol's st_other field. It isn't used
> >>anywhere and has size char, which is plenty of bits to represent the
> >>small ints.
> >
> >st_other does seem to at least have some trivial usage in the kernel,
> >see print_absolute_symbols() and sym_visibility() in
> >arch/x86/tools/relocs.c. Two of the bits are used to specify the
> >"visibility" of a symbol. Also readelf shows a "Vis" column in the
> >symbol table.
>
> Yeah, for x86 it looks like st_other is used only for SHN_ABS symbols
> in print_absolute_symbols(). Technically SHN_LIVEPATCH symbols
> shouldn't be affected in this case...but despite its sparse usage in the
> kernel it does look like using st_other to encode sympos is out of the
> question as its meaning is architecture specific..
>
> >>For objname, the simplest solution might be to append ".klp.objname"
> >>to the symbol name, and extract out this suffix when resolving the
> >>symbol. Another way might be to have st_value contain the index into
> >>the strtab (or .kpatch.strings) that contains the objname. Then we'd
> >>access the objname just like how we access the symbol's name (strtab +
> >>sym->st_name). After we find the objname we can then overwrite
> >>st_value with the real address. I think this second method is cleaner.
> >>Thoughts?
> >
> >Yeah, I guess there are a lot of possibilities for ways to encode it.
> >
> >Personally I think it would be nice if the encoding were something that
> >could easily be seen when dumping the symbol table with readelf. So,
> >for example, the objname could be encoded in the symbol name (as you
> >suggested), and the sympos could be in st_value.
>
> Sure, that should be doable. So the new process might look like this:
>
> For every livepatch symbol referenced by a rela..
>
> 1) Save the sympos encoded in st_value
>
> 2) Save the sym_objname that is encoded in the symbol's name with the
> 'klp' suffix (Just to clarify: the sym_objname specifies the object
> in which the symbol lives, and recall that we need this to remove the
> need for the "external" flag)
>
> 3) Resolve the symbol by using its name (without the klp suffix),
> sympos, and sym_objname
>
> 4) Set st_value to the found address
Sounds right to me.
> >If we do that, it'd probably be good to keep the naming consistent with
> >the '__klp_rela_objname.symname' thing. So something like
> >'_klp_sym_objname.symname'.
>
> How about 'symname.klp.objname', and renaming the klp reloc sections
> to '.klp.objname.rela.section_name'? Special symbol suffixes and
> section names seem to always use '.', so maybe this would look better?
> :-) But we can keep the underscores if people like that more. Both
> naming methods would work, it is only a matter of preference.
It's your patches, so I'd say you get to pick ;-) My only request would
be some consistency between the symbol names and the rela section names.
> >But... would there be any side effects associated with renaming it? For
> >example, would it cause problems with the s390 PLT?
Just to verify, did you see this question? :-)
--
Josh
next prev parent reply other threads:[~2015-12-10 21:41 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-01 4:21 [RFC PATCH v2 0/6] (mostly) Arch-independent livepatch Jessica Yu
2015-12-01 4:21 ` Jessica Yu
2015-12-01 4:21 ` [RFC PATCH v2 1/6] Elf: add livepatch-specific Elf constants Jessica Yu
2015-12-01 4:21 ` [RFC PATCH v2 2/6] module: preserve Elf information for livepatch modules Jessica Yu
[not found] ` <1448943679-3412-3-git-send-email-jeyu-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-12-01 8:48 ` Jessica Yu
2015-12-01 8:48 ` Jessica Yu
2015-12-01 21:06 ` Jessica Yu
2015-12-08 18:32 ` [RFC PATCH v2 2/6] " Josh Poimboeuf
[not found] ` <20151208183212.GB14846-8wJ5/zUtDR0XGNroddHbYwC/G2K4zDHf@public.gmane.org>
2015-12-09 20:05 ` Jessica Yu
2015-12-09 20:05 ` Jessica Yu
2015-12-10 14:38 ` Josh Poimboeuf
[not found] ` <20151210143817.GB29872-8wJ5/zUtDR0XGNroddHbYwC/G2K4zDHf@public.gmane.org>
2015-12-16 10:46 ` Miroslav Benes
2015-12-16 10:46 ` Miroslav Benes
2015-12-17 16:28 ` [RFC PATCH v2 2/6] " Petr Mladek
2015-12-16 10:58 ` Miroslav Benes
2015-12-17 0:40 ` Jessica Yu
2015-12-17 16:26 ` [RFC PATCH v2 2/6] " Petr Mladek
2015-12-21 5:44 ` Jessica Yu
2015-12-01 4:21 ` [RFC PATCH v2 3/6] module: s390: keep mod_arch_specific " Jessica Yu
2015-12-16 12:02 ` Miroslav Benes
[not found] ` <alpine.LNX.2.00.1512161257170.25787-ztGlSCb7Y1iN3ZZ/Hiejyg@public.gmane.org>
2015-12-16 23:48 ` Jessica Yu
2015-12-16 23:48 ` Jessica Yu
2015-12-17 11:39 ` Miroslav Benes
2015-12-01 4:21 ` [RFC PATCH v2 4/6] livepatch: reuse module loader code to write relocations Jessica Yu
[not found] ` <1448943679-3412-5-git-send-email-jeyu-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-12-01 8:43 ` Jessica Yu
2015-12-01 8:43 ` Jessica Yu
2015-12-10 14:20 ` [RFC PATCH v2 4/6] " Minfei Huang
2015-12-10 14:20 ` Minfei Huang
[not found] ` <20151210142032.GA2399-4afrMIaGpRkhWf4U84eJi3gqWNq4x99MuOMsETyM3/Q@public.gmane.org>
2015-12-10 19:56 ` Jiri Kosina
2015-12-10 19:56 ` Jiri Kosina
[not found] ` <alpine.LNX.2.00.1512102055180.9922-YHPUNQjx9ReKbouaWp301Q@public.gmane.org>
2015-12-10 21:12 ` Josh Poimboeuf
2015-12-10 21:12 ` Josh Poimboeuf
2015-12-08 18:38 ` Josh Poimboeuf
[not found] ` <20151208183844.GC14846-8wJ5/zUtDR0XGNroddHbYwC/G2K4zDHf@public.gmane.org>
2015-12-09 19:10 ` Jessica Yu
2015-12-09 19:10 ` Jessica Yu
[not found] ` <20151209191013.GA25387-N0bYjD2NfQ6k4hzjq3hgyGTy53QMssKEsp+A89P3RPuQWHG76I6BsA@public.gmane.org>
2015-12-10 14:28 ` Josh Poimboeuf
2015-12-10 14:28 ` Josh Poimboeuf
2015-12-10 21:33 ` Jessica Yu
[not found] ` <20151210213328.GA6553-N0bYjD2NfQ6k4hzjq3hgyGTy53QMssKEsp+A89P3RPuQWHG76I6BsA@public.gmane.org>
2015-12-10 21:41 ` Josh Poimboeuf [this message]
2015-12-10 21:41 ` Josh Poimboeuf
[not found] ` <20151210214115.GD4934-8wJ5/zUtDR0XGNroddHbYwC/G2K4zDHf@public.gmane.org>
2015-12-10 22:07 ` Jessica Yu
2015-12-10 22:07 ` Jessica Yu
2015-12-16 5:40 ` Jessica Yu
2015-12-16 5:40 ` Jessica Yu
2015-12-16 12:59 ` Miroslav Benes
2015-12-16 19:14 ` Jessica Yu
[not found] ` <20151216054048.GA28258-N0bYjD2NfQ6k4hzjq3hgyGTy53QMssKEsp+A89P3RPuQWHG76I6BsA@public.gmane.org>
2015-12-17 15:45 ` Petr Mladek
2015-12-17 15:45 ` Petr Mladek
2015-12-21 5:57 ` Jessica Yu
2015-12-01 4:21 ` [RFC PATCH v2 5/6] samples: livepatch: init reloc section array and mark as klp module Jessica Yu
2015-12-08 18:41 ` Josh Poimboeuf
2015-12-01 4:21 ` [RFC PATCH v2 6/6] Documentation: livepatch: outline the Elf format of a livepatch module Jessica Yu
-- strict thread matches above, loose matches on Subject: below --
2016-03-16 19:47 [PATCH v5 0/6] (mostly) Arch-independent livepatch Jessica Yu
2016-03-16 19:47 ` [PATCH v5 4/6] livepatch: reuse module loader code to write relocations Jessica Yu
2016-03-21 13:55 ` Miroslav Benes
2016-03-21 19:18 ` Jessica Yu
2016-03-21 19:24 ` Josh Poimboeuf
2016-03-21 21:16 ` Jiri Kosina
2016-03-21 21:34 ` Josh Poimboeuf
[not found] ` <20160321213445.e64jic2uoc7tdtbl-8wJ5/zUtDR0XGNroddHbYwC/G2K4zDHf@public.gmane.org>
2016-03-21 22:02 ` Jiri Kosina
2016-03-21 22:02 ` Jiri Kosina
2016-03-22 19:00 ` Jessica Yu
2016-03-21 16:31 ` [PATCH v5 4/6] " Petr Mladek
2016-03-21 16:46 ` Josh Poimboeuf
2016-03-21 17:36 ` Josh Poimboeuf
2016-03-21 18:07 ` Jessica Yu
2016-02-04 1:11 [RFC PATCH v4 0/6] (mostly) Arch-independent livepatch Jessica Yu
2016-02-04 1:11 ` [RFC PATCH v4 4/6] livepatch: reuse module loader code to write relocations Jessica Yu
2016-02-08 20:26 ` Josh Poimboeuf
[not found] ` <20160208202606.GD23106-8wJ5/zUtDR0XGNroddHbYwC/G2K4zDHf@public.gmane.org>
2016-02-10 0:56 ` Jessica Yu
2016-02-10 0:56 ` Jessica Yu
2016-02-09 14:01 ` [RFC PATCH v4 4/6] " Petr Mladek
2016-02-10 1:21 ` Jessica Yu
2016-01-08 19:28 [RFC PATCH v3 0/6] (mostly) Arch-independent livepatch Jessica Yu
2016-01-08 19:28 ` [RFC PATCH v3 4/6] livepatch: reuse module loader code to write relocations Jessica Yu
2016-01-11 21:33 ` Josh Poimboeuf
[not found] ` <20160111213349.GB17874-8wJ5/zUtDR0XGNroddHbYwC/G2K4zDHf@public.gmane.org>
2016-01-11 22:35 ` Jessica Yu
2016-01-11 22:35 ` Jessica Yu
[not found] ` <20160111223513.GA10796-N0bYjD2NfQ6k4hzjq3hgyGTy53QMssKEsp+A89P3RPuQWHG76I6BsA@public.gmane.org>
2016-01-12 3:05 ` Josh Poimboeuf
2016-01-12 3:05 ` Josh Poimboeuf
[not found] ` <20160112030552.GC17874-8wJ5/zUtDR0XGNroddHbYwC/G2K4zDHf@public.gmane.org>
2016-01-12 9:12 ` Petr Mladek
2016-01-12 9:12 ` Petr Mladek
2016-01-14 5:07 ` Jessica Yu
2016-01-14 5:07 ` Jessica Yu
2016-01-12 16:40 ` [RFC PATCH v3 4/6] " Miroslav Benes
2016-01-14 3:49 ` Jessica Yu
2016-01-14 9:04 ` Miroslav Benes
2016-01-13 9:19 ` [RFC PATCH v3 4/6] " Miroslav Benes
[not found] ` <alpine.LNX.2.00.1601131012340.10011-ztGlSCb7Y1iN3ZZ/Hiejyg@public.gmane.org>
2016-01-13 18:39 ` Jessica Yu
2016-01-13 18:39 ` Jessica Yu
2016-01-14 9:10 ` Miroslav Benes
2015-11-10 4:45 [RFC PATCH 0/5] Arch-independent livepatch Jessica Yu
2015-11-10 4:45 ` [RFC PATCH 3/5] livepatch: reuse module loader code to write relocations Jessica Yu
2015-11-11 14:30 ` Miroslav Benes
[not found] ` <alpine.LNX.2.00.1511111519250.12467-ztGlSCb7Y1iN3ZZ/Hiejyg@public.gmane.org>
2015-11-11 20:07 ` Jessica Yu
2015-11-11 20:07 ` Jessica Yu
[not found] ` <20151111200732.GB30025-N0bYjD2NfQ6k4hzjq3hgyGTy53QMssKEsp+A89P3RPuQWHG76I6BsA@public.gmane.org>
2015-11-12 15:27 ` Miroslav Benes
2015-11-12 15:27 ` Miroslav Benes
2015-11-12 17:40 ` Josh Poimboeuf
[not found] ` <20151112174032.GG4038-M1RQNqTfbHcHO9+bouH2LOBSVt8DKT+lrE5yTffgRl4@public.gmane.org>
2015-11-12 20:22 ` Jessica Yu
2015-11-12 20:22 ` Jessica Yu
[not found] ` <20151112202243.GC5841-N0bYjD2NfQ6k4hzjq3hgyGTy53QMssKEsp+A89P3RPuQWHG76I6BsA@public.gmane.org>
2015-11-12 20:32 ` Josh Poimboeuf
2015-11-12 20:32 ` Josh Poimboeuf
[not found] ` <20151112203221.GM4038-M1RQNqTfbHcHO9+bouH2LOBSVt8DKT+lrE5yTffgRl4@public.gmane.org>
2015-11-13 7:15 ` Jessica Yu
2015-11-13 7:15 ` Jessica Yu
2015-11-13 13:51 ` Miroslav Benes
[not found] ` <alpine.LNX.2.00.1511121601370.9440-ztGlSCb7Y1iN3ZZ/Hiejyg@public.gmane.org>
2015-11-12 19:14 ` Jessica Yu
2015-11-12 19:14 ` Jessica Yu
[not found] ` <20151112191458.GB5841-N0bYjD2NfQ6k4hzjq3hgyGTy53QMssKEsp+A89P3RPuQWHG76I6BsA@public.gmane.org>
2015-11-12 20:35 ` Jessica Yu
2015-11-12 20:35 ` Jessica Yu
2015-11-11 15:22 ` [RFC PATCH 3/5] " Petr Mladek
[not found] ` <20151111152256.GP2599-KsEp0d+Q8qECVLCxKZUutA@public.gmane.org>
2015-11-11 18:27 ` Jessica Yu
2015-11-11 18:27 ` Jessica Yu
[not found] ` <20151111182718.GA30025-N0bYjD2NfQ6k4hzjq3hgyGTy53QMssKEsp+A89P3RPuQWHG76I6BsA@public.gmane.org>
2015-11-12 9:16 ` Petr Mladek
2015-11-12 9:16 ` 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=20151210214115.GD4934@treble.redhat.com \
--to=jpoimboe-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=corbet-T1hC0tSOHrs@public.gmane.org \
--cc=jeyu-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=jikos-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=live-patching-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mbenes-AlSwsSmVLrQ@public.gmane.org \
--cc=rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org \
--cc=sjenning-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=vojtech-IBi9RG/b67k@public.gmane.org \
--cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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.