[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] network: get vlan info for Open vSwitch interfaces from proper source



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]