On Tue, Sep 02, 2014 at 01:52:15PM +0300, Boaz Harrosh wrote: > On 09/01/2014 04:50 PM, Trond Myklebust wrote: > > On Mon, Sep 1, 2014 at 7:32 AM, Shakil A Khan <shakilk1729@xxxxxxxxx> wrote: > >> Signed-off-by : Shakil A Khan <shakilk1729@xxxxxxxxx> > >> --- > >> net/sunrpc/auth_gss/auth_gss.c | 2 +- > >> 1 files changed, 1 insertions(+), 1 deletions(-) > >> > >> diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c > >> index afb292c..bea0951 100644 > >> --- a/net/sunrpc/auth_gss/auth_gss.c > >> +++ b/net/sunrpc/auth_gss/auth_gss.c > >> @@ -1387,7 +1387,7 @@ gss_key_timeout(struct rpc_cred *rc) > >> struct gss_cred *gss_cred = container_of(rc, struct gss_cred, gc_base); > >> struct gss_cl_ctx *ctx; > >> unsigned long now = jiffies; > >> - unsigned long expire; > >> + unsigned long expire = 0; > >> > >> rcu_read_lock(); > >> ctx = rcu_dereference(gss_cred->gc_ctx); > >> -- > >> 1.7.1 > > > > That would be a compiler bug, not a kernel bug. The kernel code is > > perfectly correct as it stands, and will never access the > > uninitialised variable. > > > > Than you will need the infamous uninitialised_var() You'd rather avoid sprinkling that all over, though. If nothing else it increases the chances you'll suppress a legimate warning some day. And unless I'm missing something this one really does look like an unambiguous compiler bug. --b. > > diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c > index afb292c..bea0951 100644 > --- a/net/sunrpc/auth_gss/auth_gss.c > +++ b/net/sunrpc/auth_gss/auth_gss.c > @@ -1387,7 +1387,7 @@ gss_key_timeout(struct rpc_cred *rc) > struct gss_cred *gss_cred = container_of(rc, struct gss_cred, gc_base); > struct gss_cl_ctx *ctx; > unsigned long now = jiffies; > - unsigned long expire; > + unsigned long uninitialised_var(expire); > > rcu_read_lock(); > ctx = rcu_dereference(gss_cred->gc_ctx); > > Cheers > Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
