Sure
I do not think we have to worry here.
These is best effort, and unfortunately atomic_t are int.
Adding uatomic_t helpers in the kernel with unsigned int would be a huge
effort, given this would touch all arches.
From: David Laight <hidden> Date: 2016-09-20 13:38:54
From: Eric Dumazet
Sent: 20 September 2016 14:29
...
quoted
[ 47.565420] -2117905507 + -695755206 cannot be represented in type 'int'
...
I do not think we have to worry here.
These is best effort, and unfortunately atomic_t are int.
Not until we compile on a cpu where int arithmetic doesn't wrap.
While I expect that various other parts of the kernel (and userspace)
wouldn't like such cpu, they do exist.
David
From: Eric Dumazet <hidden> Date: 2016-09-20 13:45:20
On Tue, 2016-09-20 at 13:36 +0000, David Laight wrote:
From: Eric Dumazet
quoted
Sent: 20 September 2016 14:29
...
quoted
quoted
[ 47.565420] -2117905507 + -695755206 cannot be represented in type 'int'
...
quoted
I do not think we have to worry here.
These is best effort, and unfortunately atomic_t are int.
Not until we compile on a cpu where int arithmetic doesn't wrap.
Then I guess the guy adding this kind of arches in the kernel will have
to add all the core kernel infra.
If you have an idea, I will happily review a patch.
From: Eric Dumazet <hidden> Date: 2016-09-20 14:11:55
On Tue, 2016-09-20 at 15:39 +0200, Jiri Pirko wrote:
I see. So how to silent the warning?
We can replace the atomic_add_return() and use a loop around
atomic_read() and atomic_cmpxhg()
This would change the nice property of x86 xadd into a loop.
Or we also could fallback to random generation if the atomic_cmpxchg()
fails.
I'll provide a patch, thanks.
From: Eric Dumazet <hidden> Date: 2016-09-20 14:18:15
On Tue, 2016-09-20 at 07:11 -0700, Eric Dumazet wrote:
On Tue, 2016-09-20 at 15:39 +0200, Jiri Pirko wrote:
quoted
I see. So how to silent the warning?
We can replace the atomic_add_return() and use a loop around
atomic_read() and atomic_cmpxhg()
This would change the nice property of x86 xadd into a loop.
Or we also could fallback to random generation if the atomic_cmpxchg()
fails.
I'll provide a patch, thanks.
Could you try the following ?
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index
b52496fd51075821c39435f50ac62f813967aecc..91dc108ef6dc75df80f0e73b6fa062d98dc9a58a 100644
--- a/net/ipv4/route.c+++ b/net/ipv4/route.c
@@ -476,12 +476,19 @@ u32 ip_idents_reserve(u32 hash, int segs)atomic_t*p_id=ip_idents+hash%IP_IDENTS_SZ;u32old=ACCESS_ONCE(*p_tstamp);u32now=(u32)jiffies;-u32delta=0;+u32new,delta=0;if(old!=now&&cmpxchg(p_tstamp,old,now)==old)delta=prandom_u32_max(now-old);-returnatomic_add_return(segs+delta,p_id)-segs;+old=(u32)atomic_read(p_id);+new=old+delta+segs;+/* Do not try too hard, if multiple cpus are there,+*justfallbacktopseudorandomnumber.+*/+if(unlikely(atomic_cmpxchg(p_id,old,new)!=old))+new=prandom_u32();+returnnew;}EXPORT_SYMBOL(ip_idents_reserve);
From: Eric Dumazet <hidden> Date: 2016-09-20 15:25:19
On Tue, 2016-09-20 at 07:11 -0700, Eric Dumazet wrote:
On Tue, 2016-09-20 at 15:39 +0200, Jiri Pirko wrote:
quoted
I see. So how to silent the warning?
We can replace the atomic_add_return() and use a loop around
atomic_read() and atomic_cmpxhg()
This would change the nice property of x86 xadd into a loop.
Or we also could fallback to random generation if the atomic_cmpxchg()
fails.
I'll provide a patch, thanks.
I looks at other places, I am surprised you do not see other UBSAN
issues in networking :)
netdev_refcnt_read() can potentially gives errors as well.
Tue, Sep 20, 2016 at 05:25:16PM CEST, eric.dumazet@gmail.com wrote:
On Tue, 2016-09-20 at 07:11 -0700, Eric Dumazet wrote:
quoted
On Tue, 2016-09-20 at 15:39 +0200, Jiri Pirko wrote:
quoted
I see. So how to silent the warning?
We can replace the atomic_add_return() and use a loop around
atomic_read() and atomic_cmpxhg()
This would change the nice property of x86 xadd into a loop.
Or we also could fallback to random generation if the atomic_cmpxchg()
fails.
I'll provide a patch, thanks.
I'm going to test your patch now.
I looks at other places, I am surprised you do not see other UBSAN
issues in networking :)
Not yet :)
netdev_refcnt_read() can potentially gives errors as well.
Tue, Sep 20, 2016 at 04:18:12PM CEST, eric.dumazet@gmail.com wrote:
quoted hunk
On Tue, 2016-09-20 at 07:11 -0700, Eric Dumazet wrote:
quoted
On Tue, 2016-09-20 at 15:39 +0200, Jiri Pirko wrote:
quoted
I see. So how to silent the warning?
We can replace the atomic_add_return() and use a loop around
atomic_read() and atomic_cmpxhg()
This would change the nice property of x86 xadd into a loop.
Or we also could fallback to random generation if the atomic_cmpxchg()
fails.
I'll provide a patch, thanks.
Could you try the following ?
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index
b52496fd51075821c39435f50ac62f813967aecc..91dc108ef6dc75df80f0e73b6fa062d98dc9a58a 100644
--- a/net/ipv4/route.c+++ b/net/ipv4/route.c
@@ -476,12 +476,19 @@ u32 ip_idents_reserve(u32 hash, int segs)
atomic_t *p_id = ip_idents + hash % IP_IDENTS_SZ;
u32 old = ACCESS_ONCE(*p_tstamp);
u32 now = (u32)jiffies;
- u32 delta = 0;
+ u32 new, delta = 0;
if (old != now && cmpxchg(p_tstamp, old, now) == old)
delta = prandom_u32_max(now - old);
- return atomic_add_return(segs + delta, p_id) - segs;
+ old = (u32)atomic_read(p_id);
+ new = old + delta + segs;
+ /* Do not try too hard, if multiple cpus are there,
+ * just fallback to pseudo random number.
+ */
+ if (unlikely(atomic_cmpxchg(p_id, old, new) != old))
+ new = prandom_u32();
+ return new;
}
EXPORT_SYMBOL(ip_idents_reserve);
From: Eric Dumazet <hidden> Date: 2016-09-21 01:06:20
From: Eric Dumazet <redacted>
Jiri Pirko reported an UBSAN warning happening in ip_idents_reserve()
[] UBSAN: Undefined behaviour in ./arch/x86/include/asm/atomic.h:156:11
[] signed integer overflow:
[] -2117905507 + -695755206 cannot be represented in type 'int'
Since we do not have uatomic_add_return() yet, use atomic_cmpxchg()
so that the arithmetics can be done using unsigned int.
Fixes: 04ca6973f7c1 ("ip: make IP identifiers less predictable")
Signed-off-by: Eric Dumazet <redacted>
Reported-by: Jiri Pirko <jiri@resnulli.us>
---
David, Jiri, I removed the prandom_u32() stuff in favor of a traditional
loop to meet stable requirements. Thanks !
net/ipv4/route.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
@@ -476,12 +476,18 @@ u32 ip_idents_reserve(u32 hash, int segs)atomic_t*p_id=ip_idents+hash%IP_IDENTS_SZ;u32old=ACCESS_ONCE(*p_tstamp);u32now=(u32)jiffies;-u32delta=0;+u32new,delta=0;if(old!=now&&cmpxchg(p_tstamp,old,now)==old)delta=prandom_u32_max(now-old);-returnatomic_add_return(segs+delta,p_id)-segs;+/* Do not use atomic_add_return() as it makes UBSAN unhappy */+do{+old=(u32)atomic_read(p_id);+new=old+delta+segs;+}while(atomic_cmpxchg(p_id,old,new)!=old);++returnnew-segs;}EXPORT_SYMBOL(ip_idents_reserve);
From: Eric Dumazet <redacted>
Jiri Pirko reported an UBSAN warning happening in ip_idents_reserve()
[] UBSAN: Undefined behaviour in ./arch/x86/include/asm/atomic.h:156:11
[] signed integer overflow:
[] -2117905507 + -695755206 cannot be represented in type 'int'
Since we do not have uatomic_add_return() yet, use atomic_cmpxchg()
so that the arithmetics can be done using unsigned int.
Fixes: 04ca6973f7c1 ("ip: make IP identifiers less predictable")
Signed-off-by: Eric Dumazet <redacted>
Reported-by: Jiri Pirko <jiri@resnulli.us>
---
David, Jiri, I removed the prandom_u32() stuff in favor of a traditional
loop to meet stable requirements. Thanks !