From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Nathan Chancellor <natechancellor@gmail.com>,
Cliff Whickman <cpw@sgi.com>, Robin Holt <robinmholt@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
clang-built-linux <clang-built-linux@googlegroups.com>,
Stephen Hines <srhines@google.com>,
Tony Luck <tony.luck@intel.com>,
rja@sgi.com, Fenghua Yu <fenghua.yu@intel.com>
Subject: Re: [PATCH] misc: sgi-xp: Properly initialize buf in xpc_get_rsvd_page_pa
Date: Fri, 24 May 2019 18:00:15 +0200 [thread overview]
Message-ID: <20190524160015.GA7590@kroah.com> (raw)
In-Reply-To: <CAK8P3a3RE3Jwft6WTNavV7St3P+mVFwRyCQFVaO3==LB7j29rw@mail.gmail.com>
On Fri, May 24, 2019 at 09:40:47AM +0200, Arnd Bergmann wrote:
> On Thu, May 23, 2019 at 8:05 PM 'Nick Desaulniers' via Clang Built
> Linux <clang-built-linux@googlegroups.com> wrote:
> >
> > On Thu, May 23, 2019 at 9:20 AM Nathan Chancellor
> > <natechancellor@gmail.com> wrote:
> > >
> > > Clang warns:
> > >
> > > drivers/misc/sgi-xp/xpc_partition.c:73:14: warning: variable 'buf' is
> > > uninitialized when used within its own initialization [-Wuninitialized]
> > > void *buf = buf;
> > > ~~~ ^~~
> > > 1 warning generated.
> > >
> > > Initialize it to NULL, which is more deterministic.
> > >
> > > Fixes: 279290294662 ("[IA64-SGI] cleanup the way XPC locates the reserved page")
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/466
> > > Suggested-by: Stephen Hines <srhines@google.com>
> > > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> >
> > From https://github.com/ClangBuiltLinux/linux/issues/466#issuecomment-488781917
> > I tried to follow the rabbit hole, but eventually these void* get
> > converted to u64's and passed along to function that I have no idea
> > whether they handle the value `(u64)(void*)0` or not. Either way,
> > they definitely don't handle uninitialized values/UB.
> >
> > I was going to cc Robin who's already cc'ed, but looks like this code
> > was last touched 7-10 years ago. + Tony and Fenghua for ia64 since
> > sn_partition_reserved_page_pa is defined in
> > arch/ia64/include/asm/sn/sn_sal.h.
> >
> > In absence of consensus, I'll prefer NULL to uninitialized.
> > Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
> > Thanks Nathan for following up on this.
>
> I also had to take a look, and I think I understand what's going on,
> and interestingly, the code is correct, both before and after your patch.
> It's described in this comment:
>
> /*
> * Returns the physical address of the partition's reserved page through
> * an iterative number of calls.
> *
> * On first call, 'cookie' and 'len' should be set to 0, and 'addr'
> * set to the nasid of the partition whose reserved page's address is
> * being sought.
> * On subsequent calls, pass the values, that were passed back on the
> * previous call.
> *
> * While the return status equals SALRET_MORE_PASSES, keep calling
> * this function after first copying 'len' bytes starting at 'addr'
> * into 'buf'. Once the return status equals SALRET_OK, 'addr' will
> * be the physical address of the partition's reserved page. If the
> * return status equals neither of these, an error as occurred.
> */
> static inline s64
> sn_partition_reserved_page_pa(u64 buf, u64 *cookie, u64 *addr, u64 *len)
>
> so *len is set to zero on the first call and tells the bios how many bytes
> are accessible at 'buf', and it does get updated by the BIOS to tell
> us how many bytes it needs, and then we allocate that and try again.
>
> With that explanation added,
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Nathan, can you add this to the changelog comment and add the reviewed
by lines and resend it so I can queue it up?
thanks,
greg k-h
next prev parent reply other threads:[~2019-05-24 16:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-03 3:33 -Wuninitialized warning in drivers/misc/sgi-xp/xpc_partition.c Nathan Chancellor
2019-05-23 1:56 ` Nathan Chancellor
2019-05-23 5:52 ` Greg Kroah-Hartman
2019-05-23 6:58 ` Stephen Hines
2019-05-23 16:15 ` [PATCH] misc: sgi-xp: Properly initialize buf in xpc_get_rsvd_page_pa Nathan Chancellor
2019-05-23 16:46 ` Stephen Hines
2019-05-23 18:05 ` Nick Desaulniers
2019-05-24 7:40 ` Arnd Bergmann
2019-05-24 16:00 ` Greg Kroah-Hartman [this message]
2019-05-24 16:15 ` Nathan Chancellor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190524160015.GA7590@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=clang-built-linux@googlegroups.com \
--cc=cpw@sgi.com \
--cc=fenghua.yu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=rja@sgi.com \
--cc=robinmholt@gmail.com \
--cc=srhines@google.com \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox