Local variable t should be initialized by arch_get_random_int.
Actually on failure of arch_get_random_int, value is not used.
So, just keep the build clean with less warnings.
warning:
drivers/char/random.c: In function ‘write_pool.constprop’:
drivers/char/random.c:1912:11: warning: ‘t’ may be used uninitialized in this function [-Wmaybe-uninitialized]
Signed-off-by: Constantine Shulyupin <[email protected]>
---
drivers/char/random.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 283fe390e878..8e51846d0673 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1896,7 +1896,7 @@ static int
write_pool(struct entropy_store *r, const char __user *buffer, size_t count)
{
size_t bytes;
- __u32 t, buf[16];
+ __u32 t = 0, buf[16];
const char __user *p = buffer;
while (count > 0) {
--
2.17.1
On Wed, Jul 18, 2018 at 10:11:52AM +0300, Constantine Shulyupin wrote:
> Local variable t should be initialized by arch_get_random_int.
> Actually on failure of arch_get_random_int, value is not used.
> So, just keep the build clean with less warnings.
>
> warning:
> drivers/char/random.c: In function ‘write_pool.constprop’:
> drivers/char/random.c:1912:11: warning: ‘t’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> Signed-off-by: Constantine Shulyupin <[email protected]>
There was a more significant problem which Arnd pointed out, which is
I had reversed the sense of the test in arch_get_random_int(). I've
since fixed this, and the current random tree is clean of warnings.
- Ted
On Wed, Jul 18, 2018 at 9:11 AM, Constantine Shulyupin
<[email protected]> wrote:
> Local variable t should be initialized by arch_get_random_int.
> Actually on failure of arch_get_random_int, value is not used.
> So, just keep the build clean with less warnings.
>
> warning:
> drivers/char/random.c: In function ‘write_pool.constprop’:
> drivers/char/random.c:1912:11: warning: ‘t’ may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> Signed-off-by: Constantine Shulyupin <[email protected]>
You need to be much more careful with fixes like this one. As Ted explained,
the warning was about a real bug here, and adding an incorrect initialization
just made it harder to find that bug.
There are many cases in which the compiler does have a false-positive or
a false-negative -Wmaybe-uninitialized warning, but in general you should
assume that the compiler is correct. If you add a fake initialization because
you think the compiler is wrong, it's best to link to the gcc bugzilla
describing
that gcc bug, or open a new bug report if it still happens in the
latest compiler
version and hasn't been reported before.
Arnd