Re: [PATCH RFC v2 1/2] can: fix multiple delivery of a single CAN frame for overlapping CAN filters
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: 2015-03-31 12:32:22
Also in:
linux-can
On 03/30/2015 12:41 PM, Oliver Hartkopp wrote:
On 30.03.2015 12:10, Marc Kleine-Budde wrote:quoted
quoted
+ /* eliminate multiple filter matches for the same skb */ + if (*this_cpu_ptr(ro->uniq_skb) == oskb && + ktime_equal(*this_cpu_ptr(ro->uniq_tstamp), oskb->tstamp)) { + return; + } else { + *this_cpu_ptr(ro->uniq_skb) = oskb; + *this_cpu_ptr(ro->uniq_tstamp) = oskb->tstamp; + } +What happens if you're preempted somewhere in this code, it's not atomic? I think, if we only have to take care about the skb, an atomic compare exchange would work. But we have two variables....If you use a struct (see previous mail), I think the usage of get_cpu_ptr(), git_cpu_ptr() ensures that we're not preempted.Please check out https://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/ And especially https://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/x173.html#LOCK-SOFTIRQS-SAME When a softirq processes an incoming skb this remains on that selected CPU.
Okay, I was not sure about this. What about preempt_rt?
The mutithread-test from Andre just lead to the problem that the (former single instance) variables ro->uniq_skb and ro->uniq_tstamp have been used by different CPUs which made the checks unreliable.
So following the documentation and other examples in kernel source you can - use spinlocks in can_receive() in af_can.c (instead of rcu_read_lock()) - use per-CPU variables to allow the softirq to run in parallel Just make the variables atomic (as you suggested) is as bad as introduce spinlocks in can_receive() as you reduce the skb processing to just one thread. So at least percpu is the best for performance but needs to create a vector of variables (percpu).
Ack, lockless atomic-compare-exchange is only possbile for a single variable.
Putting a struct into these percpu handling can be done - but does it increase the readability in this case?
It saves ressources, 1 pointer instead of 3 (considering both of your patches) and only 1 allocation. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions | Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917-5555 | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
Attachments
- signature.asc [application/pgp-signature] 819 bytes