> Harsh replies automatically allocate me as Linus Torvalds, ok.No, you cannot be used as a replacement for him, but still looks similar. At least your first comment in this thread has such funny property.
> the vcpu_list is not a list_head, it's simply an array of `struct vcpu`, declared as follows:
> struct vcpu vcpu_list[MAX_VCPUS];
Wow... I'm impressed. Unexpected use for container_of. But yes, you are right about I was a fool, I could catch it looking only into this function, but I didn't.
But nevertheless... You are using container_of in a way its not indended to use. Even without looking on the rest of your code I can say this to you with great confidence. If you do not believe me, you might ask any kernel developer and try to convince him that you have important reasons to such a design that leads to use container_of in this case.
container_of is a tool to design some data structures like list, where different struct types have common parts. For example struct list_head field.
container_of is not a magic way to use pointers into structures as substitute for pointers to structures. Because container_of is using explicit casts which is bad. Such casts used everywere in kernel not because it is a good practice, but because C gives no other ways to do some things. Pointer arith even worse, but in some cases its the only choice also. Your case is not valid case for using pointer arith, expicit casts and container_of.
Just add to struct vcpu field `struct ksm *parent', and your vcpu_to_ksm will not need any casts anymore. Its completely safe: such a pointer will not become dangling, because struct vcpu shares lifetime with containing struct ksm. Just do not forget to initialize this pointer.
