Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Ralf Baechle wrote: I'd try a shared library based approach for on the fly updates. The version that I've seen imposed requirements on the application for this to work properly. There are tradeoffs either way. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Rik van Riel wrote: On Wed, 20 Apr 2005, Takashi Ikebe wrote: Well, as many said Live patching is very historical & authoritative function on especially carrier, telecom vendor. If linux want to be adopted on mission critical world, this function is esseintial. Yes, if you want to use Linux in those scenarios you will need to change the telco programs to use shared memory and file descriptor passing, instead of live patching. Unfortunately we're also dealing (in many cases) with pre-existing software coming over from other OS's. The beancounters want to avoid rewriting the millions of lines of application code, so they'd rather add the missing support to the kernel. If it doesn't go into mainline, we'll just end up with a bunch of different telco-patches being maintained on the side. I highly doubt all the applications will get fixed any time soon. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 02:25:06AM -0700, Chris Wedgwood wrote: > > The call switching folks have been doing live patching at least > > since I worked on it, over 25 years ago. This is not just > > marketing. > > That still doesn't explain *why* live patching is needed. The more optimization a modern compiler does the less practical a patching approach seems for anything but very trivial fixes. I'd try a shared library based approach for on the fly updates. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Wed, 20 Apr 2005, Takashi Ikebe wrote: > Well, as many said Live patching is very historical & authoritative > function on especially carrier, telecom vendor. > If linux want to be adopted on mission critical world, this function is > esseintial. Yes, if you want to use Linux in those scenarios you will need to change the telco programs to use shared memory and file descriptor passing, instead of live patching. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Wed, Apr 20, 2005 at 05:45:00PM +0900, Takashi Ikebe wrote: > Only for AF_UNIX.. I'm sure that means AF_UNIX is restricted for the socket you use to pass the file descriptors, not a restriction on the file descriptors themselves. I don't see why the kernel would care what the descriptors are. > Well, as many said Live patching is very historical & authoritative > function on especially carrier, telecom vendor. Linux doesn't have it now, do it's not historical in the Linux space. > If linux want to be adopted on mission critical world, this function > is esseintial. But Linux is used in mission critical places and we don't have that feature. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Chris Wedgwood wrote:
(B> On Wed, Apr 20, 2005 at 04:57:31PM +0900, Takashi Ikebe wrote:
(B>
(B>
(B>>hmm.. most internet base services will use TCPv4 TCPv6 SCTP...
(B>>AF_UNIX can not use as inter-nodes communication.
(B>
(B>
(B> You can send file descriptors (the actually file descriptors
(B> themselves, not their contents) to another process over a socket.
(B>
(B> A nearly ten-year old example is attached (ie. this isn't new or
(B> magical or specific to Linux).
(B>
(B>
(B>
(B>
(B> int main()
(B> {
(B> int fds[2];
(B> int fd = -1;
(B> int rc = socketpair(AF_UNIX, SOCK_STREAM, 0, fds);
(BHmm interest enough,
(BBut please see man.
(B
(BNOTES
(B On Linux, the only supported domain for this call is AF_UNIX (or
(B syn-
(B onymously, AF_LOCAL). (Most implementations have the same
(Brestric-
(B tion.)
(B
(BOnly for AF_UNIX..
(B
(B
(BWell, as many said Live patching is very historical & authoritative
(Bfunction on especially carrier, telecom vendor.
(BIf linux want to be adopted on mission critical world, this function is
(Besseintial.
(B
(B--
(BTakashi Ikebe
(BNTT Network Service Systems Laboratories
(B9-11, Midori-Cho 3-Chome Musashino-Shi,
(BTokyo 180-8585 Japan
(BTel : +81 422 59 4246, Fax : +81 422 60 4012
(Be-mail : [EMAIL PROTECTED]
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
In article <[EMAIL PROTECTED]>, Takashi Ikebe <[EMAIL PROTECTED]> wrote: >Chris Wedgwood wrote: >> On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:> >> >>>To takeover the application status, connection type >>>communications(SOCK_STREAM) are need to be disconnected by close(). >>>Same network port is not allowed to bind by multiple processes >> >> >> AF_UNIX socket with SCM_RIGHTS >> >hmm.. most internet base services will use TCPv4 TCPv6 SCTP... >AF_UNIX can not use as inter-nodes communication. No, Chris means filedescriptor passing. You can pass any existing open filedescriptor to another process using an AF_UNIX socket. For example, the existing running process creates a UNIX socket in /var/run/mysocket that the new process can connect() to. The processes can then not only exchange all kinds of information, the old process can even send open filedescriptors over to the new process without closing/re-opening. See "man 7 unix", ANCILLARY MESSAGES -> SCM_RIGHTS ANCILLARY MESSAGES Ancillary data is sent and received using sendmsg(2) and recvmsg(2). For historical reasons the ancillary message types listed below are specified with a SOL_SOCKET type even though they are PF_UNIX specific. To send them set the cmsg_level field of the struct cmsghdr to SOL_SOCKET and the cmsg_type field to the type. For more information see cmsg(3). SCM_RIGHTS Send or receive a set of open file descriptors from another pro- cess. The data portion contains an integer array of the file descriptors. The passed file descriptors behave as though they have been created with dup(2). Mike. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Wed, Apr 20, 2005 at 04:57:31PM +0900, Takashi Ikebe wrote:
> hmm.. most internet base services will use TCPv4 TCPv6 SCTP...
> AF_UNIX can not use as inter-nodes communication.
You can send file descriptors (the actually file descriptors
themselves, not their contents) to another process over a socket.
A nearly ten-year old example is attached (ie. this isn't new or
magical or specific to Linux).
/* sendfd.c - v. crude example of passing fds */
/*
* I tested this on HPUX10 using gcc -D_XOPEN_SOURCE_EXTENDED sendfd.c -lxnet
*
* Expected output is "hello world"
*/
#include
#include
#include
#include
#include
#include
#include
/* Note: msg_control may be msg_accrights, etc. */
int sendfd(int conn, int fd)
{
size_t len = sizeof(struct cmsghdr) + sizeof(int);
struct cmsghdr *hdr = (struct cmsghdr *)malloc(len);
struct msghdr msg;
int rc;
hdr->cmsg_len = len;
hdr->cmsg_level = SOL_SOCKET;
hdr->cmsg_type = SCM_RIGHTS;
*(int *)CMSG_DATA(hdr) = fd;
msg.msg_name = NULL;
msg.msg_namelen = 0;
msg.msg_iov = NULL;
msg.msg_iovlen = 0;
msg.msg_control = hdr;
msg.msg_controllen = len;
rc = sendmsg(conn, , 0);
free(hdr);
return rc;
}
int recvfd(int conn)
{
size_t len = sizeof(struct cmsghdr) + sizeof(int);
struct cmsghdr *hdr = (struct cmsghdr *)malloc(len);
struct msghdr msg;
int rc;
msg.msg_iov = NULL;
msg.msg_iovlen = 0;
msg.msg_control = hdr;
msg.msg_controllen = len;
rc = recvmsg(conn, , 0);
if (rc >= 0
&& hdr->cmsg_len == len
&& hdr->cmsg_level == SOL_SOCKET
&& hdr->cmsg_type == SCM_RIGHTS)
{
int fd = *(int *)CMSG_DATA(hdr);
free(hdr);
return fd;
}
free(hdr);
return -1;
}
int main()
{
int fds[2];
int fd = -1;
int rc = socketpair(AF_UNIX, SOCK_STREAM, 0, fds);
pid_t pid;
if (rc)
{
perror("socketpair");
return 1;
}
/* punt */
system("echo hello world >testfile");
switch (pid = fork())
{
case 0:
// open this in the child proc
fd = open("testfile",O_RDONLY);
if (fd < 0)
perror("open(testfile)");
rc = sendfd(fds[1], fd);
if (rc)
perror("sendfd");
_exit(0);
case -1:
perror("fork");
return 1;
default:
waitpid(pid,NULL,0);
}
fd = recvfd(fds[0]);
if (fd < 0)
{
perror("recvfd");
return 1;
}
close(fds[0]);
close(fds[1]);
dup2(fd,0);
close(fd);
execl("/bin/cat","cat",NULL);
}
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Chris Wedgwood wrote: On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:> To takeover the application status, connection type communications(SOCK_STREAM) are need to be disconnected by close(). Same network port is not allowed to bind by multiple processes AF_UNIX socket with SCM_RIGHTS hmm.. most internet base services will use TCPv4 TCPv6 SCTP... AF_UNIX can not use as inter-nodes communication. -- Takashi Ikebe NTT Network Service Systems Laboratories 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Tel : +81 422 59 4246, Fax : +81 422 60 4012 e-mail : [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote: > I think basic assumption between us and you is not match... No, I think at a high-level they do. > Our assumption, the live patching is not for debug, but for the real > operation method to fix very very important process which can not > stop. I understand that. It might be though you could probably do what you want with some kind of enhanced ptrace or debugging interface that would also be of value to other people and probably simple than your proposed patch. > Live patchin fix the important process's bug without disrupting > process. I understand that. > To takeover the application status, connection type > communications(SOCK_STREAM) are need to be disconnected by close(). > Same network port is not allowed to bind by multiple processes AF_UNIX socket with SCM_RIGHTS > especialy, ru_utime and ru_stime is very important to critical > applications. how so? what is magical about these that can't be dealt with in userspace should it span 2+ processes? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Hi, I think basic assumption between us and you is not match.. Our assumption, the live patching is not for debug, but for the real operation method to fix very very important process which can not stop. Live patchin fix the important process's bug without disrupting process. Chris Wedgwood wrote: On Wed, Apr 20, 2005 at 01:18:23PM +0900, Takashi Ikebe wrote: Well, Live patching is just a patch, so I think the developer of patch should know the original source code well. In which case they could fix the application. Yes, so they provide us the patch module, and we want to apply the patch as live patching. Well, as you said some application can do that, but some application can not continue service with your suggestion. Such as? please think about the process which use connection type communication such as TCP(it's only example) between users and server. During status copy, all the session between users and server are disconnected... They don't have to be. ??? To takeover the application status, connection type communications(SOCK_STREAM) are need to be disconnected by close(). Same network port is not allowed to bind by multiple processes How can you do that?? Users don't want to disconnect,(and also we don't want to disconnect) but server process need to it to takeover the status. can not save the exiting service at all. Yes they can. It's one example, but similar problems may occurs whenever processed use the resources which are mainly controlled by kernel. What resources? We can migrate memory and file descriptors? What is missing? For example, current process's resouces of rlimit. you nerver set current rusage to new process. especialy, ru_utime and ru_stime is very important to critical applications. I don't know much about resources, but there may be more(I hope not..) -- Takashi Ikebe NTT Network Service Systems Laboratories 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Tel : +81 422 59 4246, Fax : +81 422 60 4012 e-mail : [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Hi, I think basic assumption between us and you is not match.. Our assumption, the live patching is not for debug, but for the real operation method to fix very very important process which can not stop. Live patchin fix the important process's bug without disrupting process. Chris Wedgwood wrote: On Wed, Apr 20, 2005 at 01:18:23PM +0900, Takashi Ikebe wrote: Well, Live patching is just a patch, so I think the developer of patch should know the original source code well. In which case they could fix the application. Yes, so they provide us the patch module, and we want to apply the patch as live patching. Well, as you said some application can do that, but some application can not continue service with your suggestion. Such as? please think about the process which use connection type communication such as TCP(it's only example) between users and server. During status copy, all the session between users and server are disconnected... They don't have to be. ??? To takeover the application status, connection type communications(SOCK_STREAM) are need to be disconnected by close(). Same network port is not allowed to bind by multiple processes How can you do that?? Users don't want to disconnect,(and also we don't want to disconnect) but server process need to it to takeover the status. can not save the exiting service at all. Yes they can. It's one example, but similar problems may occurs whenever processed use the resources which are mainly controlled by kernel. What resources? We can migrate memory and file descriptors? What is missing? For example, current process's resouces of rlimit. you nerver set current rusage to new process. especialy, ru_utime and ru_stime is very important to critical applications. I don't know much about resources, but there may be more(I hope not..) -- Takashi Ikebe NTT Network Service Systems Laboratories 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Tel : +81 422 59 4246, Fax : +81 422 60 4012 e-mail : [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote: I think basic assumption between us and you is not match... No, I think at a high-level they do. Our assumption, the live patching is not for debug, but for the real operation method to fix very very important process which can not stop. I understand that. It might be though you could probably do what you want with some kind of enhanced ptrace or debugging interface that would also be of value to other people and probably simple than your proposed patch. Live patchin fix the important process's bug without disrupting process. I understand that. To takeover the application status, connection type communications(SOCK_STREAM) are need to be disconnected by close(). Same network port is not allowed to bind by multiple processes AF_UNIX socket with SCM_RIGHTS especialy, ru_utime and ru_stime is very important to critical applications. how so? what is magical about these that can't be dealt with in userspace should it span 2+ processes? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Chris Wedgwood wrote: On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote: To takeover the application status, connection type communications(SOCK_STREAM) are need to be disconnected by close(). Same network port is not allowed to bind by multiple processes AF_UNIX socket with SCM_RIGHTS hmm.. most internet base services will use TCPv4 TCPv6 SCTP... AF_UNIX can not use as inter-nodes communication. -- Takashi Ikebe NTT Network Service Systems Laboratories 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Tel : +81 422 59 4246, Fax : +81 422 60 4012 e-mail : [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Wed, Apr 20, 2005 at 04:57:31PM +0900, Takashi Ikebe wrote:
hmm.. most internet base services will use TCPv4 TCPv6 SCTP...
AF_UNIX can not use as inter-nodes communication.
You can send file descriptors (the actually file descriptors
themselves, not their contents) to another process over a socket.
A nearly ten-year old example is attached (ie. this isn't new or
magical or specific to Linux).
/* sendfd.c - v. crude example of passing fds */
/*
* I tested this on HPUX10 using gcc -D_XOPEN_SOURCE_EXTENDED sendfd.c -lxnet
*
* Expected output is hello world
*/
#include stdio.h
#include sys/types.h
#include sys/wait.h
#include unistd.h
#include stdlib.h
#include sys/socket.h
#include sys/un.h
/* Note: msg_control may be msg_accrights, etc. */
int sendfd(int conn, int fd)
{
size_t len = sizeof(struct cmsghdr) + sizeof(int);
struct cmsghdr *hdr = (struct cmsghdr *)malloc(len);
struct msghdr msg;
int rc;
hdr-cmsg_len = len;
hdr-cmsg_level = SOL_SOCKET;
hdr-cmsg_type = SCM_RIGHTS;
*(int *)CMSG_DATA(hdr) = fd;
msg.msg_name = NULL;
msg.msg_namelen = 0;
msg.msg_iov = NULL;
msg.msg_iovlen = 0;
msg.msg_control = hdr;
msg.msg_controllen = len;
rc = sendmsg(conn, msg, 0);
free(hdr);
return rc;
}
int recvfd(int conn)
{
size_t len = sizeof(struct cmsghdr) + sizeof(int);
struct cmsghdr *hdr = (struct cmsghdr *)malloc(len);
struct msghdr msg;
int rc;
msg.msg_iov = NULL;
msg.msg_iovlen = 0;
msg.msg_control = hdr;
msg.msg_controllen = len;
rc = recvmsg(conn, msg, 0);
if (rc = 0
hdr-cmsg_len == len
hdr-cmsg_level == SOL_SOCKET
hdr-cmsg_type == SCM_RIGHTS)
{
int fd = *(int *)CMSG_DATA(hdr);
free(hdr);
return fd;
}
free(hdr);
return -1;
}
int main()
{
int fds[2];
int fd = -1;
int rc = socketpair(AF_UNIX, SOCK_STREAM, 0, fds);
pid_t pid;
if (rc)
{
perror(socketpair);
return 1;
}
/* punt */
system(echo hello world testfile);
switch (pid = fork())
{
case 0:
// open this in the child proc
fd = open(testfile,O_RDONLY);
if (fd 0)
perror(open(testfile));
rc = sendfd(fds[1], fd);
if (rc)
perror(sendfd);
_exit(0);
case -1:
perror(fork);
return 1;
default:
waitpid(pid,NULL,0);
}
fd = recvfd(fds[0]);
if (fd 0)
{
perror(recvfd);
return 1;
}
close(fds[0]);
close(fds[1]);
dup2(fd,0);
close(fd);
execl(/bin/cat,cat,NULL);
}
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
In article [EMAIL PROTECTED], Takashi Ikebe [EMAIL PROTECTED] wrote: Chris Wedgwood wrote: On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote: To takeover the application status, connection type communications(SOCK_STREAM) are need to be disconnected by close(). Same network port is not allowed to bind by multiple processes AF_UNIX socket with SCM_RIGHTS hmm.. most internet base services will use TCPv4 TCPv6 SCTP... AF_UNIX can not use as inter-nodes communication. No, Chris means filedescriptor passing. You can pass any existing open filedescriptor to another process using an AF_UNIX socket. For example, the existing running process creates a UNIX socket in /var/run/mysocket that the new process can connect() to. The processes can then not only exchange all kinds of information, the old process can even send open filedescriptors over to the new process without closing/re-opening. See man 7 unix, ANCILLARY MESSAGES - SCM_RIGHTS ANCILLARY MESSAGES Ancillary data is sent and received using sendmsg(2) and recvmsg(2). For historical reasons the ancillary message types listed below are specified with a SOL_SOCKET type even though they are PF_UNIX specific. To send them set the cmsg_level field of the struct cmsghdr to SOL_SOCKET and the cmsg_type field to the type. For more information see cmsg(3). SCM_RIGHTS Send or receive a set of open file descriptors from another pro- cess. The data portion contains an integer array of the file descriptors. The passed file descriptors behave as though they have been created with dup(2). Mike. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Chris Wedgwood wrote:
(B On Wed, Apr 20, 2005 at 04:57:31PM +0900, Takashi Ikebe wrote:
(B
(B
(Bhmm.. most internet base services will use TCPv4 TCPv6 SCTP...
(BAF_UNIX can not use as inter-nodes communication.
(B
(B
(B You can send file descriptors (the actually file descriptors
(B themselves, not their contents) to another process over a socket.
(B
(B A nearly ten-year old example is attached (ie. this isn't new or
(B magical or specific to Linux).
(B
(B
(B
(B
(B int main()
(B {
(B int fds[2];
(B int fd = -1;
(B int rc = socketpair(AF_UNIX, SOCK_STREAM, 0, fds);
(BHmm interest enough,
(BBut please see man.
(B
(BNOTES
(B On Linux, the only supported domain for this call is AF_UNIX (or
(B syn-
(B onymously, AF_LOCAL). (Most implementations have the same
(Brestric-
(B tion.)
(B
(BOnly for AF_UNIX..
(B
(B
(BWell, as many said Live patching is very historical authoritative
(Bfunction on especially carrier, telecom vendor.
(BIf linux want to be adopted on mission critical world, this function is
(Besseintial.
(B
(B--
(BTakashi Ikebe
(BNTT Network Service Systems Laboratories
(B9-11, Midori-Cho 3-Chome Musashino-Shi,
(BTokyo 180-8585 Japan
(BTel : +81 422 59 4246, Fax : +81 422 60 4012
(Be-mail : [EMAIL PROTECTED]
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Wed, Apr 20, 2005 at 05:45:00PM +0900, Takashi Ikebe wrote: Only for AF_UNIX.. I'm sure that means AF_UNIX is restricted for the socket you use to pass the file descriptors, not a restriction on the file descriptors themselves. I don't see why the kernel would care what the descriptors are. Well, as many said Live patching is very historical authoritative function on especially carrier, telecom vendor. Linux doesn't have it now, do it's not historical in the Linux space. If linux want to be adopted on mission critical world, this function is esseintial. But Linux is used in mission critical places and we don't have that feature. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Wed, 20 Apr 2005, Takashi Ikebe wrote: Well, as many said Live patching is very historical authoritative function on especially carrier, telecom vendor. If linux want to be adopted on mission critical world, this function is esseintial. Yes, if you want to use Linux in those scenarios you will need to change the telco programs to use shared memory and file descriptor passing, instead of live patching. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 02:25:06AM -0700, Chris Wedgwood wrote: The call switching folks have been doing live patching at least since I worked on it, over 25 years ago. This is not just marketing. That still doesn't explain *why* live patching is needed. The more optimization a modern compiler does the less practical a patching approach seems for anything but very trivial fixes. I'd try a shared library based approach for on the fly updates. Ralf - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Rik van Riel wrote: On Wed, 20 Apr 2005, Takashi Ikebe wrote: Well, as many said Live patching is very historical authoritative function on especially carrier, telecom vendor. If linux want to be adopted on mission critical world, this function is esseintial. Yes, if you want to use Linux in those scenarios you will need to change the telco programs to use shared memory and file descriptor passing, instead of live patching. Unfortunately we're also dealing (in many cases) with pre-existing software coming over from other OS's. The beancounters want to avoid rewriting the millions of lines of application code, so they'd rather add the missing support to the kernel. If it doesn't go into mainline, we'll just end up with a bunch of different telco-patches being maintained on the side. I highly doubt all the applications will get fixed any time soon. Chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Ralf Baechle wrote: I'd try a shared library based approach for on the fly updates. The version that I've seen imposed requirements on the application for this to work properly. There are tradeoffs either way. Chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Wed, Apr 20, 2005 at 01:18:23PM +0900, Takashi Ikebe wrote: > Well, Live patching is just a patch, so I think the developer of > patch should know the original source code well. In which case they could fix the application. > Well, as you said some application can do that, but some application > can not continue service with your suggestion. Such as? > please think about the process which use connection type > communication such as TCP(it's only example) between users and > server. During status copy, all the session between users and server > are disconnected... They don't have to be. > can not save the exiting service at all. Yes they can. > It's one example, but similar problems may occurs whenever processed > use the resources which are mainly controlled by kernel. What resources? We can migrate memory and file descriptors? What is missing? Anyhow, you seem hell bent on this despite showing any real evidence it's useful or desirable... maybe a different audience for your patches would help? http://selenic.com/mailman/listinfo/kernel-mentors might be of value to you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Takashi Ikebe wrote: (B (B>Sorry, I may mistake the point, (B>Chris Wedgwood wrote: (B> (B> (B>>that would also be a problem for live patching too, if you have bad (B>>state, you have bad state --- live patching doesn't change that (B>> (B>> (B>What I want to say is takeover may makes memory unstable, because there (B>are extra operations to reserve current (unstable) status to memory. (B>Live patching never force target process to reserve status to memory. Is (B>this make sense? (B> (B> (BSorry, I misunderstand it, forget above comment, both methods are (Bpossible to destroy memory. (B (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Takashi Ikebe wrote: (B (BSorry, I may mistake the point, (BChris Wedgwood wrote: (B (B (Bthat would also be a problem for live patching too, if you have bad (Bstate, you have bad state --- live patching doesn't change that (B (B (BWhat I want to say is takeover may makes memory unstable, because there (Bare extra operations to reserve current (unstable) status to memory. (BLive patching never force target process to reserve status to memory. Is (Bthis make sense? (B (B (BSorry, I misunderstand it, forget above comment, both methods are (Bpossible to destroy memory. (B (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Wed, Apr 20, 2005 at 01:18:23PM +0900, Takashi Ikebe wrote: Well, Live patching is just a patch, so I think the developer of patch should know the original source code well. In which case they could fix the application. Well, as you said some application can do that, but some application can not continue service with your suggestion. Such as? please think about the process which use connection type communication such as TCP(it's only example) between users and server. During status copy, all the session between users and server are disconnected... They don't have to be. can not save the exiting service at all. Yes they can. It's one example, but similar problems may occurs whenever processed use the resources which are mainly controlled by kernel. What resources? We can migrate memory and file descriptors? What is missing? Anyhow, you seem hell bent on this despite showing any real evidence it's useful or desirable... maybe a different audience for your patches would help? http://selenic.com/mailman/listinfo/kernel-mentors might be of value to you. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Tue, Apr 19, 2005 at 02:19:57PM +0900, Takashi Ikebe wrote: > What I want to say is takeover may makes memory unstable, because > there are extra operations to reserve current (unstable) status to > memory. mmap is coherent between processes > Live patching never force target process to reserve status to memory. Is > this make sense? Not really. I don't see how it makes it any better or easier, just different. > I think the point is how long does it takes to hand the fd off to > another process. (means how long time the network port is > unavailable??) Probably under 1 ms. Not long anyhow. > Please see and try http://pannus.sourceforge.net > There includes commands and some samples. pannus-sample.tgz contains some pretty contrived examples, nothing that anyone could really sensibly comment on > On live patching, you never need to use shared memory, just prepare > fixed code, and just compile it as shared ibject, that's all. pretty > easy and fast to replace the functions. it requires magic like a compiler and knowledge of the original application. if the application was written sensibly someone without access to the application code could change this live taking over the previous applications state even more easily --- and the code would be more straightforward. so i still fail to see why this is needed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Sorry, I may mistake the point, (BChris Wedgwood wrote: (B (B>>For me, is seems very dangerous to estimate the primary copy is not (B>>broken through status takeover.. (B>> (B>> (B> (B>that would also be a problem for live patching too, if you have bad (B>state, you have bad state --- live patching doesn't change that (B> (B> (BWhat I want to say is takeover may makes memory unstable, because there (Bare extra operations to reserve current (unstable) status to memory. (BLive patching never force target process to reserve status to memory. Is (Bthis make sense? (B (B>>Some process use critical resources such as fixed network listen (B>>port can not speed up so. (B>> (B>> (B> (B>hand the fd off to another process (B> (B> (BI think the point is how long does it takes to hand the fd off to (Banother process.(means how long time the network port is unavailable??) (B (B>>More importantly, the only process who prepare to use this mechanism (B>>only allows to use quick process takeover. (B>> (B>> (B> (B>no, i can mmap state or similar, hand fd's off and switch to another (B>process in a context switch... hot patching i bet is going to be (B>slower (B> (B>how about you show up some code that needs this? (B> (B> (B>>This cause software development difficult. (B>> (B>> (B> (B>i honestly doubt in most cases you can hand live patch faster and more (B>easily than having the application sensibly written and passing it off (B> (B>please, prove me wrong, show us some code (B> (B> (BPlease see and try http://pannus.sourceforge.net (BThere includes commands and some samples. (BOn live patching, you never need to use shared memory, just prepare (Bfixed code, and just compile it as shared ibject, that's all. pretty (Beasy and fast to replace the functions. (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Tue, Apr 19, 2005 at 11:14:27AM +0900, Takashi Ikebe wrote: > this makes software developer crazy are you serious? how is live patching of .text easier than some of the other suggestions which all are more or less sane and things like gdb, oprofile, etc. will deal with w/o problems? patching code in a running process is way complicated and messy, if you think this is the easier solution i guess i have little more to say > For me, is seems very dangerous to estimate the primary copy is not > broken through status takeover.. that would also be a problem for live patching too, if you have bad state, you have bad state --- live patching doesn't change that > Some process use critical resources such as fixed network listen > port can not speed up so. hand the fd off to another process > More importantly, the only process who prepare to use this mechanism > only allows to use quick process takeover. no, i can mmap state or similar, hand fd's off and switch to another process in a context switch... hot patching i bet is going to be slower how about you show up some code that needs this? > This cause software development difficult. i honestly doubt in most cases you can hand live patch faster and more easily than having the application sensibly written and passing it off please, prove me wrong, show us some code > The live patching does not require to implement such special > techniques on applications. this is like saying live patching is a complicated in-kernel solution for badly written userspace isn't it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Rik van Riel wrote: (B (B>On Mon, 18 Apr 2005, Takashi Ikebe wrote: (B> (B> (B> (B>>I believe process status copy consume more time, may be below sequences are (B>>needed; (B>>- Stop the service on ACT-process. (B>>- Copy on memory/on transaction status to shared memory. (B>> (B>> (B> (B>No need for this, the process could ALWAYS store its (B>status in a shared memory status. This is just as (B>fast as private memory, only more flexible (B> (B> (BI don't think so, because ACT process must stop service logic to (Btakeover, if the service use network listen port.(ACT process need to (Bstop service and close socket to take over.) (B (B>>- Takeover shared memory key to SBY process and release the shared memory (B>>- SBY process access to shared memory. (B>> (B>> (B> (B>Which means the SBY process can attach to the shared (B>memory region while the ACT process is running. It (B>can then communicate with the ACT process through a (B>socket ... (B> (B> (Bthis makes software developer crazy (B (B>>- SBY process checks the memory and reset broken sessions. (B>>- SBY process restart the service. (B>> (B>> (B> (B>... and the SBY process can take over immediately. (B>The state machine running the SBY software can (B>continue using the same data structures the ACT (B>process was using beforehand, since they're in a (B>shared memory region. (B> (B> (B>>Some part may be parallelize, but seems the more data make service (B>>disruption time longer...(It seems exceeds 100 milliseconds depends on (B>>data size..) and process will be more complicatedmakes more bugs... (B>> (B>> (B> (B>The data size should not be an issue, since the primary (B>copy of the state is in the shared memory area. (B> (B> (BFor me, is seems very dangerous to estimate the primary copy is not (Bbroken through status takeover.. (B (B>The state machine in the SBY process can directly run (B>using those data structures, so no copying is needed. (B> (B>The only overhead will be inter-process communication, (B>having the first process close file descriptors, yielding (B>the CPU to the second process, which then opens up the (B>devices again. We both know how long a context switch (B>and an open() syscall take - negligable. (B> (B>The old version of the program can shut itself down (B>after it knows the new version has taken over - in the (B>background, without disrupting the now active process. (B> (B> (B> (BI think your assumption works on some type of process, but not for all (Bthe process. (BSome process use critical resources such as fixed network listen port (Bcan not speed up so. (BMore importantly, the only process who prepare to use this mechanism (Bonly allows to use quick process takeover. This cause software (Bdevelopment difficult. (BThe live patching does not require to implement such special techniques (Bon applications. (B (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
> That still doesn't explain *why* live patching is needed. True enough. When a requirement is based in 30 years of tradition and practice, it takes work to to back it up to the essentials that would distinguish accurately between adequate and inadequate alternatives. And that I presume is what you mean by the emphasized *why*. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, 18 Apr 2005, Takashi Ikebe wrote: > I believe process status copy consume more time, may be below sequences are > needed; > - Stop the service on ACT-process. > - Copy on memory/on transaction status to shared memory. No need for this, the process could ALWAYS store its status in a shared memory status. This is just as fast as private memory, only more flexible. > - Takeover shared memory key to SBY process and release the shared memory > - SBY process access to shared memory. Which means the SBY process can attach to the shared memory region while the ACT process is running. It can then communicate with the ACT process through a socket ... > - SBY process checks the memory and reset broken sessions. > - SBY process restart the service. ... and the SBY process can take over immediately. The state machine running the SBY software can continue using the same data structures the ACT process was using beforehand, since they're in a shared memory region. > Some part may be parallelize, but seems the more data make service > disruption time longer...(It seems exceeds 100 milliseconds depends on > data size..) and process will be more complicatedmakes more bugs... The data size should not be an issue, since the primary copy of the state is in the shared memory area. The state machine in the SBY process can directly run using those data structures, so no copying is needed. The only overhead will be inter-process communication, having the first process close file descriptors, yielding the CPU to the second process, which then opens up the devices again. We both know how long a context switch and an open() syscall take - negligable. The old version of the program can shut itself down after it knows the new version has taken over - in the background, without disrupting the now active process. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Hello, Rik van Riel wrote: On Mon, 18 Apr 2005, Chris Wedgwood wrote: On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote: The call switching folks have been doing live patching at least since I worked on it, over 25 years ago. This is not just marketing. That still doesn't explain *why* live patching is needed. I suspect it was needed in the past, on embedded computers so small they could only run one program at a time. I see no reason why changing programs on the fly couldn't be done nicer with SHM segments today - just start up the new program in parallel with the old one, have it attach to the SHM region and handshake with the old program to take over operations. At that point the old program can let go of file descriptors (eg. those to devices), yield the CPU and the new program can open those file descriptors. The SHM area contains all of the state information needed, so the program can continue running like it always would. This may well be lower latency than live patching, and probably lower complexity/risk too... I think most important thing for carrier system is service availability. The live patch only stops process(which have 3 threads) 180 nanoseconds with 2functions, 2 variable changes on my linux desktop(Xeon 2.8G dual). (on sample 1) I believe process status copy consume more time, may be below sequences are needed; - Stop the service on ACT-process. - Copy on memory/on transaction status to shared memory. - Takeover shared memory key to SBY process and release the shared memory - SBY process access to shared memory. - SBY process checks the memory and reset broken sessions. - SBY process restart the service. Some part may be parallelize, but seems the more data make service disruption time longer...(It seems exceeds 100 milliseconds depends on data size..) and process will be more complicatedmakes more bugs... -- Takashi Ikebe NTT Network Service Systems Laboratories 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Tel : +81 422 59 4246, Fax : +81 422 60 4012 e-mail : [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, 18 Apr 2005, Chris Wedgwood wrote: > On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote: > > > The call switching folks have been doing live patching at least > > since I worked on it, over 25 years ago. This is not just > > marketing. > > That still doesn't explain *why* live patching is needed. I suspect it was needed in the past, on embedded computers so small they could only run one program at a time. I see no reason why changing programs on the fly couldn't be done nicer with SHM segments today - just start up the new program in parallel with the old one, have it attach to the SHM region and handshake with the old program to take over operations. At that point the old program can let go of file descriptors (eg. those to devices), yield the CPU and the new program can open those file descriptors. The SHM area contains all of the state information needed, so the program can continue running like it always would. This may well be lower latency than live patching, and probably lower complexity/risk too... -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Takashi Ikebe <[EMAIL PROTECTED]> wrote: > systr_pmem_read() and systr_pmem_write() just calls ptrace > PTRACE_PEEKTEXT/DATA repeatedly In this case we need to *stop* target > process whenever patch modules is loading You'll have to do that anyway, since you'll need to atomically store two machine words. At least you'll have to lock access to the corresponding memory page(s). -- Error, no keyboard -- press F1 to continue. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote: > The call switching folks have been doing live patching at least > since I worked on it, over 25 years ago. This is not just > marketing. That still doesn't explain *why* live patching is needed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Chris wrote: > Linux doesn't guarantee you'll get scheduled > (strictly speaking) in n milliseconds usually. The general case load doesn't apply here. Those doing call switching know what they have running, and know that it won't give the scheduler any opportunities to not run what must be run, in time. Given a sufficiently short run queue, the scheduler is quite predictable. And there is difference between the entire system being down for over 100 milliseconds, and a given call being delayed that long. Under sufficient load (busiest hour on Mothers Day, say), the system must continue to operate, though some switching may be delayed longer than normal, though still within specified limits. > > This function is very essential whenever ... > > Those are just marketing words. > ... > I'm guessing any suggestion of fixing the applications behavior would > be lost with some argument along the lines of ... The call switching folks have been doing live patching at least since I worked on it, over 25 years ago. This is not just marketing. No sense in being disrespectful to Takashi-san. This patch may or may not be the best way to provide the functionality they require. I don't even know if a kernel patch is needed. But the tone of this thread won't lead anyone to better answers anytime soon. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 11:03:39AM +0100, James Courtier-Dutton wrote: > I can only think of one other system that might benefit from live > updates, and that is set top boxes, so bugs can be fixed without the > user knowing. hardly mission critical and usually don't have the resources to do complicate things much better to rexec/reboot as needed > This also can be worked around by downloading the bug fixes and only > installing the bugs fixes when the user is not viewing the > TV. E.g. When the box has been placed in standby by the user. again it doesn't need live patching (satellite and cable boxes update themselves routinely, some certainly do need to periodically reboot to do this and it's apparently not a problem) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Chris Friesen wrote: > Chris Wedgwood wrote: > >> On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: >> >> >>> From our experience, sometimes patches became to dozens to hundreds >>> at one patching, and in this case GDB based approach cause target >>> process's availability descent. > > >> could you perhaps explain some *real* *world* applications/systems >> where this is necessary and why existing APIs won't work with them >> perhaps? > > > In the telecom space it's quite common to want to modify multiple > running binaries with as little downtime as possible. (Beyond a > threshold it becomes FCC-reportable in the US, and everyone wants to > avoid that...) > > Our old proprietary OS had explicit support for replacing running binary > code on the fly, so customers have gotten used to the ability. Now they > want equivalent functionality with our linux-based stuff. > > We've done some proprietary stuff (ie. pre-OSDL CGL) in this area, but > it was apparently a real pain and was quite restrictive on the > application writers. (I was not involved with that portion of the project.) > > For general application support I suspect some kernel support will be > required. Whether this is the way to go or whether it can be done using > existing mechanisms, I'm not knowledgeable enough to comment. > > Chris > - I raised a thread like this about 1 year ago. I was asking for it from the point of view of a Telco. After some discussions on this list, I came to agree with the posts on the list by other people that the feature is not needed. At least certainly not needed in the Telco space. 99.999% uptime is much better acheived with the use of clustering, rather than trying to upgrade software in a Live situation. In a clustered environment, one offloads all the tasks from machine A and spread them across the cluster. Once the machine A is not doing any work at all, you can upgrade, reboot, whatever you like, and then add it back to the cluster. This approach is much less risky than live module updates. If the equipment is not clustered, it will at least be 2 to 1 redundent, so you just upgrade the redundent device, manually force a fail over, and then upgrade the other device. Again, no live update required. I can only think of one other system that might benefit from live updates, and that is set top boxes, so bugs can be fixed without the user knowing. This also can be worked around by downloading the bug fixes and only installing the bugs fixes when the user is not viewing the TV. E.g. When the box has been placed in standby by the user. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 05:37:09PM +0900, Takashi Ikebe wrote: > As you said, if we can migrate the data to new process without > stopping service, it is OK, but the real applications need to > takeover data very much(sometimes it's over gigabytedepends on > service, and causes service disruption...). man mmap man 5 ipc > So, live patching seems reasonable to us. That still doesn't tell me why it's necessary to do something so complicated > 2. Activate the patch modules with pannus -a command. > - stop the target process and check current instruction not to conflict. > - if it is not conflict, overwrite the jump assembly to function's > entrypoiny where you want to fix, to patch module's one. > - restart the process. there is a still a stop/start here why not just hand the state of to a different process? how is that slower? > Will this be answer?? maybe, but i'm far from convinced it's necessary and therefore warrants a big ugly kernel patch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
I'm sorry, I can not catch the point well, (Bbut what I want to say is, we do not want stop the service due to bug fix. (B (BAs you said, if we can migrate the data to new process without stopping (Bservice, it is OK, but the real applications need to takeover data very (Bmuch(sometimes it's over gigabytedepends on service, and causes (Bservice disruption...). So, live patching seems reasonable to us. (BAnd unfortunately the APIs which people suggested are all based on (Bptrace system calls. as you know, ptrace based data read/write needs to (Bstop the target process during read/write. We would like to minimize (Btarget process stopping time. (B (B>I'm guessing any suggestion of fixing the applications behavior would (B>be lost with some argument along the lines of: "this application was (B>written in 1824 by Ada Lovelace using pre-Roswell Alien Technology and (B>was certified NEBS compliant by the Deli Lama and god herself, so (B>clearly we can't touch a single line of it" or similar right? (Bwell, it's possibly, but the same problems occur on gdb. (BI think this depends on user's manner... (B (BI briefly describe the way of live patching below; (B1. Load the patch modules with pannus -l command. (B- load the patch module with first memory mapping system call(ptrace (BPEEKDATA can be same work, but it needs to stop target process..) (B- search patch module's initialize area and execute them with (Bexecinit.c(similler to signal handler) (B- target process exec initialization. (B2. Activate the patch modules with pannus -a command. (B- stop the target process and check current instruction not to conflict. (B- if it is not conflict, overwrite the jump assembly to function's (Bentrypoiny where you want to fix, to patch module's one. (B- restart the process. (B (BWill this be answer?? (B (BChris Wedgwood wrote: (B (B>On Mon, Apr 18, 2005 at 04:32:21PM +0900, Takashi Ikebe wrote: (B> (B> (B> (B>>The software does not allow to stops over 100 milliseconds at worst (B>>case. (B>> (B>> (B> (B>Out of interest, how do you ensure the process doesn't stop for that (B>long right now? Linux doesn't guarantee you'll get scheduled (B>(strictly speaking) in n milliseconds usually. (B> (B> (B> (B>>Not to descent the service availability, software fix due to bug, (B>>should not stop the service, and live patching is very historical (B>>function in telecoms world. (B>> (B>> (B> (B>Lots of really complicated and unnecessary things are common in the (B>telecoms world. (B> (B>For the example you gave I can think of several ways to migrate data (B>to a new process (if need be) in a timely manner without interruption. (B>None of these *require* live patching. (B> (B> (B> (B>>Every carrier, NEPs(Network Equipment Provider) provide/use this (B>>function to keep network service (such as telephone) available. (B>> (B>> (B> (B>How does this *require* live patching? (B> (B> (B> (B>>This function is very essential whenever the carrier use the linux (B>>as center of it's system. (B>> (B>> (B> (B>Those are just marketing words. (B> (B> (B> (B>>Therefore the live patching function should not stop the target (B>>process (service process) as possible as. the more times we stop the (B>>target process, the service goes unavailable... (B>> (B>> (B> (B>Love patching seems like a very complicated thing to get right and it (B>could potentially blow up. (B> (B>I'm guessing any suggestion of fixing the applications behavior would (B>be lost with some argument along the lines of: "this application was (B>written in 1824 by Ada Lovelace using pre-Roswell Alien Technology and (B>was certified NEBS compliant by the Deli Lama and god herself, so (B>clearly we can't touch a single line of it" or similar right? (B> (B> (B (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 04:32:21PM +0900, Takashi Ikebe wrote: > The software does not allow to stops over 100 milliseconds at worst > case. Out of interest, how do you ensure the process doesn't stop for that long right now? Linux doesn't guarantee you'll get scheduled (strictly speaking) in n milliseconds usually. > Not to descent the service availability, software fix due to bug, > should not stop the service, and live patching is very historical > function in telecoms world. Lots of really complicated and unnecessary things are common in the telecoms world. For the example you gave I can think of several ways to migrate data to a new process (if need be) in a timely manner without interruption. None of these *require* live patching. > Every carrier, NEPs(Network Equipment Provider) provide/use this > function to keep network service (such as telephone) available. How does this *require* live patching? > This function is very essential whenever the carrier use the linux > as center of it's system. Those are just marketing words. > Therefore the live patching function should not stop the target > process (service process) as possible as. the more times we stop the > target process, the service goes unavailable... Love patching seems like a very complicated thing to get right and it could potentially blow up. I'm guessing any suggestion of fixing the applications behavior would be lost with some argument along the lines of: "this application was written in 1824 by Ada Lovelace using pre-Roswell Alien Technology and was certified NEBS compliant by the Deli Lama and god herself, so clearly we can't touch a single line of it" or similar right? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
For example, please think about telephone switching software. (BThe software does not allow to stops over 100 milliseconds at worst (Bcase.(this depends on how many customers are using, the more customers (Bare using, the allowable stopping time goes to shorter.) (BAnd the system is required over 99.999% availability, so typically, the (Bsystem is constructed as ACT-SBY high-availability clustering model. (BIn the case of critical error the system takeover the service process to (BSBY node. (BNot to descent the service availability, software fix due to bug, should (Bnot stop the service, and live patching is very historical function in (Btelecoms world. (BEvery carrier, NEPs(Network Equipment Provider) provide/use this (Bfunction to keep network service(such as telephone) available. (BThis function is very essential whenever the carrier use the linux as (Bcenter of it's system. (B (BTherefore the live patching function should not stop the target (Bprocess(service process) as possible as. the more times we stop the (Btarget process, the service goes unavailable... (B (B (BChris Wedgwood wrote: (B (B>On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: (B> (B> (B> (B>>From our experience, sometimes patches became to dozens to hundreds (B>>at one patching, and in this case GDB based approach cause target (B>>process's availability descent. (B>> (B>> (B> (B>i don't really buy that it can't be done or you complex patches are (B>necessary to be honest --- and there are various alternative APIs that (B>could help as others have pointed out (B> (B> (B>could you perhaps explain some *real* *world* applications/systems (B>where this is necessary and why existing APIs won't work with them (B>perhaps? (B> (B>solving a real-world problem is much more interesting to listen to (B>that filling in a check-box on a (somewhat dubious) specification (B>- (B>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in (B>the body of a message to [EMAIL PROTECTED] (B>More majordomo info at http://vger.kernel.org/majordomo-info.html (B>Please read the FAQ at http://www.tux.org/lkml/ (B> (B> (B (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 12:35:04AM -0600, Chris Friesen wrote: > In the telecom space it's quite common to want to modify multiple > running binaries with as little downtime as possible. OK > (Beyond a threshold it becomes FCC-reportable in the US, and > everyone wants to avoid that...) That's beside the point. > Our old proprietary OS had explicit support for replacing running > binary code on the fly, so customers have gotten used to the > ability. Now they want equivalent functionality with our > linux-based stuff. *Why* do they need this is what I asked. A sensible real world example would be useful. > For general application support I suspect some kernel support will > be required. Whether this is the way to go or whether it can be > done using existing mechanisms, I'm not knowledgeable enough to > comment. I used to work in telco space, we had some such systems and similar things. Some from Nortel even. None of the things I saw did anything that I can image really need a complicated kernel patch for. In fact, I'm not convinced *any* of these uses really needed live-patching at all. I would just like some examples of real-world needs and an explanation of why it's needed. Not handy-waving. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Chris Wedgwood wrote: On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: From our experience, sometimes patches became to dozens to hundreds at one patching, and in this case GDB based approach cause target process's availability descent. could you perhaps explain some *real* *world* applications/systems where this is necessary and why existing APIs won't work with them perhaps? In the telecom space it's quite common to want to modify multiple running binaries with as little downtime as possible. (Beyond a threshold it becomes FCC-reportable in the US, and everyone wants to avoid that...) Our old proprietary OS had explicit support for replacing running binary code on the fly, so customers have gotten used to the ability. Now they want equivalent functionality with our linux-based stuff. We've done some proprietary stuff (ie. pre-OSDL CGL) in this area, but it was apparently a real pain and was quite restrictive on the application writers. (I was not involved with that portion of the project.) For general application support I suspect some kernel support will be required. Whether this is the way to go or whether it can be done using existing mechanisms, I'm not knowledgeable enough to comment. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: > From our experience, sometimes patches became to dozens to hundreds > at one patching, and in this case GDB based approach cause target > process's availability descent. i don't really buy that it can't be done or you complex patches are necessary to be honest --- and there are various alternative APIs that could help as others have pointed out could you perhaps explain some *real* *world* applications/systems where this is necessary and why existing APIs won't work with them perhaps? solving a real-world problem is much more interesting to listen to that filling in a check-box on a (somewhat dubious) specification - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: From our experience, sometimes patches became to dozens to hundreds at one patching, and in this case GDB based approach cause target process's availability descent. i don't really buy that it can't be done or you complex patches are necessary to be honest --- and there are various alternative APIs that could help as others have pointed out could you perhaps explain some *real* *world* applications/systems where this is necessary and why existing APIs won't work with them perhaps? solving a real-world problem is much more interesting to listen to that filling in a check-box on a (somewhat dubious) specification - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Chris Wedgwood wrote: On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: From our experience, sometimes patches became to dozens to hundreds at one patching, and in this case GDB based approach cause target process's availability descent. could you perhaps explain some *real* *world* applications/systems where this is necessary and why existing APIs won't work with them perhaps? In the telecom space it's quite common to want to modify multiple running binaries with as little downtime as possible. (Beyond a threshold it becomes FCC-reportable in the US, and everyone wants to avoid that...) Our old proprietary OS had explicit support for replacing running binary code on the fly, so customers have gotten used to the ability. Now they want equivalent functionality with our linux-based stuff. We've done some proprietary stuff (ie. pre-OSDL CGL) in this area, but it was apparently a real pain and was quite restrictive on the application writers. (I was not involved with that portion of the project.) For general application support I suspect some kernel support will be required. Whether this is the way to go or whether it can be done using existing mechanisms, I'm not knowledgeable enough to comment. Chris - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 12:35:04AM -0600, Chris Friesen wrote: In the telecom space it's quite common to want to modify multiple running binaries with as little downtime as possible. OK (Beyond a threshold it becomes FCC-reportable in the US, and everyone wants to avoid that...) That's beside the point. Our old proprietary OS had explicit support for replacing running binary code on the fly, so customers have gotten used to the ability. Now they want equivalent functionality with our linux-based stuff. *Why* do they need this is what I asked. A sensible real world example would be useful. For general application support I suspect some kernel support will be required. Whether this is the way to go or whether it can be done using existing mechanisms, I'm not knowledgeable enough to comment. I used to work in telco space, we had some such systems and similar things. Some from Nortel even. None of the things I saw did anything that I can image really need a complicated kernel patch for. In fact, I'm not convinced *any* of these uses really needed live-patching at all. I would just like some examples of real-world needs and an explanation of why it's needed. Not handy-waving. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
For example, please think about telephone switching software. (BThe software does not allow to stops over 100 milliseconds at worst (Bcase.(this depends on how many customers are using, the more customers (Bare using, the allowable stopping time goes to shorter.) (BAnd the system is required over 99.999% availability, so typically, the (Bsystem is constructed as ACT-SBY high-availability clustering model. (BIn the case of critical error the system takeover the service process to (BSBY node. (BNot to descent the service availability, software fix due to bug, should (Bnot stop the service, and live patching is very historical function in (Btelecoms world. (BEvery carrier, NEPs(Network Equipment Provider) provide/use this (Bfunction to keep network service(such as telephone) available. (BThis function is very essential whenever the carrier use the linux as (Bcenter of it's system. (B (BTherefore the live patching function should not stop the target (Bprocess(service process) as possible as. the more times we stop the (Btarget process, the service goes unavailable... (B (B (BChris Wedgwood wrote: (B (BOn Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: (B (B (B (BFrom our experience, sometimes patches became to dozens to hundreds (Bat one patching, and in this case GDB based approach cause target (Bprocess's availability descent. (B (B (B (Bi don't really buy that it can't be done or you complex patches are (Bnecessary to be honest --- and there are various alternative APIs that (Bcould help as others have pointed out (B (B (Bcould you perhaps explain some *real* *world* applications/systems (Bwhere this is necessary and why existing APIs won't work with them (Bperhaps? (B (Bsolving a real-world problem is much more interesting to listen to (Bthat filling in a check-box on a (somewhat dubious) specification (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/ (B (B (B (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 04:32:21PM +0900, Takashi Ikebe wrote: The software does not allow to stops over 100 milliseconds at worst case. Out of interest, how do you ensure the process doesn't stop for that long right now? Linux doesn't guarantee you'll get scheduled (strictly speaking) in n milliseconds usually. Not to descent the service availability, software fix due to bug, should not stop the service, and live patching is very historical function in telecoms world. Lots of really complicated and unnecessary things are common in the telecoms world. For the example you gave I can think of several ways to migrate data to a new process (if need be) in a timely manner without interruption. None of these *require* live patching. Every carrier, NEPs(Network Equipment Provider) provide/use this function to keep network service (such as telephone) available. How does this *require* live patching? This function is very essential whenever the carrier use the linux as center of it's system. Those are just marketing words. Therefore the live patching function should not stop the target process (service process) as possible as. the more times we stop the target process, the service goes unavailable... Love patching seems like a very complicated thing to get right and it could potentially blow up. I'm guessing any suggestion of fixing the applications behavior would be lost with some argument along the lines of: this application was written in 1824 by Ada Lovelace using pre-Roswell Alien Technology and was certified NEBS compliant by the Deli Lama and god herself, so clearly we can't touch a single line of it or similar right? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
I'm sorry, I can not catch the point well, (Bbut what I want to say is, we do not want stop the service due to bug fix. (B (BAs you said, if we can migrate the data to new process without stopping (Bservice, it is OK, but the real applications need to takeover data very (Bmuch(sometimes it's over gigabytedepends on service, and causes (Bservice disruption...). So, live patching seems reasonable to us. (BAnd unfortunately the APIs which people suggested are all based on (Bptrace system calls. as you know, ptrace based data read/write needs to (Bstop the target process during read/write. We would like to minimize (Btarget process stopping time. (B (BI'm guessing any suggestion of fixing the applications behavior would (Bbe lost with some argument along the lines of: "this application was (Bwritten in 1824 by Ada Lovelace using pre-Roswell Alien Technology and (Bwas certified NEBS compliant by the Deli Lama and god herself, so (Bclearly we can't touch a single line of it" or similar right? (Bwell, it's possibly, but the same problems occur on gdb. (BI think this depends on user's manner... (B (BI briefly describe the way of live patching below; (B1. Load the patch modules with pannus -l command. (B- load the patch module with first memory mapping system call(ptrace (BPEEKDATA can be same work, but it needs to stop target process..) (B- search patch module's initialize area and execute them with (Bexecinit.c(similler to signal handler) (B- target process exec initialization. (B2. Activate the patch modules with pannus -a command. (B- stop the target process and check current instruction not to conflict. (B- if it is not conflict, overwrite the jump assembly to function's (Bentrypoiny where you want to fix, to patch module's one. (B- restart the process. (B (BWill this be answer?? (B (BChris Wedgwood wrote: (B (BOn Mon, Apr 18, 2005 at 04:32:21PM +0900, Takashi Ikebe wrote: (B (B (B (BThe software does not allow to stops over 100 milliseconds at worst (Bcase. (B (B (B (BOut of interest, how do you ensure the process doesn't stop for that (Blong right now? Linux doesn't guarantee you'll get scheduled (B(strictly speaking) in n milliseconds usually. (B (B (B (BNot to descent the service availability, software fix due to bug, (Bshould not stop the service, and live patching is very historical (Bfunction in telecoms world. (B (B (B (BLots of really complicated and unnecessary things are common in the (Btelecoms world. (B (BFor the example you gave I can think of several ways to migrate data (Bto a new process (if need be) in a timely manner without interruption. (BNone of these *require* live patching. (B (B (B (BEvery carrier, NEPs(Network Equipment Provider) provide/use this (Bfunction to keep network service (such as telephone) available. (B (B (B (BHow does this *require* live patching? (B (B (B (BThis function is very essential whenever the carrier use the linux (Bas center of it's system. (B (B (B (BThose are just marketing words. (B (B (B (BTherefore the live patching function should not stop the target (Bprocess (service process) as possible as. the more times we stop the (Btarget process, the service goes unavailable... (B (B (B (BLove patching seems like a very complicated thing to get right and it (Bcould potentially blow up. (B (BI'm guessing any suggestion of fixing the applications behavior would (Bbe lost with some argument along the lines of: "this application was (Bwritten in 1824 by Ada Lovelace using pre-Roswell Alien Technology and (Bwas certified NEBS compliant by the Deli Lama and god herself, so (Bclearly we can't touch a single line of it" or similar right? (B (B (B (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 05:37:09PM +0900, Takashi Ikebe wrote: As you said, if we can migrate the data to new process without stopping service, it is OK, but the real applications need to takeover data very much(sometimes it's over gigabytedepends on service, and causes service disruption...). man mmap man 5 ipc So, live patching seems reasonable to us. That still doesn't tell me why it's necessary to do something so complicated 2. Activate the patch modules with pannus -a command. - stop the target process and check current instruction not to conflict. - if it is not conflict, overwrite the jump assembly to function's entrypoiny where you want to fix, to patch module's one. - restart the process. there is a still a stop/start here why not just hand the state of to a different process? how is that slower? Will this be answer?? maybe, but i'm far from convinced it's necessary and therefore warrants a big ugly kernel patch - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Chris Friesen wrote: Chris Wedgwood wrote: On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: From our experience, sometimes patches became to dozens to hundreds at one patching, and in this case GDB based approach cause target process's availability descent. could you perhaps explain some *real* *world* applications/systems where this is necessary and why existing APIs won't work with them perhaps? In the telecom space it's quite common to want to modify multiple running binaries with as little downtime as possible. (Beyond a threshold it becomes FCC-reportable in the US, and everyone wants to avoid that...) Our old proprietary OS had explicit support for replacing running binary code on the fly, so customers have gotten used to the ability. Now they want equivalent functionality with our linux-based stuff. We've done some proprietary stuff (ie. pre-OSDL CGL) in this area, but it was apparently a real pain and was quite restrictive on the application writers. (I was not involved with that portion of the project.) For general application support I suspect some kernel support will be required. Whether this is the way to go or whether it can be done using existing mechanisms, I'm not knowledgeable enough to comment. Chris - I raised a thread like this about 1 year ago. I was asking for it from the point of view of a Telco. After some discussions on this list, I came to agree with the posts on the list by other people that the feature is not needed. At least certainly not needed in the Telco space. 99.999% uptime is much better acheived with the use of clustering, rather than trying to upgrade software in a Live situation. In a clustered environment, one offloads all the tasks from machine A and spread them across the cluster. Once the machine A is not doing any work at all, you can upgrade, reboot, whatever you like, and then add it back to the cluster. This approach is much less risky than live module updates. If the equipment is not clustered, it will at least be 2 to 1 redundent, so you just upgrade the redundent device, manually force a fail over, and then upgrade the other device. Again, no live update required. I can only think of one other system that might benefit from live updates, and that is set top boxes, so bugs can be fixed without the user knowing. This also can be worked around by downloading the bug fixes and only installing the bugs fixes when the user is not viewing the TV. E.g. When the box has been placed in standby by the user. James - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 11:03:39AM +0100, James Courtier-Dutton wrote: I can only think of one other system that might benefit from live updates, and that is set top boxes, so bugs can be fixed without the user knowing. hardly mission critical and usually don't have the resources to do complicate things much better to rexec/reboot as needed This also can be worked around by downloading the bug fixes and only installing the bugs fixes when the user is not viewing the TV. E.g. When the box has been placed in standby by the user. again it doesn't need live patching (satellite and cable boxes update themselves routinely, some certainly do need to periodically reboot to do this and it's apparently not a problem) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Chris wrote: Linux doesn't guarantee you'll get scheduled (strictly speaking) in n milliseconds usually. The general case load doesn't apply here. Those doing call switching know what they have running, and know that it won't give the scheduler any opportunities to not run what must be run, in time. Given a sufficiently short run queue, the scheduler is quite predictable. And there is difference between the entire system being down for over 100 milliseconds, and a given call being delayed that long. Under sufficient load (busiest hour on Mothers Day, say), the system must continue to operate, though some switching may be delayed longer than normal, though still within specified limits. This function is very essential whenever ... Those are just marketing words. ... I'm guessing any suggestion of fixing the applications behavior would be lost with some argument along the lines of ... The call switching folks have been doing live patching at least since I worked on it, over 25 years ago. This is not just marketing. No sense in being disrespectful to Takashi-san. This patch may or may not be the best way to provide the functionality they require. I don't even know if a kernel patch is needed. But the tone of this thread won't lead anyone to better answers anytime soon. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote: The call switching folks have been doing live patching at least since I worked on it, over 25 years ago. This is not just marketing. That still doesn't explain *why* live patching is needed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Takashi Ikebe [EMAIL PROTECTED] wrote: systr_pmem_read() and systr_pmem_write() just calls ptrace PTRACE_PEEKTEXT/DATA repeatedly In this case we need to *stop* target process whenever patch modules is loading You'll have to do that anyway, since you'll need to atomically store two machine words. At least you'll have to lock access to the corresponding memory page(s). -- Error, no keyboard -- press F1 to continue. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, 18 Apr 2005, Chris Wedgwood wrote: On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote: The call switching folks have been doing live patching at least since I worked on it, over 25 years ago. This is not just marketing. That still doesn't explain *why* live patching is needed. I suspect it was needed in the past, on embedded computers so small they could only run one program at a time. I see no reason why changing programs on the fly couldn't be done nicer with SHM segments today - just start up the new program in parallel with the old one, have it attach to the SHM region and handshake with the old program to take over operations. At that point the old program can let go of file descriptors (eg. those to devices), yield the CPU and the new program can open those file descriptors. The SHM area contains all of the state information needed, so the program can continue running like it always would. This may well be lower latency than live patching, and probably lower complexity/risk too... -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Hello, Rik van Riel wrote: On Mon, 18 Apr 2005, Chris Wedgwood wrote: On Mon, Apr 18, 2005 at 02:16:09AM -0700, Paul Jackson wrote: The call switching folks have been doing live patching at least since I worked on it, over 25 years ago. This is not just marketing. That still doesn't explain *why* live patching is needed. I suspect it was needed in the past, on embedded computers so small they could only run one program at a time. I see no reason why changing programs on the fly couldn't be done nicer with SHM segments today - just start up the new program in parallel with the old one, have it attach to the SHM region and handshake with the old program to take over operations. At that point the old program can let go of file descriptors (eg. those to devices), yield the CPU and the new program can open those file descriptors. The SHM area contains all of the state information needed, so the program can continue running like it always would. This may well be lower latency than live patching, and probably lower complexity/risk too... I think most important thing for carrier system is service availability. The live patch only stops process(which have 3 threads) 180 nanoseconds with 2functions, 2 variable changes on my linux desktop(Xeon 2.8G dual). (on sample 1) I believe process status copy consume more time, may be below sequences are needed; - Stop the service on ACT-process. - Copy on memory/on transaction status to shared memory. - Takeover shared memory key to SBY process and release the shared memory - SBY process access to shared memory. - SBY process checks the memory and reset broken sessions. - SBY process restart the service. Some part may be parallelize, but seems the more data make service disruption time longer...(It seems exceeds 100 milliseconds depends on data size..) and process will be more complicatedmakes more bugs... -- Takashi Ikebe NTT Network Service Systems Laboratories 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Tel : +81 422 59 4246, Fax : +81 422 60 4012 e-mail : [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, 18 Apr 2005, Takashi Ikebe wrote: I believe process status copy consume more time, may be below sequences are needed; - Stop the service on ACT-process. - Copy on memory/on transaction status to shared memory. No need for this, the process could ALWAYS store its status in a shared memory status. This is just as fast as private memory, only more flexible. - Takeover shared memory key to SBY process and release the shared memory - SBY process access to shared memory. Which means the SBY process can attach to the shared memory region while the ACT process is running. It can then communicate with the ACT process through a socket ... - SBY process checks the memory and reset broken sessions. - SBY process restart the service. ... and the SBY process can take over immediately. The state machine running the SBY software can continue using the same data structures the ACT process was using beforehand, since they're in a shared memory region. Some part may be parallelize, but seems the more data make service disruption time longer...(It seems exceeds 100 milliseconds depends on data size..) and process will be more complicatedmakes more bugs... The data size should not be an issue, since the primary copy of the state is in the shared memory area. The state machine in the SBY process can directly run using those data structures, so no copying is needed. The only overhead will be inter-process communication, having the first process close file descriptors, yielding the CPU to the second process, which then opens up the devices again. We both know how long a context switch and an open() syscall take - negligable. The old version of the program can shut itself down after it knows the new version has taken over - in the background, without disrupting the now active process. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
That still doesn't explain *why* live patching is needed. True enough. When a requirement is based in 30 years of tradition and practice, it takes work to to back it up to the essentials that would distinguish accurately between adequate and inadequate alternatives. And that I presume is what you mean by the emphasized *why*. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Rik van Riel wrote: (B (BOn Mon, 18 Apr 2005, Takashi Ikebe wrote: (B (B (B (BI believe process status copy consume more time, may be below sequences are (Bneeded; (B- Stop the service on ACT-process. (B- Copy on memory/on transaction status to shared memory. (B (B (B (BNo need for this, the process could ALWAYS store its (Bstatus in a shared memory status. This is just as (Bfast as private memory, only more flexible (B (B (BI don't think so, because ACT process must stop service logic to (Btakeover, if the service use network listen port.(ACT process need to (Bstop service and close socket to take over.) (B (B- Takeover shared memory key to SBY process and release the shared memory (B- SBY process access to shared memory. (B (B (B (BWhich means the SBY process can attach to the shared (Bmemory region while the ACT process is running. It (Bcan then communicate with the ACT process through a (Bsocket ... (B (B (Bthis makes software developer crazy (B (B- SBY process checks the memory and reset broken sessions. (B- SBY process restart the service. (B (B (B (B... and the SBY process can take over immediately. (BThe state machine running the SBY software can (Bcontinue using the same data structures the ACT (Bprocess was using beforehand, since they're in a (Bshared memory region. (B (B (BSome part may be parallelize, but seems the more data make service (Bdisruption time longer...(It seems exceeds 100 milliseconds depends on (Bdata size..) and process will be more complicatedmakes more bugs... (B (B (B (BThe data size should not be an issue, since the primary (Bcopy of the state is in the shared memory area. (B (B (BFor me, is seems very dangerous to estimate the primary copy is not (Bbroken through status takeover.. (B (BThe state machine in the SBY process can directly run (Busing those data structures, so no copying is needed. (B (BThe only overhead will be inter-process communication, (Bhaving the first process close file descriptors, yielding (Bthe CPU to the second process, which then opens up the (Bdevices again. We both know how long a context switch (Band an open() syscall take - negligable. (B (BThe old version of the program can shut itself down (Bafter it knows the new version has taken over - in the (Bbackground, without disrupting the now active process. (B (B (B (BI think your assumption works on some type of process, but not for all (Bthe process. (BSome process use critical resources such as fixed network listen port (Bcan not speed up so. (BMore importantly, the only process who prepare to use this mechanism (Bonly allows to use quick process takeover. This cause software (Bdevelopment difficult. (BThe live patching does not require to implement such special techniques (Bon applications. (B (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Tue, Apr 19, 2005 at 11:14:27AM +0900, Takashi Ikebe wrote: this makes software developer crazy are you serious? how is live patching of .text easier than some of the other suggestions which all are more or less sane and things like gdb, oprofile, etc. will deal with w/o problems? patching code in a running process is way complicated and messy, if you think this is the easier solution i guess i have little more to say For me, is seems very dangerous to estimate the primary copy is not broken through status takeover.. that would also be a problem for live patching too, if you have bad state, you have bad state --- live patching doesn't change that Some process use critical resources such as fixed network listen port can not speed up so. hand the fd off to another process More importantly, the only process who prepare to use this mechanism only allows to use quick process takeover. no, i can mmap state or similar, hand fd's off and switch to another process in a context switch... hot patching i bet is going to be slower how about you show up some code that needs this? This cause software development difficult. i honestly doubt in most cases you can hand live patch faster and more easily than having the application sensibly written and passing it off please, prove me wrong, show us some code The live patching does not require to implement such special techniques on applications. this is like saying live patching is a complicated in-kernel solution for badly written userspace isn't it? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Sorry, I may mistake the point, (BChris Wedgwood wrote: (B (BFor me, is seems very dangerous to estimate the primary copy is not (Bbroken through status takeover.. (B (B (B (Bthat would also be a problem for live patching too, if you have bad (Bstate, you have bad state --- live patching doesn't change that (B (B (BWhat I want to say is takeover may makes memory unstable, because there (Bare extra operations to reserve current (unstable) status to memory. (BLive patching never force target process to reserve status to memory. Is (Bthis make sense? (B (BSome process use critical resources such as fixed network listen (Bport can not speed up so. (B (B (B (Bhand the fd off to another process (B (B (BI think the point is how long does it takes to hand the fd off to (Banother process.(means how long time the network port is unavailable??) (B (BMore importantly, the only process who prepare to use this mechanism (Bonly allows to use quick process takeover. (B (B (B (Bno, i can mmap state or similar, hand fd's off and switch to another (Bprocess in a context switch... hot patching i bet is going to be (Bslower (B (Bhow about you show up some code that needs this? (B (B (BThis cause software development difficult. (B (B (B (Bi honestly doubt in most cases you can hand live patch faster and more (Beasily than having the application sensibly written and passing it off (B (Bplease, prove me wrong, show us some code (B (B (BPlease see and try http://pannus.sourceforge.net (BThere includes commands and some samples. (BOn live patching, you never need to use shared memory, just prepare (Bfixed code, and just compile it as shared ibject, that's all. pretty (Beasy and fast to replace the functions. (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Tue, Apr 19, 2005 at 02:19:57PM +0900, Takashi Ikebe wrote: What I want to say is takeover may makes memory unstable, because there are extra operations to reserve current (unstable) status to memory. mmap is coherent between processes Live patching never force target process to reserve status to memory. Is this make sense? Not really. I don't see how it makes it any better or easier, just different. I think the point is how long does it takes to hand the fd off to another process. (means how long time the network port is unavailable??) Probably under 1 ms. Not long anyhow. Please see and try http://pannus.sourceforge.net There includes commands and some samples. pannus-sample.tgz contains some pretty contrived examples, nothing that anyone could really sensibly comment on On live patching, you never need to use shared memory, just prepare fixed code, and just compile it as shared ibject, that's all. pretty easy and fast to replace the functions. it requires magic like a compiler and knowledge of the original application. if the application was written sensibly someone without access to the application code could change this live taking over the previous applications state even more easily --- and the code would be more straightforward. so i still fail to see why this is needed. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Davide Libenzi wrote: (B (B>On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote: (B> (B> (B> (B>>On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: (B>> (B>> (B>>>GDB based approach seems not fit to our requirements. GDB(ptrace) based (B>>>functions are basically need to be done when target process is stopping. (B>>>In addition to that current PTRACE_PEEK/POKE* allows us to copy only a (B>>>*word* size... (B>>> (B>>> (B>>While true, this is easily fixable. (B>> (B>> (B> (B>Indeed, look at the systr_pmem_read() and systr_pmem_write() functions: (B> (B>http://www.xmailserver.org/sysctr.html (B> (B> (B> (Bsystr_pmem_read() and systr_pmem_write() just calls ptrace PTRACE_PEEKTEXT/DATA (Brepeatedly (BIn this case we need to *stop* target process whenever patch modules is (Bloading (BIt cause target process availability worse. (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, 18 Apr 2005 00:42:23 -0400
Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
> > GDB based approach seems not fit to our requirements. GDB(ptrace) based
> > functions are basically need to be done when target process is stopping.
> > In addition to that current PTRACE_PEEK/POKE* allows us to copy only a
> > *word* size...
>
> While true, this is easily fixable. There is even an interface
> precedent on OpenBSD (and possibly other platforms as well).
Some platforms even support the necessary PTRADE_{READ,WRITE}DATA
operations already, sparc is one such platform.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote: > On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: > > GDB based approach seems not fit to our requirements. GDB(ptrace) based > > functions are basically need to be done when target process is stopping. > > In addition to that current PTRACE_PEEK/POKE* allows us to copy only a > > *word* size... > > While true, this is easily fixable. Indeed, look at the systr_pmem_read() and systr_pmem_write() functions: http://www.xmailserver.org/sysctr.html - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote: > On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: > > GDB based approach seems not fit to our requirements. GDB(ptrace) based > > functions are basically need to be done when target process is stopping. > > In addition to that current PTRACE_PEEK/POKE* allows us to copy only a > > *word* size... > > While true, this is easily fixable. There is even an interface > precedent on OpenBSD (and possibly other platforms as well). > If we're going to be stealing ideas for debugging interfaces from other operating systems, could we steal from Solaris instead of anything ptrace-based? -- Nicholas Miell <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: > GDB based approach seems not fit to our requirements. GDB(ptrace) based > functions are basically need to be done when target process is stopping. > In addition to that current PTRACE_PEEK/POKE* allows us to copy only a > *word* size... While true, this is easily fixable. There is even an interface precedent on OpenBSD (and possibly other platforms as well). -- Daniel Jacobowitz CodeSourcery, LLC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Hello, Chris Wedgwood wrote: On Mon, Apr 18, 2005 at 12:19:54PM +0900, Takashi Ikebe wrote: This patch add function called "Live patching" which is defined on OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7 kernel. I;m curious as to what people decided this was a necessary requirement. The requirements are comes from Network Equipment Providers, Telecom Carriers, and Hardware Vendors, You can see the attendee from below link; http://groups.osdl.org/world_map/full_roster/ The live patching allows process to patch on-line (without restarting process) on i386 and x86_64 architectures, by overwriting jump assembly code on entry point of functions which you want to fix, to patched functions. Why can't you use ptrace for all this? GDB based approach seems not fit to our requirements. GDB(ptrace) based functions are basically need to be done when target process is stopping. In addition to that current PTRACE_PEEK/POKE* allows us to copy only a *word* size... From our experience, sometimes patches became to dozens to hundreds at one patching, and in this case GDB based approach cause target process's availability descent. -- Takashi Ikebe NTT Network Service Systems Laboratories 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Tel : +81 422 59 4246, Fax : +81 422 60 4012 e-mail : [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 12:19:54PM +0900, Takashi Ikebe wrote: > This patch add function called "Live patching" which is defined on > OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7 > kernel. I;m curious as to what people decided this was a necessary requirement. > The live patching allows process to patch on-line (without > restarting process) on i386 and x86_64 architectures, by overwriting > jump assembly code on entry point of functions which you want to > fix, to patched functions. Why can't you use ptrace for all this? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 12:19:54PM +0900, Takashi Ikebe wrote: This patch add function called Live patching which is defined on OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7 kernel. I;m curious as to what people decided this was a necessary requirement. The live patching allows process to patch on-line (without restarting process) on i386 and x86_64 architectures, by overwriting jump assembly code on entry point of functions which you want to fix, to patched functions. Why can't you use ptrace for all this? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Hello, Chris Wedgwood wrote: On Mon, Apr 18, 2005 at 12:19:54PM +0900, Takashi Ikebe wrote: This patch add function called Live patching which is defined on OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7 kernel. I;m curious as to what people decided this was a necessary requirement. The requirements are comes from Network Equipment Providers, Telecom Carriers, and Hardware Vendors, You can see the attendee from below link; http://groups.osdl.org/world_map/full_roster/ The live patching allows process to patch on-line (without restarting process) on i386 and x86_64 architectures, by overwriting jump assembly code on entry point of functions which you want to fix, to patched functions. Why can't you use ptrace for all this? GDB based approach seems not fit to our requirements. GDB(ptrace) based functions are basically need to be done when target process is stopping. In addition to that current PTRACE_PEEK/POKE* allows us to copy only a *word* size... From our experience, sometimes patches became to dozens to hundreds at one patching, and in this case GDB based approach cause target process's availability descent. -- Takashi Ikebe NTT Network Service Systems Laboratories 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Tel : +81 422 59 4246, Fax : +81 422 60 4012 e-mail : [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: GDB based approach seems not fit to our requirements. GDB(ptrace) based functions are basically need to be done when target process is stopping. In addition to that current PTRACE_PEEK/POKE* allows us to copy only a *word* size... While true, this is easily fixable. There is even an interface precedent on OpenBSD (and possibly other platforms as well). -- Daniel Jacobowitz CodeSourcery, LLC - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote: On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: GDB based approach seems not fit to our requirements. GDB(ptrace) based functions are basically need to be done when target process is stopping. In addition to that current PTRACE_PEEK/POKE* allows us to copy only a *word* size... While true, this is easily fixable. There is even an interface precedent on OpenBSD (and possibly other platforms as well). If we're going to be stealing ideas for debugging interfaces from other operating systems, could we steal from Solaris instead of anything ptrace-based? -- Nicholas Miell [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote: On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: GDB based approach seems not fit to our requirements. GDB(ptrace) based functions are basically need to be done when target process is stopping. In addition to that current PTRACE_PEEK/POKE* allows us to copy only a *word* size... While true, this is easily fixable. Indeed, look at the systr_pmem_read() and systr_pmem_write() functions: http://www.xmailserver.org/sysctr.html - Davide - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
On Mon, 18 Apr 2005 00:42:23 -0400
Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
GDB based approach seems not fit to our requirements. GDB(ptrace) based
functions are basically need to be done when target process is stopping.
In addition to that current PTRACE_PEEK/POKE* allows us to copy only a
*word* size...
While true, this is easily fixable. There is even an interface
precedent on OpenBSD (and possibly other platforms as well).
Some platforms even support the necessary PTRADE_{READ,WRITE}DATA
operations already, sparc is one such platform.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH x86_64] Live Patching Function on 2.6.11.7
Davide Libenzi wrote: (B (BOn Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote: (B (B (B (BOn Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote: (B (B (BGDB based approach seems not fit to our requirements. GDB(ptrace) based (Bfunctions are basically need to be done when target process is stopping. (BIn addition to that current PTRACE_PEEK/POKE* allows us to copy only a (B*word* size... (B (B (BWhile true, this is easily fixable. (B (B (B (BIndeed, look at the systr_pmem_read() and systr_pmem_write() functions: (B (Bhttp://www.xmailserver.org/sysctr.html (B (B (B (Bsystr_pmem_read() and systr_pmem_write() just calls ptrace PTRACE_PEEKTEXT/DATA (Brepeatedly (BIn this case we need to *stop* target process whenever patch modules is (Bloading (BIt cause target process availability worse. (B (B-- (BTakashi Ikebe (BNTT Network Service Systems Laboratories (B9-11, Midori-Cho 3-Chome Musashino-Shi, (BTokyo 180-8585 Japan (BTel : +81 422 59 4246, Fax : +81 422 60 4012 (Be-mail : [EMAIL PROTECTED] (B (B (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
