From: Aaron Conole <aconole@redhat.com>
To: Eric Dumazet <edumazet@google.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Pravin B Shelar <pshelar@ovn.org>,
dev@openvswitch.org, Ilya Maximets <i.maximets@ovn.org>,
Simon Horman <horms@ovn.org>,
Eelco Chaudron <echaudro@redhat.com>
Subject: Re: [PATCH net 1/2] net: openvswitch: limit the number of recursions from action sets
Date: Tue, 06 Feb 2024 09:55:03 -0500 [thread overview]
Message-ID: <f7t5xz1k5h4.fsf@redhat.com> (raw)
In-Reply-To: <CANn89iLeKwk3Pc796V7Vgvm8-GLifbwimPJsDTudBZG-1kVAMg@mail.gmail.com> (Eric Dumazet's message of "Tue, 6 Feb 2024 15:30:47 +0100")
Eric Dumazet <edumazet@google.com> writes:
> On Tue, Feb 6, 2024 at 2:11 PM Aaron Conole <aconole@redhat.com> wrote:
>>
>> The ovs module allows for some actions to recursively contain an action
>> list for complex scenarios, such as sampling, checking lengths, etc.
>> When these actions are copied into the internal flow table, they are
>> evaluated to validate that such actions make sense, and these calls
>> happen recursively.
>>
>> The ovs-vswitchd userspace won't emit more than 16 recursion levels
>> deep. However, the module has no such limit and will happily accept
>> limits larger than 16 levels nested. Prevent this by tracking the
>> number of recursions happening and manually limiting it to 16 levels
>> nested.
>>
>> The initial implementation of the sample action would track this depth
>> and prevent more than 3 levels of recursion, but this was removed to
>> support the clone use case, rather than limited at the current userspace
>> limit.
>>
>> Fixes: 798c166173ff ("openvswitch: Optimize sample action for the clone use cases")
>> Signed-off-by: Aaron Conole <aconole@redhat.com>
>> ---
>> net/openvswitch/flow_netlink.c | 33 ++++++++++++++++++++++++++++-----
>> 1 file changed, 28 insertions(+), 5 deletions(-)
>>
>> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
>> index 88965e2068ac..ba5cfa67a720 100644
>> --- a/net/openvswitch/flow_netlink.c
>> +++ b/net/openvswitch/flow_netlink.c
>> @@ -48,6 +48,9 @@ struct ovs_len_tbl {
>>
>> #define OVS_ATTR_NESTED -1
>> #define OVS_ATTR_VARIABLE -2
>> +#define OVS_COPY_ACTIONS_MAX_DEPTH 16
>> +
>> +static DEFINE_PER_CPU(int, copy_actions_depth);
>>
>> static bool actions_may_change_flow(const struct nlattr *actions)
>> {
>> @@ -3148,11 +3151,11 @@ static int copy_action(const struct nlattr *from,
>> return 0;
>> }
>>
>> -static int __ovs_nla_copy_actions(struct net *net, const struct nlattr *attr,
>> - const struct sw_flow_key *key,
>> - struct sw_flow_actions **sfa,
>> - __be16 eth_type, __be16 vlan_tci,
>> - u32 mpls_label_count, bool log)
>> +static int ___ovs_nla_copy_actions(struct net *net, const struct nlattr *attr,
>> + const struct sw_flow_key *key,
>> + struct sw_flow_actions **sfa,
>> + __be16 eth_type, __be16 vlan_tci,
>> + u32 mpls_label_count, bool log)
>> {
>> u8 mac_proto = ovs_key_mac_proto(key);
>> const struct nlattr *a;
>> @@ -3478,6 +3481,26 @@ static int __ovs_nla_copy_actions(struct net *net, const struct nlattr *attr,
>> return 0;
>> }
>>
>> +static int __ovs_nla_copy_actions(struct net *net, const struct nlattr *attr,
>> + const struct sw_flow_key *key,
>> + struct sw_flow_actions **sfa,
>> + __be16 eth_type, __be16 vlan_tci,
>> + u32 mpls_label_count, bool log)
>> +{
>> + int level = this_cpu_read(copy_actions_depth);
>> + int ret;
>> +
>> + if (level > OVS_COPY_ACTIONS_MAX_DEPTH)
>> + return -EOVERFLOW;
>> +
>
> This code seems to run in process context.
>
> Using per cpu limit would not work, unless you disabled migration ?
Oops - I didn't consider it.
Given that, maybe the best approach would not to rely on per-cpu
counter. I'll respin in the next series with a depth counter that I pass
to the function instead and compare that. I guess that should address
migration and eliminate the need for per-cpu counter.
Does it make sense?
>> + __this_cpu_inc(copy_actions_depth);
>> + ret = ___ovs_nla_copy_actions(net, attr, key, sfa, eth_type,
>> + vlan_tci, mpls_label_count, log);
>> + __this_cpu_dec(copy_actions_depth);
>> +
>> + return ret;
>> +}
>> +
>> /* 'key' must be the masked key. */
>> int ovs_nla_copy_actions(struct net *net, const struct nlattr *attr,
>> const struct sw_flow_key *key,
>> --
>> 2.41.0
>>
next prev parent reply other threads:[~2024-02-06 14:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-06 13:11 [PATCH net 0/2] net: openvswitch: limit the recursions from action sets Aaron Conole
2024-02-06 13:11 ` [PATCH net 1/2] net: openvswitch: limit the number of " Aaron Conole
2024-02-06 14:30 ` Eric Dumazet
2024-02-06 14:55 ` Aaron Conole [this message]
2024-02-06 14:56 ` Eric Dumazet
2024-02-06 15:40 ` Aaron Conole
2024-02-06 13:11 ` [PATCH net 2/2] selftests: openvswitch: Add validation for the recursion test Aaron Conole
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=f7t5xz1k5h4.fsf@redhat.com \
--to=aconole@redhat.com \
--cc=davem@davemloft.net \
--cc=dev@openvswitch.org \
--cc=echaudro@redhat.com \
--cc=edumazet@google.com \
--cc=horms@ovn.org \
--cc=i.maximets@ovn.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pshelar@ovn.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).