All of lore.kernel.org
 help / color / mirror / Atom feed
* [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing
@ 2009-10-10 23:16 Haiyang Zhang
  2009-10-12 15:30 ` Greg KH
                   ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Haiyang Zhang @ 2009-10-10 23:16 UTC (permalink / raw)
  To: Greg Kroah-Hartman, Hank Janssen; +Cc: linux-kernel, Tom Hanrahan, Hashir Abdi

From: Haiyang Zhang <haiyangz@microsoft.com>

Fix vmbus load hang caused by wrong data packing.

Cc: Hank Janssen <hjanssen@microsoft.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>

---
diff --git a/drivers/staging/hv/ChannelMgmt.h b/drivers/staging/hv/ChannelMgmt.h
index a839d8f..3f18584 100644
--- a/drivers/staging/hv/ChannelMgmt.h
+++ b/drivers/staging/hv/ChannelMgmt.h
@@ -30,6 +30,8 @@
 #include "VmbusChannelInterface.h"
 #include "VmbusPacketFormat.h"
 
+#pragma pack(push,1)
+
 /* Version 1 messages */
 enum vmbus_channel_message_type {
 	ChannelMessageInvalid			=  0,
@@ -54,24 +56,24 @@ enum vmbus_channel_message_type {
 	ChannelMessageViewRangeRemove		= 18,
 #endif
 	ChannelMessageCount
-} __attribute__((packed));
+};
 
 struct vmbus_channel_message_header {
 	enum vmbus_channel_message_type MessageType;
 	u32 Padding;
-} __attribute__((packed));
+};
 
 /* Query VMBus Version parameters */
 struct vmbus_channel_query_vmbus_version {
 	struct vmbus_channel_message_header Header;
 	u32 Version;
-} __attribute__((packed));
+};
 
 /* VMBus Version Supported parameters */
 struct vmbus_channel_version_supported {
 	struct vmbus_channel_message_header Header;
 	bool VersionSupported;
-} __attribute__((packed));
+};
 
 /* Offer Channel parameters */
 struct vmbus_channel_offer_channel {
@@ -80,13 +82,13 @@ struct vmbus_channel_offer_channel {
 	u32 ChildRelId;
 	u8 MonitorId;
 	bool MonitorAllocated;
-} __attribute__((packed));
+};
 
 /* Rescind Offer parameters */
 struct vmbus_channel_rescind_offer {
 	struct vmbus_channel_message_header Header;
 	u32 ChildRelId;
-} __attribute__((packed));
+};
 
 /*
  * Request Offer -- no parameters, SynIC message contains the partition ID
@@ -122,7 +124,7 @@ struct vmbus_channel_open_channel {
 
 	/* User-specific data to be passed along to the server endpoint. */
 	unsigned char UserData[MAX_USER_DEFINED_BYTES];
-} __attribute__((packed));
+};
 
 /* Open Channel Result parameters */
 struct vmbus_channel_open_result {
@@ -130,13 +132,13 @@ struct vmbus_channel_open_result {
 	u32 ChildRelId;
 	u32 OpenId;
 	u32 Status;
-} __attribute__((packed));
+};
 
 /* Close channel parameters; */
 struct vmbus_channel_close_channel {
 	struct vmbus_channel_message_header Header;
 	u32 ChildRelId;
-} __attribute__((packed));
+};
 
 /* Channel Message GPADL */
 #define GPADL_TYPE_RING_BUFFER		1
@@ -156,7 +158,7 @@ struct vmbus_channel_gpadl_header {
 	u16 RangeBufLen;
 	u16 RangeCount;
 	struct gpa_range Range[0];
-} __attribute__((packed));
+};
 
 /* This is the followup packet that contains more PFNs. */
 struct vmbus_channel_gpadl_body {
@@ -164,25 +166,25 @@ struct vmbus_channel_gpadl_body {
 	u32 MessageNumber;
 	u32 Gpadl;
 	u64 Pfn[0];
-} __attribute__((packed));
+};
 
 struct vmbus_channel_gpadl_created {
 	struct vmbus_channel_message_header Header;
 	u32 ChildRelId;
 	u32 Gpadl;
 	u32 CreationStatus;
-} __attribute__((packed));
+};
 
 struct vmbus_channel_gpadl_teardown {
 	struct vmbus_channel_message_header Header;
 	u32 ChildRelId;
 	u32 Gpadl;
-} __attribute__((packed));
+};
 
 struct vmbus_channel_gpadl_torndown {
 	struct vmbus_channel_message_header Header;
 	u32 Gpadl;
-} __attribute__((packed));
+};
 
 #ifdef VMBUS_FEATURE_PARENT_OR_PEER_MEMORY_MAPPED_INTO_A_CHILD
 struct vmbus_channel_view_range_add {
@@ -190,19 +192,19 @@ struct vmbus_channel_view_range_add {
 	PHYSICAL_ADDRESS ViewRangeBase;
 	u64 ViewRangeLength;
 	u32 ChildRelId;
-} __attribute__((packed));
+};
 
 struct vmbus_channel_view_range_remove {
 	struct vmbus_channel_message_header Header;
 	PHYSICAL_ADDRESS ViewRangeBase;
 	u32 ChildRelId;
-} __attribute__((packed));
+};
 #endif
 
 struct vmbus_channel_relid_released {
 	struct vmbus_channel_message_header Header;
 	u32 ChildRelId;
-} __attribute__((packed));
+};
 
 struct vmbus_channel_initiate_contact {
 	struct vmbus_channel_message_header Header;
@@ -211,12 +213,12 @@ struct vmbus_channel_initiate_contact {
 	u64 InterruptPage;
 	u64 MonitorPage1;
 	u64 MonitorPage2;
-} __attribute__((packed));
+};
 
 struct vmbus_channel_version_response {
 	struct vmbus_channel_message_header Header;
 	bool VersionSupported;
-} __attribute__((packed));
+};
 
 enum vmbus_channel_state {
 	CHANNEL_OFFER_STATE,
@@ -305,6 +307,7 @@ struct vmbus_channel_msginfo {
 	unsigned char Msg[0];
 };
 
+#pragma pack(pop)
 
 struct vmbus_channel *AllocVmbusChannel(void);
 

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing
  2009-10-10 23:16 [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing Haiyang Zhang
@ 2009-10-12 15:30 ` Greg KH
  2009-10-12 17:03   ` Haiyang Zhang
  2009-10-12 20:34 ` Greg KH
  2009-10-16 20:11 ` [PATCH 1/1] Staging: hv: Fix vmbus load hang caused by faulty " Hank Janssen
  2 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2009-10-12 15:30 UTC (permalink / raw)
  To: Haiyang Zhang; +Cc: Hank Janssen, linux-kernel, Tom Hanrahan, Hashir Abdi

On Sat, Oct 10, 2009 at 11:16:00PM +0000, Haiyang Zhang wrote:
> From: Haiyang Zhang <haiyangz@microsoft.com>
> 
> Fix vmbus load hang caused by wrong data packing.
> 
> Cc: Hank Janssen <hjanssen@microsoft.com>
> Cc: Greg Kroah-Hartman <gregkh@suse.de>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
> 
> ---
> diff --git a/drivers/staging/hv/ChannelMgmt.h b/drivers/staging/hv/ChannelMgmt.h
> index a839d8f..3f18584 100644
> --- a/drivers/staging/hv/ChannelMgmt.h
> +++ b/drivers/staging/hv/ChannelMgmt.h
> @@ -30,6 +30,8 @@
>  #include "VmbusChannelInterface.h"
>  #include "VmbusPacketFormat.h"
>  
> +#pragma pack(push,1)
> +
>  /* Version 1 messages */
>  enum vmbus_channel_message_type {
>  	ChannelMessageInvalid			=  0,
> @@ -54,24 +56,24 @@ enum vmbus_channel_message_type {
>  	ChannelMessageViewRangeRemove		= 18,
>  #endif
>  	ChannelMessageCount
> -} __attribute__((packed));

Why the change here?  Isn't this doing the same thing?

And I'm guessing that not all of these structures are needing to be
packed, right?  Are they all shared across the HV boundry?

And is this fixing the problem that Hank and users have reported with
the current code?  Does this need to get into the 2.6.32 release?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing
  2009-10-12 15:30 ` Greg KH
@ 2009-10-12 17:03   ` Haiyang Zhang
  2009-10-12 17:29     ` Greg KH
  0 siblings, 1 reply; 13+ messages in thread
From: Haiyang Zhang @ 2009-10-12 17:03 UTC (permalink / raw)
  To: Greg KH; +Cc: Hank Janssen, linux-kernel, Tom Hanrahan, Hashir Abdi

>  	ChannelMessageCount
> -} __attribute__((packed));

Why the change here?  Isn't this doing the same thing?

And I'm guessing that not all of these structures are needing to be
packed, right?  Are they all shared across the HV boundry?

And is this fixing the problem that Hank and users have reported with
the current code?  Does this need to get into the 2.6.32 release?


thanks,

greg k-h
================================================
Hi Greg,

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.

These data structures are moved by someone from the original file, ChannelMessages.h, which contains structures used for messaging to host.

Yes, it's fixing the problem that Hank and users have reported with the current code. And yes, 2.6.32 needs this fix.

Thanks,

- Haiyang


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing
  2009-10-12 17:03   ` Haiyang Zhang
@ 2009-10-12 17:29     ` Greg KH
  2009-10-12 20:10       ` Hank Janssen
  0 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2009-10-12 17:29 UTC (permalink / raw)
  To: Haiyang Zhang; +Cc: Hank Janssen, linux-kernel, Tom Hanrahan, Hashir Abdi

On Mon, Oct 12, 2009 at 05:03:42PM +0000, Haiyang Zhang wrote:
> >  	ChannelMessageCount
> > -} __attribute__((packed));
> 
> Why the change here?  Isn't this doing the same thing?
> 
> And I'm guessing that not all of these structures are needing to be
> packed, right?  Are they all shared across the HV boundry?
> 
> And is this fixing the problem that Hank and users have reported with
> the current code?  Does this need to get into the 2.6.32 release?
> 
> 
> thanks,
> 
> greg k-h
> ================================================
> Hi Greg,

Odd quoting style :(

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

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

And are all of these structures needing to be packed?

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?

> Yes, it's fixing the problem that Hank and users have reported with
> the current code. And yes, 2.6.32 needs this fix.

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?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing
  2009-10-12 17:29     ` Greg KH
