Re: [RFC PATCH 0/2] kpatch: dynamic kernel patching

[Jiri Kosina]

On Mon, 5 May 2014, David Lang wrote:

> how would you know that all instances of the datastructure in memory 
> have= been touched? just because all tasks have run and are outside the 
> function in question doesn't tell you data structures have been 
> converted. You have n= o way of knowing when (or if) the next call to 
> the modified function will take place on any potential in-memory 
> structure.

The problem you are trying to avoid here is functions expecting to read 
"v2" format of the data from memory, while there are still tasks that are 
unpredictably writing "v1" format of the data to the memory.

There are several ways to attack this problem:

- stop the whole system, convert all the existing data structures to new 
  format (which might potentially be non-trivial, mostly because you 
  have to *know* where all the data structures have been allocated), apply 
  patch, resume operation [ksplice, probably kpatch in future]
- restrict the data format to be backwards compatible [to be done 
  manually during patch creation, currently what kGraft needs to do in 
  such case]
- have a proxy code which can read both "v1" and "v2" formats, and writes 
  back in the same format it has seen the data structure on input
- once all the *code* has been converted, it still has to understand "v1" 
  and "v2", but it can now start writing out "v2" format only [possible 
  with kGraft, not implemented in automated fashion]

Ideas are of course more than welcome.

Thanks,

-- 
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/