The compiler warning seems to be a false positive, as
rt_cookie != cookie is only checked if rt6_get_cookie_safe
returns true in which case rt_cookie is initialized.
Please disregard this patch.
The compiler warning seems to be a false positive, as
rt_cookie != cookie is only checked if rt6_get_cookie_safe
returns true in which case rt_cookie is initialized.
Please disregard this patch.
...or not? I was thinking of sending a similar patch with
uninitialized_var(rt_cookie), but it seems we have similar cases
where we just initialize to zero instead.
I wonder which approach is considered the most acceptable nowadays. I
would be in favour of uninitialized_var() as it doesn't change the
binary output, but https://lwn.net/Articles/529954/ also contains some
valid criticism. Ideas?
The compiler warning seems to be a false positive, as
rt_cookie != cookie is only checked if rt6_get_cookie_safe
returns true in which case rt_cookie is initialized.
Please disregard this patch.
...or not? I was thinking of sending a similar patch with
uninitialized_var(rt_cookie), but it seems we have similar cases
where we just initialize to zero instead.
I wonder which approach is considered the most acceptable nowadays. I
would be in favour of uninitialized_var() as it doesn't change the
binary output, but https://lwn.net/Articles/529954/ also contains some
valid criticism. Ideas?
Generally speaking I guess initializing to zero is Ok to do.
As far as which approach is better, I don't have any strong opinion.
So I will probably just apply Steffen's patch.
rt_cookie might be used uninitialized, fix this by
initializing it.
Fixes: c5cff8561d2d ("ipv6: add rcu grace period before freeing fib6_node")
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>