@ 2009-10-12 20:10       ` Hank Janssen
  2009-10-12 20:22         ` Greg KH
  2009-10-13  5:08         ` Pekka Enberg
  0 siblings, 2 replies; 13+ messages in thread
From: Hank Janssen @ 2009-10-12 20:10 UTC (permalink / raw)
  To: Greg KH, Haiyang Zhang; +Cc: linux-kernel, Tom Hanrahan, Hashir Abdi


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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing
  2009-10-12 20:10       ` Hank Janssen
@ 2009-10-12 20:22         ` Greg KH
  2009-10-12 20:44           ` Haiyang Zhang
  2009-10-13  5:08         ` Pekka Enberg
  1 sibling, 1 reply; 13+ messages in thread
From: Greg KH @ 2009-10-12 20:22 UTC (permalink / raw)
  To: Hank Janssen; +Cc: Haiyang Zhang, linux-kernel, Tom Hanrahan, Hashir Abdi

On Mon, Oct 12, 2009 at 08:10:40PM +0000, Hank Janssen wrote:
> 
> >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.

Can you figure out why?  What is the output of gcc for both ways?

Can you show what is fixed by this change?

Also note that #pragma packed is not supported by older versions of gcc,
so I don't think that it would work at all on some compiler versions
that are still legal to use for the kernel.  But I'm not quite sure when
it was added, so I might be wrong.

> >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 can't take this patch until I see what the root problem is here,
sorry.

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

What is the rest of the oops message?  That's pretty hard to determine
anything from :)

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing
  2009-10-10 23:16 [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing Haiyang Zhang
  2009-10-12 15:30 ` Greg KH
@ 2009-10-12 20:34 ` Greg KH
  2009-10-16 20:11 ` [PATCH 1/1] Staging: hv: Fix vmbus load hang caused by faulty " Hank Janssen
  2 siblings, 0 replies; 13+ messages in thread
From: Greg KH @ 2009-10-12 20:34 UTC (permalink / raw)
  To: Haiyang Zhang
  Cc: Greg Kroah-Hartman, Hank Janssen, linux-kernel, Tom Hanrahan,
	Hashir Abdi

On Sat, Oct 10, 2009 at 11:16:00PM +0000, Haiyang Zhang wrote:
> From: Haiyang Zhang <haiyangz@microsoft.com>
> 
> Fix vmbus load hang caused by wrong data packing.

I also note that you are packing more structures here with this patch
than the code before the patch had.  Could that be the issue here?  The
additional structures are ones that should be packed instead?

If so, that might explain why things are working, just try to add the
packed attribute to the struct vmbus_channel and struct
vmbus_channel_debug_info and struct vmbus_channel_msginfo structures.

