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

Re: [Xen-devel] [PATCH V2] x86, amd_ucode: Support multiple container files appended together



>>> On 25.06.14 at 00:42, <aravind.gopalakrishnan@xxxxxxx> wrote:
> On 6/24/2014 2:23 AM, Jan Beulich wrote:
>>> @@ -236,7 +260,15 @@ static int get_ucode_from_buffer_amd(
>>>       mpbuf = (const struct mpbhdr *)&bufp[off];
>>>       if ( mpbuf->type != UCODE_UCODE_TYPE )
>>>       {
>>> -        printk(KERN_ERR "microcode: Wrong microcode payload type field\n");
>>> +        /*
>>> +         * We will hit this condition only if an update has succeeded
>>> +         * but there is still another container file being parsed.
>>> +         * In that case, there is no need of this ERR message to be
>>> +         * printed.
>>> +         */
>>> +        if ( mpbuf->type != UCODE_MAGIC )
>>> +            printk(KERN_ERR "microcode: Wrong microcode payload type 
> field\n");
>> The more often I look at it, the less convinced am I that this is okay:
>> UCODE_MAGIC isn't a valid value for mpbuf->type, it just so happens
>> that the field matches up with the next block signature. Either don't
>> abuse the field, or make clear via comment why it is done this way.
> 
> Would this be better? -
> if ( *(const uint32_t *)buf != UCODE_MAGIC )
> 
> I can still let the above comment be there (or modify it to make it more 
> clear?)

As I said in the previous reply (see above), I'm not really decided
which of the two options is the better one. Perhaps the one using
a cast on buf as you just now suggested is slightly preferable, as
it matches the other similar check(s).

>>> +    return 0;
>>> +}
>>> +
>>> +static int container_fast_forward(const void *data, size_t size_left, 
> size_t *offset)
>>> +{
>>> +    size_t size;
>>> +    uint32_t *header;
>>> +
>>> +    while ( size_left )
>>> +    {
>>> +        header = (uint32_t *) (data + *offset);
>> Pointless (and wrong, as it discards the const qualifier) cast.
> 
> Ok. I have removed this cast (and as a consequence *header) entirely.
> Also need -
> if ( size_left < 0 ) check. Reason-
> With offset value being advanced aggressively in 'install_equiv_cpu_table',
> It could be that we go over the bufsize. This situation will be caught here.

Except that size_left is of unsigned type, i.e. will never be < 0.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.