[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |