From: Aaron Conole <aconole@redhat.com>
To: Ilya Maximets <i.maximets@ovn.org>
Cc: Eelco Chaudron <echaudro@redhat.com>,
Pravin B Shelar <pshelar@ovn.org>,
netdev@vger.kernel.org, dev@openvswitch.org
Subject: Re: Patch "openvswitch: Fix Frame-size larger than 1024 bytes warning" not correct.
Date: Tue, 29 Nov 2022 09:05:07 -0500 [thread overview]
Message-ID: <f7t4juhua98.fsf@redhat.com> (raw)
In-Reply-To: <3a98720b-4eb0-595f-81ad-f90460963c62@ovn.org> (Ilya Maximets's message of "Fri, 25 Nov 2022 15:53:03 +0100")
Ilya Maximets <i.maximets@ovn.org> writes:
> On 11/15/22 17:16, Eelco Chaudron wrote:
>> Hi Pravin,
>>
>> It looks like a previous fix you made, 190aa3e77880 ("openvswitch:
>> Fix Frame-size larger than 1024 bytes warning."), is breaking
>> stuff. With this change, the actual flow lookup,
>> ovs_flow_tbl_lookup(), is done using a masked key, where it should
>> be an unmasked key. This is maybe more clear if you take a look at
>> the diff for the ufid addition, 74ed7ab9264c ("openvswitch: Add
>> support for unique flow IDs.").
>>
>> Just reverting the change gets rid of the problem, but it will
>> re-introduce the larger stack size. It looks like we either have it
>> on the stack or dynamically allocate it each time. Let me know if
>> you have any other clever fix ;)
>
> I'd say that dynamic allocation should be fine.
> We do alloc other things in the same function, and
> I don't immediately see another simple way to fix
> the problem without heavily re-working the logic.
+1
> My 2c.
> Best regards, Ilya Maximets.
>
>>
>> We found this after debugging some customer-specific issue. More details are in the following OVS patch, https://patchwork.ozlabs.org/project/openvswitch/list/?series=328315
>>
>> Cheers,
>>
>> Eelco
>>
>>
>> FYI the working revers:
>>
>>
>> Revert "openvswitch: Fix Frame-size larger than 1024 bytes warning."
>>
>> This reverts commit 190aa3e77880a05332ea1ccb382a51285d57adb5.
>>
>> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
>> index 861dfb8daf4a..660d5fdd9b28 100644
>> --- a/net/openvswitch/datapath.c
>> +++ b/net/openvswitch/datapath.c
>> @@ -948,6 +948,7 @@ static int ovs_flow_cmd_new(struct sk_buff *skb, struct genl_info *info)
>> struct sw_flow_mask mask;
>> struct sk_buff *reply;
>> struct datapath *dp;
>> + struct sw_flow_key key;
>> struct sw_flow_actions *acts;
>> struct sw_flow_match match;
>> u32 ufid_flags = ovs_nla_get_ufid_flags(a[OVS_FLOW_ATTR_UFID_FLAGS]);
>> @@ -975,24 +976,20 @@ static int ovs_flow_cmd_new(struct sk_buff *skb, struct genl_info *info)
>> }
>>
>> /* Extract key. */
>> - ovs_match_init(&match, &new_flow->key, false, &mask);
>> + ovs_match_init(&match, &key, true, &mask);
>> error = ovs_nla_get_match(net, &match, a[OVS_FLOW_ATTR_KEY],
>> a[OVS_FLOW_ATTR_MASK], log);
>> if (error)
>> goto err_kfree_flow;
>>
>> + ovs_flow_mask_key(&new_flow->key, &key, true, &mask);
>> +
>> /* Extract flow identifier. */
>> error = ovs_nla_get_identifier(&new_flow->id, a[OVS_FLOW_ATTR_UFID],
>> - &new_flow->key, log);
>> + &key, log);
>> if (error)
>> goto err_kfree_flow;
>>
>> - /* unmasked key is needed to match when ufid is not used. */
>> - if (ovs_identifier_is_key(&new_flow->id))
>> - match.key = new_flow->id.unmasked_key;
>> -
>> - ovs_flow_mask_key(&new_flow->key, &new_flow->key, true, &mask);
>> -
>> /* Validate actions. */
>> error = ovs_nla_copy_actions(net, a[OVS_FLOW_ATTR_ACTIONS],
>> &new_flow->key, &acts, log);
>> @@ -1019,7 +1016,7 @@ static int ovs_flow_cmd_new(struct sk_buff *skb, struct genl_info *info)
>> if (ovs_identifier_is_ufid(&new_flow->id))
>> flow = ovs_flow_tbl_lookup_ufid(&dp->table, &new_flow->id);
>> if (!flow)
>> - flow = ovs_flow_tbl_lookup(&dp->table, &new_flow->key);
>> + flow = ovs_flow_tbl_lookup(&dp->table, &key);
>> if (likely(!flow)) {
>> rcu_assign_pointer(new_flow->sf_acts, acts);
>>
prev parent reply other threads:[~2022-11-29 14:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-15 16:16 Patch "openvswitch: Fix Frame-size larger than 1024 bytes warning" not correct Eelco Chaudron
2022-11-23 10:56 ` Eelco Chaudron
2022-11-25 14:53 ` Ilya Maximets
2022-11-29 14:05 ` Aaron Conole [this message]
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=f7t4juhua98.fsf@redhat.com \
--to=aconole@redhat.com \
--cc=dev@openvswitch.org \
--cc=echaudro@redhat.com \
--cc=i.maximets@ovn.org \
--cc=netdev@vger.kernel.org \
--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).