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

Re: [libvirt] [PATCHv2 18/27] xen: reject unknown flags



2011/7/14 Eric Blake <eblake redhat com>:
> On 07/13/2011 06:59 AM, Matthias Bolte wrote:
>> 2011/7/8 Eric Blake <eblake redhat com>:
>>> @@ -1629,8 +1633,10 @@ xenDaemonDomainSave(virDomainPtr domain, const char *filename)
>>>  */
>>>  static int
>>>  xenDaemonDomainCoreDump(virDomainPtr domain, const char *filename,
>>> -                        unsigned int flags ATTRIBUTE_UNUSED)
>>> +                        unsigned int flags)
>>>  {
>>> +    virCheckFlags(0, -1);
>>> +
>>>     if ((domain == NULL) || (domain->conn == NULL) || (domain->name == NULL) ||
>>>         (filename == NULL)) {
>>>         virXendError(VIR_ERR_INVALID_ARG, __FUNCTION__);
>>
>> Third time fooled by ATTRIBUTE_UNUSED. xenDaemonDomainCoreDump
>> understands VIR_DUMP_LIVE and VIR_DUMP_CRASH.
>
> Yep, which is why for v3, I've gone through and looked at every use of
> virCheckFlags(0, ...) to make sure that the next instance of 'flags' is
> not until the next function.  I'll respin this patch for my v3 series.
> In the meantime, I've pushed 16 and 17.
>
>>
>>> @@ -3151,10 +3160,12 @@ xenDaemonDomainMigratePrepare (virConnectPtr dconn,
>>>                                int *cookielen ATTRIBUTE_UNUSED,
>>>                                const char *uri_in,
>>>                                char **uri_out,
>>> -                               unsigned long flags ATTRIBUTE_UNUSED,
>>> +                               unsigned long flags,
>>>                                const char *dname ATTRIBUTE_UNUSED,
>>>                                unsigned long resource ATTRIBUTE_UNUSED)
>>>  {
>>> +    virCheckFlags(0, -1);
>>> +
>>>     /* If uri_in is NULL, get the current hostname as a best guess
>>>      * of how the source host should connect to us.  Note that caller
>>>      * deallocates this string.
>>
>> This breaks virDomainMigrate, because *DomainMigratePrepare is called
>> with the flags passed to virDomainMigrate, even if
>> xenDaemonDomainMigratePrepare doesn't use this flags it has to accept
>> all flags that the Xen driver understand in general form migration.
>
> Good point, and somewhat relevant to your comments about ESX migration
> flags in 8/27 as well.
>
> I will also double-check that qemu and remote (the only other drivers
> with a MigratePrepare callback) are not affected.

You should probably double-check all *DomainMigrate* driver functions
as they all get the flags from the virDomainMigrate* functions.

-- 
Matthias Bolte
http://photron.blogspot.com


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