From: Greg KH <gregkh@suse.de>
To: Hank Janssen <hjanssen@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Tom Hanrahan <hanrahat@microsoft.com>,
Hashir Abdi <habdi@microsoft.com>
Subject: Re: [patch] Staging: hv: Fix vmbus load hang caused by wrong data packing
Date: Mon, 12 Oct 2009 13:22:14 -0700 [thread overview]
Message-ID: <20091012202214.GA9631@suse.de> (raw)
In-Reply-To: <8AFC7968D54FB448A30D8F38F259C5620E7B1C22@TK5EX14MBXC114.redmond.corp.microsoft.com>
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
next prev parent reply other threads:[~2009-10-12 20:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091012202214.GA9631@suse.de \
--to=gregkh@suse.de \
--cc=habdi@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hanrahat@microsoft.com \
--cc=hjanssen@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.