[help] Confusion on livepatch's per-task consistency model

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello guys,


I'm new to livepatch world and now I'm a little confused with livepatch's

per-task consistency model which is introduced by [1]. I've also readed the

discussion on mailing list [2], which introduces shadow variable to handle

data layout and semantic changes. But there's still some confusion with this

per-task consistency model.


According to the model, there will be scenario where old function and new

function can co-exist, though for a single thread, it sees either all new

functions or all old functions.


I can't understand why Vojtech said that 'old func processing new data' was

impossible. Assuming a scenario where a process calls func-A to submit a

work request (inserted into a global list), and then a kthread is responsible

for calling func-B to process all work requests in the list. What if this process

has finished the transition (sees new func-A) while kthread still sees the old func-B?

In this case, old func-B has to process new data. If there's some lock semantic

changes in func-A and func-B, then old func-B has no way identifying the shadow

variable labeled by new func-A.


Please tell me if I missed something, and any suggestions will be appreciated. ;)


Thanks.


[1] livepatch: change to a per-task consistency model

(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.6-rc3&id=d83a7cb375eec21f04c83542395d08b2f6641da2)


[2] https://lkml.kernel.org/r/20141107140458.GA21774@xxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux Kernel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux