All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Richard Moser <nigelenki@comcast.net>
To: Valdis.Kletnieks@vt.edu
Cc: linux-kernel@vger.kernel.org
Subject: Re: Hot-patching
Date: Tue, 20 Sep 2005 18:50:43 -0400	[thread overview]
Message-ID: <43309243.3050100@comcast.net> (raw)
In-Reply-To: <200509202221.j8KMLhcr032238@turing-police.cc.vt.edu>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Valdis.Kletnieks@vt.edu wrote:
> On Tue, 20 Sep 2005 18:07:17 EDT, John Richard Moser said:
> 
> 
>>These bugfixes don't typically change the exported binary interface of
>>the existing functions being corrected, and so it would be feasible to
>>halt all processors and execute an atomic codepath to switch the symbols
>>in the running kernel to point to the replacement functions from the old
>>ones.  If big functions are split up into smaller ones, as long as the
>>interface is the same for all existing functions, it shouldn't matter as
>>well.
> 
> 
> I believe telco switch software has been doing patch-on-the-fly for quite
> a long time.  It's a royal pain in the butt, especially if you have any
> dynamic 'struct foo_ops' lurking.
> 
> And you can't just plop the code in either - let's say the fix includes "add
> a state bit to the 'struct foo_ctl' to track XYZ".  Now you need to think about
> the fact that there's likely kmalloc'ed struct foo_ctl's already out there
> that don't know about this bit.  Hilarity ensues....

In which case you can't make a hot-patch, unless you like watching your
kernel take a crap.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDMJJDhDd4aOud5P8RAijUAJ9BPXQoVCeD5EzTXedBGaIz87SjsgCdEN21
6/2BUWcZ4HT4FwSFkWt5OEM=
=WjP8
-----END PGP SIGNATURE-----

  reply	other threads:[~2005-09-20 22:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-20 22:07 Hot-patching John Richard Moser
2005-09-20 22:18 ` Hot-patching Jesper Juhl
2005-09-20 22:21 ` Hot-patching Valdis.Kletnieks
2005-09-20 22:50   ` John Richard Moser [this message]
2005-09-20 22:47 ` Hot-patching Jesper Juhl
2005-09-20 22:57   ` Hot-patching John Richard Moser
2005-09-20 23:07     ` Hot-patching Jesper Juhl

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=43309243.3050100@comcast.net \
    --to=nigelenki@comcast.net \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=linux-kernel@vger.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 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.