[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231031165245.-pTSiGsg@linutronix.de>
Date: Tue, 31 Oct 2023 17:52:45 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Oliver Hartkopp <socketcan@...tkopp.net>
Cc: Marc Kleine-Budde <mkl@...gutronix.de>, linux-can@...r.kernel.org,
netdev@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC] Questionable RCU/BH usage in cgw_create_job().
On 2023-10-31 17:14:01 [+0100], Oliver Hartkopp wrote:
> Hi Sebastian,
Hi Oliver,
> The content of gwj->mod can be overwritten with new modification rules at
> runtime. But this update (with memcpy) has to take place when there is no
> incoming network traffic.
This is my assumption. But "no incoming network traffic" is not ensured,
right?
> > If not, my suggestion would be replacing the bh-off, memcpy part with:
> > | old_mod = rcu_replace_pointer(gwj->mod, new_mod, true);
> > | kfree_rcu_mightsleep(old_mod);
> >
> > and doing the needed pointer replacement with for struct cgw_job::mod
> > and RCU annotation.
>
> Replacing a pointer does not copy any data to the cf_mod structure, right?
Yes. The cf_mod data structure is embedded into cgw_job. So it would
have to become a pointer. Then cgw_create_job() would create a new
cf_mod via cgw_parse_attr() but it would be a new allocated structure
instead on stack like it is now. And then in the existing case you would
do the swap. Otherwise (non-existing, brand new) it becomes part of the
new created cgw_job.
The point is to replace/ update cf_mod at runtime while following RCU
rules so always either new or the old object is observed. Never an
intermediate step.
> Best regards,
> Oliver
Sebastian
Powered by blists - more mailing lists