lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8AFC7968D54FB448A30D8F38F259C5620E7B1C22@TK5EX14MBXC114.redmond.corp.microsoft.com>
Date:	Mon, 12 Oct 2009 20:10:40 +0000
From:	Hank Janssen <hjanssen@...rosoft.com>
To:	Greg KH <gregkh@...e.de>, Haiyang Zhang <haiyangz@...rosoft.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Tom Hanrahan <hanrahat@...rosoft.com>,
	Hashir Abdi <habdi@...rosoft.com>
Subject: RE: [patch] Staging: hv: Fix vmbus load hang caused by wrong data
 packing


>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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