[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CADPKJ-7==Bo=Wu6cHQ_y2qQVsPoJGeP3x0GztMXYcDaKCfmrkQ@mail.gmail.com>
Date: Fri, 22 Nov 2024 15:34:06 +0800
From: clingfei <clf700383@...il.com>
To: Matthieu Baerts <matttbe@...nel.org>, Mat Martineau <martineau@...nel.org>,
Geliang Tang <geliang@...nel.org>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Simon Horman <horms@...nel.org>, netdev@...r.kernel.org, mptcp@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Data race in net/mptcp/pm_netlink.c
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?
The report is listed below.
** CID 1601938: Concurrent data access violations (MISSING_LOCK)
/net/mptcp/pm_netlink.c: 1864 in mptcp_pm_nl_dump_addr()
________________________________________________________________________________________________________
*** CID 1601938: Concurrent data access violations (MISSING_LOCK)
/net/mptcp/pm_netlink.c: 1864 in mptcp_pm_nl_dump_addr()
1858 int i;
1859
1860 pernet = pm_nl_get_pernet(net);
1861
1862 rcu_read_lock();
1863 for (i = id; i < MPTCP_PM_MAX_ADDR_ID + 1; i++) {
>>> CID 1601938: Concurrent data access violations (MISSING_LOCK)
>>> Accessing "pernet->id_bitmap" without holding lock "pm_nl_pernet.lock". Elsewhere, "pm_nl_pernet.id_bitmap" is written to with "pm_nl_pernet.lock" held 1 out of 1 times.
1864 if (test_bit(i, pernet->id_bitmap)) {
1865 entry = __lookup_addr_by_id(pernet, i);
1866 if (!entry)
1867 break;
1868
1869 if (entry->addr.id <= id)
Powered by blists - more mailing lists