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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox