[lkml]   [2008]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/7] Ksplice: Rebootless kernel updates
On Tue, Dec 16, 2008 at 07:07:40PM -0800, Andrew Morton wrote:

> I'd have _thought_ that distros and their high-end customers would be
> interested in it, but I haven't noticed anything from them. Not that
> this means much - our processes for gathering this sort of information
> are rudimentary at best. Has your team been in contact with distros?
> Are Suse shipping it, or planning to?
> (cc's a few more distro people)

I'm not exactly enamoured by this tbh.
It's a neat hack, but the idea of it being used by even a small percentage
of our users gives me the creeps.

It comes down to 'what happens when something goes wrong'.
When the end-user is running a ksplice-patched kernel with an unknown
number of patches, reproducability can get really complicated.
The Fedora position on it has been 'you keep both pieces if something breaks'
in the same way we don't support someone who hand-built their own kernel.
I understand ksplice now taints the kernel when it applies a patch, which
is a step in the right direction, but we don't always get to see
tainted flags in bug reports (the non-oops variants for eg).

If distros can't get security updates out in a reasonable time, fix
the process instead of adding mechanism that does an end-run around it.

Which just leaves the "we can't afford downtime" argument, which leads
me to question how well reviewed runtime patches are.

Having seen some of the non-ksplice runtime patches that appear in the
wake of a new security hole, I can't say I have a lot of faith.
Perhaps if there was a sanctioned ksplice functionality,
then such patches would get better review before being deployed. Dunno.



 \ /
  Last update: 2008-12-17 04:57    [W:0.094 / U:2.708 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site