On 08/29/2012 10:49 AM, Kyle Mestery (kmestery) wrote:
On Aug 29, 2012, at 6:19 AM, Alex Jia wrote:
> On 08/29/2012 06:43 PM, Laine Stump wrote:
>> This bug was revealed by the crash described in
>>
>>
https://bugzilla.redhat.com/show_bug.cgi?id=852383
>>
>> The vlan info pointer sent to virNetDevOpenvswitchAddPort should never
>> be non-NULL unless there is at least one tag. The factthat such a vlan
>> info pointer was receveid pointed out that a caller was passing the
>> wrong pointer. Instead of sending&net->vlan, the result of
>> virDomainNetGetActualVlan(net) should be sent - that function will
>> look for vlan info in net->data.network.actual->vlan, and in cany case
>> return NULL instead of a pointer if the vlan info it finds has no
>> tags.
>>
>> Aside from causing the crash, sending a hardcoded&net->vlan has the
>> effect of ignoring vlan info from a<network> or<portgroup> config.
>> ---
>>
>> Since I'm not online in a regular fashion for the next few days (too
>> bad I wasn't online in the 12 hours or so *before* the 0.10.0 release
>> instead of after :-/), I would appreciate if whoever ACKs this could
>> push it. Thanks!
> Laine, unfortunately, the libvirtd still is crash without my patch after applying
your patch :(
>
Hi Alex and Laine:
What I notice is, that with Laine's patch, for virtualport of type openvswitch, if I
do NOT define
a VLAN, it crashes. If I do, then I can start my virtual machines. Without Laine's
patch, it's the
same, which leads me to believe Laine's patch only fixes a symptom of this issue.
No, there are actually two separate crashes and two separate issues -
look at the two tracebacks in
https://bugzilla.redhat.com/show_bug.cgi?id=852383 - they are different
at the very top. One crash is due to improper buf usage, and the other
due to a bad vlan pointer. The first doesn't show up until the second is
fixed (or masked by checking for vlan->nTags > 0).
And again, while the checking for vlan->nTags > 0 isn't a bad thing,
doing that just masks the symptom of the "original" real issue, which
was us sending &net->vlan rather than calling virDomainNetGetActualVlan().