[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110531171927.38d4b0f7.yoshikawa.takuya@oss.ntt.co.jp>
Date: Tue, 31 May 2011 17:19:27 +0900
From: Takuya Yoshikawa <yoshikawa.takuya@....ntt.co.jp>
To: Ingo Molnar <mingo@...e.hu>
Cc: Borislav Petkov <bp@...en8.de>, Avi Kivity <avi@...hat.com>,
Marcelo Tosatti <mtosatti@...hat.com>, kvm@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>, takuya.yoshikawa@...il.com
Subject: Re: [PATCH] kvm: Fix build warnings
On Tue, 31 May 2011 09:38:24 +0200
Ingo Molnar <mingo@...e.hu> wrote:
>
> * Borislav Petkov <bp@...en8.de> wrote:
>
> > +++ b/arch/x86/kvm/paging_tmpl.h
> > @@ -121,7 +121,7 @@ static int FNAME(walk_addr_generic)(struct guest_walker *walker,
> > gva_t addr, u32 access)
> > {
> > pt_element_t pte;
> > - pt_element_t __user *ptep_user;
> > + pt_element_t __user *uninitialized_var(ptep_user);
>
> Note that doing this is actually actively dangerous for two reasons.
>
> Firstly, it also shuts down the warning when it turns into a *real*
> warning. For example this function will not produce a warning:
>
> int test(int a)
> {
> int uninitialized_var(b);
>
> return b;
> }
>
> Secondly, if the *compiler* cannot understand the flow then the code
> is obviously rather complex for humans to review. So if there's an
> initialization bug in the future, the risk of a human not seeing it
> and the risk of uninitialized_var() hiding it is larger.
>
> So the recommended thing is to simplify the flow there to make it
> easier for the compiler to see through it.
Thank you for your advice.
Borislav, would you like to do the fix suggested here?
As the person who introduced this warning, if these are too many
for you, I will try some of these.
Takuya
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists