Re: [Xen-devel] [PATCH 1/1] hvm.c: Prevent gcc uninitialised var warning

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.03.15 at 16:02, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 23/03/15 15:01, Don Slutz wrote:
>> gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 reports:
>> ----------------------------------------------------------------------
>> hvm.c: In function `hvm_create_ioreq_server':
>> hvm.c:487:18: error: `bufioreq_pfn' may be used uninitialised in this 
> function
>> [-Werror=uninitialized]
>> hvm.c:718:30: note: `bufioreq_pfn' was declared here
>> ----------------------------------------------------------------------
>>
>> My code analysis says that gcc is wrong, but initilize the variable
>> to prevent the gcc warning.
>>
>> Reported-by: Ian Murray <murrayie@xxxxxxxxxxx>
>> Signed-off-by: Don Slutz <dslutz@xxxxxxxxxxx>
> 
> GCC is correct and there is path through this function where
> bufioreq_pfn is used while uninitialised (non-debug build, is_default =
> 1, handle_bufioreq = 0).

I'm not seeing it: When is_default is set, bufioreq_pfn gets
initialized in the first if()'s body.

> As an aside, the compiler is in a very easy position to spot this.  The
> error means that GCC has positively identified a basic block which does
> use bufioreq_pfn before it has been initialised.
> 
> I observe that the patch has been committed, but it merely hides the
> problem and doesn't fix it; hvm_free_ioreq_gmfn(d, bufioreq_pfn) will
> still clobber arbitrary memory.

I committed the patch based on me not being able to find a path
where the variable would actually be used uninitialized (and it is
known that various gcc versions have varying levels of problems
with correctly identifying such issues). If indeed there is a path
that I'm not seeing, then I'd indeed favor reverting and putting
in a proper, backportable fix.

Jan


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