Re: Data race in net/mptcp/pm_netlink.c

[Matthieu Baerts <matttbe@kernel.org>]

Hello,

On 22/11/2024 08:34, clingfei wrote:
> linux-next weekly scan reports that there might be data race in
> net/mptcp/pm_netlink.c, when mptcp_pm_nl_flush_addrs_doit
> bitmap_zeroing pernet->id_bit_map at line 1748, there might be a
> concurrent read at line 1864.
> Should we add a lock to protect pernet->id_bit_map?

I don't think there is an issue here: if the flush is being done in
parallel to an in progress dump (max 255 addresses), I don't know what
the userspace can really expect. What's important is not to access freed
data, which should be prevented by the 'rcu_read_lock()'.

So it looks like no lock or id_bitmap duplication is needed here. Even
if there was a need for a certain consistency there, these 2 operations
should not happen in parallel, because the MPTCP generic NL family
doesn't have ".parallel_ops = true".

So I think this report is a false positive, no?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.