All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.cz>
To: Minfei Huang <minfei.huang@hotmail.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	sjenning@redhat.com, jkosina@suse.cz, vojtech@suse.cz,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] livepatch: Fix the bug if the function name is larger than KSYM_NAME_LEN-1
Date: Tue, 14 Apr 2015 18:27:18 +0200	[thread overview]
Message-ID: <20150414162718.GC21044@dhcp128.suse.cz> (raw)
In-Reply-To: <BLU436-SMTP729A2F3F19142F31BFB46494E60@phx.gbl>

On Tue 2015-04-14 23:55:36, Minfei Huang wrote:
> On 04/14/15 at 10:11P, Josh Poimboeuf wrote:
> > On Tue, Apr 14, 2015 at 01:45:49PM +0800, Minfei Huang wrote:
> > > On 04/14/15 at 12:32P, Josh Poimboeuf wrote:
> > > > On Tue, Apr 14, 2015 at 01:29:50PM +0800, Minfei Huang wrote:
> > > > > 
> > > > > For end user, they may know litter about restriction of kallsyms and
> > > > > livepatch. How can they know the restriction that function name is
> > > > > limited to 127?
> > > > 
> > > > As I mentioned above, I think kallsyms.c should fail the build if it
> > > > encounters a symbol longer than KSYM_NAME_LEN.
> > > > 
> > > 
> > > I dont think it is a good idea to handle this case like that. The
> > > function name is only for human recognization. Why the compiler fails
> > > to build it?
> > 
> > Well, the function name isn't only for human recognition.  kpatch-build
> > generates patch modules automatically.  It assumes that the compiled
> > function name matches the kallsyms name.  And I'd guess that a lot of
> > other code (both in-kernel and user space tools) make the same
> > assumption.
> > 
> > Not to mention that most humans would also make the same assumption...
> 
> Yes. The assumption is correct for most case.
> 
> It is significance for livepatch to support extra module, because in my
> opinion kernel is more stable than the third module.
> 
> So it is more important, if the livepatch can patch all sorts of patch.
> For dynamic function name, I think it is simple to avoid it.

Do you have some really existing module with such a crazy long
function names or is this debate pure theoretical, please?

Also have you tested your patch and tried to apply livepatch
for some really exiting module, please? I ask because it won't
be trivial to create such a patch. Also the patch would work
only for the one running system.

Best Regards,
Petr

> Usually, we will use ominity to handle a bunch of machines. So it is
> simple, if we use script to get the function address and build the patch.  
> 
> Josh, is there any chance to accept my patches? It may be important
> somewhile that system can not restart without schedule to reload the
> fixed-module.
> 
> Thanks
> Minfei
> 
> > 
> > -- 
> > Josh
> --
> To unsubscribe from this list: send the line "unsubscribe live-patching" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2015-04-14 16:27 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1428844554-4015-1-git-send-email-minfei.huang@hotmail.com>
2015-04-12 13:15 ` [PATCH 1/2] livepatch: Add a new function to verify the address and name match for extra module Minfei Huang
2015-04-13  8:37   ` Petr Mladek
2015-04-13  9:11     ` Minfei Huang
2015-04-13  9:41       ` Petr Mladek
2015-04-13  9:50         ` Minfei Huang
2015-04-13 10:22           ` Petr Mladek
2015-04-13 10:37             ` Minfei Huang
2015-04-13 22:58               ` Josh Poimboeuf
2015-04-14  0:17                 ` Minfei Huang
2015-04-14  0:48                   ` Minfei Huang
2015-04-14  4:05                     ` Josh Poimboeuf
2015-04-14  4:56                       ` Minfei Huang
2015-04-12 13:15 ` [PATCH 2/2] livepatch: Fix the bug if the function name is larger than KSYM_NAME_LEN-1 Minfei Huang
2015-04-13  8:44   ` Petr Mladek
2015-04-13  9:16     ` Minfei Huang
2015-04-13 23:13   ` Josh Poimboeuf
2015-04-14  0:26     ` Minfei Huang
2015-04-14  4:57       ` Josh Poimboeuf
2015-04-14  5:03         ` Minfei Huang
2015-04-14  5:11           ` Josh Poimboeuf
2015-04-14  5:29             ` Minfei Huang
2015-04-14  5:32               ` Josh Poimboeuf
2015-04-14  5:45                 ` Minfei Huang
2015-04-14 15:11                   ` Josh Poimboeuf
2015-04-14 15:55                     ` Minfei Huang
2015-04-14 16:27                       ` Petr Mladek [this message]
2015-04-14 17:01                         ` Minfei Huang
2015-04-14 18:41                           ` Petr Mladek
2015-04-15  2:15                             ` Minfei Huang
2015-04-15  8:30                               ` Miroslav Benes
2015-04-15  8:49                                 ` Minfei Huang
2015-04-15 10:35                                 ` Minfei Huang
2015-04-15 11:58                                   ` Miroslav Benes
2015-04-15 16:24                                     ` Justin Keller
2015-04-16  2:10                                       ` Minfei Huang
2015-04-26 13:05                                     ` Minfei Huang
2015-04-27  8:41                                       ` Miroslav Benes

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=20150414162718.GC21044@dhcp128.suse.cz \
    --to=pmladek@suse.cz \
    --cc=jkosina@suse.cz \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=minfei.huang@hotmail.com \
    --cc=sjenning@redhat.com \
    --cc=vojtech@suse.cz \
    /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.