From: Florian Westphal <fw@strlen.de>
To: Stefan Wiehler <stefan.wiehler@nokia.com>
Cc: Florian Westphal <fw@strlen.de>,
"David S . Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net v6 09/10] ip6mr: Lock RCU before ip6mr_get_table() call in ip6mr_rtm_getroute()
Date: Fri, 18 Oct 2024 13:52:31 +0200 [thread overview]
Message-ID: <20241018115231.GB28324@breakpoint.cc> (raw)
In-Reply-To: <a7f1f376-3f0e-4455-816e-ae7b4051d501@nokia.com>
Stefan Wiehler <stefan.wiehler@nokia.com> wrote:
> >> When IPV6_MROUTE_MULTIPLE_TABLES is enabled, multicast routing tables
> >> must be read under RCU or RTNL lock.
> >>
> >> Fixes: d1db275dd3f6 ("ipv6: ip6mr: support multiple tables")
> >> Signed-off-by: Stefan Wiehler <stefan.wiehler@nokia.com>
> >> ---
> >> net/ipv6/ip6mr.c | 10 +++++++---
> >> 1 file changed, 7 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
> >> index b169b27de7e1..39aac81a30f1 100644
> >> --- a/net/ipv6/ip6mr.c
> >> +++ b/net/ipv6/ip6mr.c
> >> @@ -2633,27 +2633,31 @@ static int ip6mr_rtm_getroute(struct sk_buff *in_skb, struct nlmsghdr *nlh,
> >> grp = nla_get_in6_addr(tb[RTA_DST]);
> >> tableid = tb[RTA_TABLE] ? nla_get_u32(tb[RTA_TABLE]) : 0;
> >>
> >> + rcu_read_lock();
> >
> > AFAICS ip6mr_rtm_getroute() runs with RTNL held, so I don't see
> > why this patch is needed.
>
> That's true, but it's called neither with RCU nor RTNL lock when
> RTNL_FLAG_DOIT_UNLOCKED is set in rtnetlink_rcv_msg():
Sure, but RTNL_FLAG_DOIT_UNLOCKED is not set for this function:
err = rtnl_register_module(THIS_MODULE, RTNL_FAMILY_IP6MR, RTM_GETROUTE,
ip6mr_rtm_getroute, ip6mr_rtm_dumproute, 0);
(0 == flag field). So RNTL is held. Would of course be nice to convert it to RCU
eventually but thats an enhancement, not a bug fix, so this must be in
separate changesets, targetting net and net-next, respectively.
> I realized now that I completely misunderstood how ip6mr_rtm_dumproute() gets
> called - it should be still safe though because mpls_netconf_dump_devconf() and
> getaddr_dumpit() hold the RCU lock while mpls_dump_routes() asserts that the
> RTNL lock is held. Is that observation correct?
{THIS_MODULE, PF_PHONET, RTM_GETADDR, NULL, getaddr_dumpit, 0},
{THIS_MODULE, PF_MPLS, RTM_GETROUTE, mpls_getroute, mpls_dump_routes, 0},
Both get called with RTNL mutex held, but not within an RCU read side
section.
but:
{THIS_MODULE, PF_MPLS, RTM_GETNETCONF, [..] mpls_netconf_dump_devconf,
RTNL_FLAG_DUMP_UNLOCKED}, // == no RTNL held
Means: dump callback is invoked without RTNL mutex. Those functions
are also called without and RCU read-side section.
Both the get (doit) and the dumper function callbacks need to
explicitly opt-in for RTNL-less invocation at register time.
next prev parent reply other threads:[~2024-10-18 11:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 17:37 [PATCH net v6 00/10] Lock RCU before calling ip6mr_get_table() Stefan Wiehler
2024-10-17 17:37 ` [PATCH net v6 01/10] ip6mr: Lock RCU before ip6mr_get_table() call in ip6mr_vif_seq_start() Stefan Wiehler
2024-10-17 17:37 ` [PATCH net v6 02/10] ip6mr: Lock RCU before ip6mr_get_table() call in ip6mr_ioctl() Stefan Wiehler
2024-10-17 17:37 ` [PATCH net v6 03/10] ip6mr: Lock RCU before ip6mr_get_table() call in ip6mr_compat_ioctl() Stefan Wiehler
2024-10-17 17:37 ` [PATCH net v6 04/10] ip6mr: Lock RCU before ip6mr_get_table() call in ip6mr_get_route() Stefan Wiehler
2024-10-17 17:37 ` [PATCH net v6 05/10] ip6mr: Lock RTNL before ip6mr_new_table() call in ip6mr_rules_init() Stefan Wiehler
2024-10-17 18:10 ` Florian Westphal
2024-10-18 10:41 ` Stefan Wiehler
2024-10-17 17:37 ` [PATCH net v6 06/10] ip6mr: Lock RCU before ip6mr_get_table() call in ip6mr_mfc_seq_start() Stefan Wiehler
2024-10-17 17:37 ` [PATCH net v6 07/10] ip6mr: Lock RCU before ip6mr_get_table() call in ip6_mroute_setsockopt() Stefan Wiehler
2024-10-17 18:28 ` Florian Westphal
2024-10-23 10:24 ` Paolo Abeni
2024-10-17 17:37 ` [PATCH net v6 08/10] ip6mr: Lock RCU before ip6mr_get_table() call in ip6_mroute_getsockopt() Stefan Wiehler
2024-10-17 17:37 ` [PATCH net v6 09/10] ip6mr: Lock RCU before ip6mr_get_table() call in ip6mr_rtm_getroute() Stefan Wiehler
2024-10-17 18:14 ` Florian Westphal
2024-10-18 11:24 ` Stefan Wiehler
2024-10-18 11:52 ` Florian Westphal [this message]
2024-10-17 17:37 ` [PATCH net v6 10/10] Revert "ipv6: Fix suspicious RCU usage warning in ip6mr" Stefan Wiehler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241018115231.GB28324@breakpoint.cc \
--to=fw@strlen.de \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=stefan.wiehler@nokia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.