If you want that exact functionality, do this:
At program start, spawn a new thread:
1) Open a UNIX socket (/var/run/someapp_live_patch.sock)
2) poll() that socket for a connection.
3) When you get a connection, do your own security checks
4) If it's ok, then map the specified file into memory
5) Read a table of crap to patch from the file
6) Do the patching, being careful to avoid the millions of
races involved for each CPU, *especially* regarding the
separate icache and dcache on CPUs like PPC and such.
7) Go back to step 2
If you want equivalent functionality but much safer and not CPU
dependent and full of hand-coded assembly:
1) open(), mmap(), and mlock() the file (/var/lib/someapp/data)
2) Spawn normal operation threads
3) Spawn a new hot-patch thread:
1) Open a UNIX socket (/var/run/someapp_live_patch.sock)
2) poll() that socket for a connection.
3) When you get one, coordinate with the new process as it
attaches itself to /var/lib/someapp/data
4) Handle shared locking of parts of /var/lib/someapp/data
5) Send it your listen() file-descriptors over the socket.
6) Wait for the other process to signal it's ready.
7) Stop accepting new connections on the socket.
8) Send file-descriptors for current connections
9) Cleanup and quit
When live-patching:
1) connect to the socket /var/run/someapp_live_patch.sock
2) open(), mmap() and mlock() /var/lib/someapp/data
3) Coordinate with the other process via the socket
4) Receive the listen() file-descriptors over the socket.
5) Set up the shared data locking
6) Spawn normal operation threads
7) Signal readiness
8) Receive file-descriptors for current connections
9) Spawn threads for them too.
10) Spawn a new hot-patch thread as above
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
