RE: [patch] Staging: hv: Fix vmbus load hang caused by wrong datapacking

[Hank Janssen]

>Odd quoting style :(

We like to keep things lively :)

>> Based on our testing, the #pragma pack(push,1) can pack the data
>> correctly for the HyperV to use, but __attribute__((packed)) couldn't
>> do this right.
>
>Why?  What does gcc generate differently?  This should be identical.

It should, but in practice in this case it does not seem to behave the same
Way.

>> These data structures are moved by someone from the original file,
>> ChannelMessages.h, which contains structures used for messaging to
>> host.
>
>I moved them as they did not need to be in that file, right?

Moving them was not a problem.

>Ideally, we don't deal with packed structures at all, but with offsets
>in memory and pick out the proper fields and put them into new
>structures if you want to use them that way.  How hard would that be to
>do here instead?

It is something that I want to look at in the future. Our primary focus
Is to get the bug fixed. We cannot do the offset way in the time we
Have before 2.6.32 closes and still be comfortable we have gone through
The extensive testing cycle we do on our side.

>I still want to figure out what the real difference here is.  Especially
>as I removed a lot of the #pragma pack(push,1) lines from the hv code.
>If it really is different, all of those patches should be reverted,
>right?

Not sure yet if they need to be reverted, after we fixed this bug last week
We are getting another one, it was masked by the one we just fixed. 
We are checking into that right now;

	BUG: unable to handle kernel NULL pointer dereference at (null)


Thanks,

Hank.


--
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/