Although, if that solves the problem, then something else is seriously
wrong, as those structures should not being passed across the hypervisor
boundry...

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing
  2009-10-12 20:22         ` Greg KH
@ 2009-10-12 20:44           ` Haiyang Zhang
  2009-10-12 21:27             ` Greg KH
  0 siblings, 1 reply; 13+ messages in thread
From: Haiyang Zhang @ 2009-10-12 20:44 UTC (permalink / raw)
  To: Greg KH, Hank Janssen; +Cc: linux-kernel, Tom Hanrahan, Hashir Abdi

> Can you figure out why?  What is the output of gcc for both ways?
There are no build errors in either ways, I think it may be a bug in gcc handing __attribute__((packed)).

> Can you show what is fixed by this change?
Before the fix:
The command "insmod hv_vmbus.ko" hangs. 
Root cause: The message data sent from Linux guest to HyperV host were not correctly packed and not recognized by HyperV host. So, the host doesn't acknowledge that the vmbus channel is set up. Then, the guest keeps on waiting for the event and hangs the insmod command.

After the fix:
The command "insmod hv_vmbus.ko" completes successfully with vmbus module loaded.

> Also note that #pragma packed is not supported by older versions of gcc,
> so I don't think that it would work at all on some compiler versions
> that are still legal to use for the kernel.  But I'm not quite sure when
> it was added, so I might be wrong.
This pragma was used in older distro, such as SLES10 (kernel 2.6.16) without any problem.

>From your newer email:
> I also note that you are packing more structures here with this patch than the code before the patch had.  Could that be the 
> issue here?  The additional structures are ones that should be packed instead?
No, the extra packed structures are not required for this bug fix. Just to make sure any future struct related to message is packed, so I put the pack() around the entire file.

Thanks,

- Haiyang

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing
  2009-10-12 20:44           ` Haiyang Zhang
@ 2009-10-12 21:27             ` Greg KH
  2009-10-12 23:41               ` Haiyang Zhang
  0 siblings, 1 reply; 13+ messages in thread
From: Greg KH @ 2009-10-12 21:27 UTC (permalink / raw)
  To: Haiyang Zhang; +Cc: Hank Janssen, linux-kernel, Tom Hanrahan, Hashir Abdi

On Mon, Oct 12, 2009 at 08:44:06PM +0000, Haiyang Zhang wrote:
> > Can you figure out why?  What is the output of gcc for both ways?
> There are no build errors in either ways, I think it may be a bug in
> gcc handing __attribute__((packed)).

Of course there is not a build error.  I mean what is the difference in
the assembly produced?  Why is the __attribute__ version not the same

> > Can you show what is fixed by this change?
> Before the fix:
> The command "insmod hv_vmbus.ko" hangs. 
> Root cause: The message data sent from Linux guest to HyperV host were
> not correctly packed and not recognized by HyperV host. So, the host
> doesn't acknowledge that the vmbus channel is set up. Then, the guest
> keeps on waiting for the event and hangs the insmod command.
> 
> After the fix:
> The command "insmod hv_vmbus.ko" completes successfully with vmbus
> module loaded.

That's not showing me why the above fixed the problem.

> > Also note that #pragma packed is not supported by older versions of gcc,
> > so I don't think that it would work at all on some compiler versions
> > that are still legal to use for the kernel.  But I'm not quite sure when
> > it was added, so I might be wrong.
> This pragma was used in older distro, such as SLES10 (kernel 2.6.16)
> without any problem.

What compiler version was that?  Have you tried it on the lowest
required version of gcc?

> >From your newer email:
> > I also note that you are packing more structures here with this patch than the code before the patch had.  Could that be the 
> > issue here?  The additional structures are ones that should be packed instead?
> No, the extra packed structures are not required for this bug fix. Just to make sure any future struct related to message is packed, so I put the pack() around the entire file.

Please wrap your email lines properly...

Your patch changes structures that it is needed for.

We need to find the root cause of _why_ your patch fixes the problem here,
that is what I am trying to get you to do.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing
  2009-10-12 21:27             ` Greg KH
@ 2009-10-12 23:41               ` Haiyang Zhang
  0 siblings, 0 replies; 13+ messages in thread
From: Haiyang Zhang @ 2009-10-12 23:41 UTC (permalink / raw)
  To: Greg KH; +Cc: Hank Janssen, linux-kernel, Tom Hanrahan, Hashir Abdi

> We need to find the root cause of _why_ your patch fixes the problem
> here,
> that is what I am trying to get you to do.
OK, I will add some temporary code to get the size and the address of the fields in the data structures. Hope that will help us understand the mechanism of this fix.

Thanks,

- Haiyang



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [patch] Staging: hv: Fix vmbus load hang caused by wrong data  packing
  2009-10-12 20:10       ` Hank Janssen
  2009-10-12 20:22         ` Greg KH
@ 2009-10-13  5:08         ` Pekka Enberg
  2009-10-16 20:03           ` Hank Janssen
  1 sibling, 1 reply; 13+ messages in thread
From: Pekka Enberg @ 2009-10-13  5:08 UTC (permalink / raw)
  To: Hank Janssen
  Cc: Greg KH, Haiyang Zhang, linux-kernel, Tom Hanrahan, Hashir Abdi

Hi Hank,

On Mon, Oct 12, 2009 at 11:10 PM, Hank Janssen <hjanssen@microsoft.com> wrote:
>>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.

We don't merge fixes to the kernel unless we understand _why_ they fix
things. It's pretty likely that the problem here is that one or more
of the structs you are putting under "#pragma pack" just need to be
annotated with "attribute packed".

                        Pekka

^ permalink raw reply	[flat|nested] 13+ messages in thread

* RE: [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing
  2009-10-13  5:08         ` Pekka Enberg
@ 2009-10-16 20:03           ` Hank Janssen
  0 siblings, 0 replies; 13+ messages in thread
From: Hank Janssen @ 2009-10-16 20:03 UTC (permalink / raw)
  To: Pekka Enberg, Greg KH
  Cc: Tom Hanrahan, Hashir Abdi, Haiyang Zhang, linux-kernel



Greg / Pecca,

>We don't merge fixes to the kernel unless we understand _why_ they fix
>things. It's pretty likely that the problem here is that one or more
>of the structs you are putting under "#pragma pack" just need to be
>annotated with "attribute packed".

We have figured out what the problem is with it. 

It seems that the #pragma pack(push,1) doesn't change the size 
of "enum vmbus_channel_message_type", the size remains as 4 bytes, 
which is the default. I do not know if this is the result of
a gcc bug.

If you add __attribute__((packed)) here, the size becomes 1 byte, 
which couldn't be accepted by HyperV host, and causes vmbus load 
to hang.

So, the different behavior of #pragma pack(push,1) v.s.  
__attribute__((packed)) on the data struct, "enum vmbus_channel_message_type",
caused this bug. The fix is to remove __attribute__((packed)) of this data. 
We don't need to add #pragma pack(push,1) or #pragma pack(pop) here, since 
it has no effect on this structure. (BTW, seems it's a bug of gcc's 
handling of pragma pack().)

I will submit a patch later today that corrects the bug.

This patch in effect removes part of a previous patch somebody else 
Submitted that introduced this problem.

This bug masked another problem we encountered as soon as we fixed this
Problem. I am getting a NULL pointer problem on insertion of the hv_vmbus
Driver. I will write a more detailed description of that problem and send 
It to the list.

I checked the originally submitted code, and made that work with 2.6.32.
And that does run okay. 

Thanks,

Hank.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH 1/1] Staging: hv: Fix vmbus load hang caused by faulty data packing
  2009-10-10 23:16 [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing Haiyang Zhang
  2009-10-12 15:30 ` Greg KH
  2009-10-12 20:34 ` Greg KH
@ 2009-10-16 20:11 ` Hank Janssen
  2 siblings, 0 replies; 13+ messages in thread
From: Hank Janssen @ 2009-10-16 20:11 UTC (permalink / raw)
  To: Greg Kroah-Hartman, linux-kernel; +Cc: Tom Hanrahan, Hashir Abdi, Haiyang Zhang


 From: Hank Janssen <hjanssen@microsoft.com>

Fix vmbus load hang caused by wrong data packing.
This fix needs to be applied to 2.6.32 as well.

Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Hank Janssen<hjanssen@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>

---
diff --git a/drivers/staging/hv/ChannelMgmt.h b/drivers/staging/hv/ChannelMgmt.h
index a839d8f..2782328 100644
--- a/drivers/staging/hv/ChannelMgmt.h
+++ b/drivers/staging/hv/ChannelMgmt.h
@@ -54,7 +54,7 @@ enum vmbus_channel_message_type {
 	ChannelMessageViewRangeRemove		= 18,
 #endif
 	ChannelMessageCount
-} __attribute__((packed));
+};
 
 struct vmbus_channel_message_header {
 	enum vmbus_channel_message_type MessageType;


^ permalink raw reply related	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2009-10-16 21:15 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-10 23:16 [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing Haiyang Zhang
2009-10-12 15:30 ` Greg KH
2009-10-12 17:03   ` Haiyang Zhang
2009-10-12 17:29     ` Greg KH
2009-10-12 20:10       ` Hank Janssen
2009-10-12 20:22         ` Greg KH
2009-10-12 20:44           ` Haiyang Zhang
2009-10-12 21:27             ` Greg KH
2009-10-12 23:41               ` Haiyang Zhang
2009-10-13  5:08         ` Pekka Enberg
2009-10-16 20:03           ` Hank Janssen
2009-10-12 20:34 ` Greg KH
2009-10-16 20:11 ` [PATCH 1/1] Staging: hv: Fix vmbus load hang caused by faulty " Hank Janssen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.