From: Jakub Kicinski <kuba@kernel.org>
To: Taehee Yoo <ap420073@gmail.com>
Cc: davem@davemloft.net, pabeni@redhat.com, edumazet@google.com,
jiri@resnulli.us, j.vosburgh@gmail.com, andy@greyhouse.net,
netdev@vger.kernel.org, jarod@redhat.com, razor@blackwall.org,
simon.horman@corigine.com, wangyufen@huawei.com,
syzbot+60748c96cf5c6df8e581@syzkaller.appspotmail.com
Subject: Re: [PATCH net v2] net: fix stack overflow when LRO is disabled for virtual interfaces
Date: Wed, 17 May 2023 11:45:52 -0700 [thread overview]
Message-ID: <20230517114552.08c38d4c@kernel.org> (raw)
In-Reply-To: <6701e21c-a430-6309-bc13-dcff529d8ab5@gmail.com>
On Thu, 18 May 2023 02:28:29 +0900 Taehee Yoo wrote:
> > Why doesn't the (already synchronized) upper not skip the update?
>
> The skipping logic of this is existing in the netdev_sync_lower_features().
> The purpose of this is to synchronize the lower interfaces, not the
> upper interface.
> Actually, there is no upper-only synchronization logic.
>
> Both bonding and team interfaces rely on notification mechanisms to work
> their own logic such as synchronization.
> The notification is a broadcasting mechanism.
> So, both lower and upper receive this event, and it works its own
> notification handling.
This is all true.
> But the notification mechanism currently doesn't have options such as
> filtering and these interfaces receive this event with updated feature
> flags.
We don't have to filter notifications.
> So, the upper interface can't distinguish whether the received event is
> the first event or duplicated event.
What I was thinking was basically why does __netdev_update_features()
not return early if it made no changes? Looking thru the history this
behavior has been created by commit e7868a85e1b26bcb2e. Can we revert
that and fix the problem of syncing features on new ports differently?
next prev parent reply other threads:[~2023-05-17 18:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 14:30 [PATCH net v2] net: fix stack overflow when LRO is disabled for virtual interfaces Taehee Yoo
2023-05-17 14:59 ` Eric Dumazet
2023-05-17 15:02 ` Nikolay Aleksandrov
2023-05-17 16:15 ` Jakub Kicinski
2023-05-17 17:28 ` Taehee Yoo
2023-05-17 18:45 ` Jakub Kicinski [this message]
2023-05-19 6:25 ` Taehee Yoo
2023-05-19 21:31 ` Jakub Kicinski
2023-05-20 5:50 ` patchwork-bot+netdevbpf
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=20230517114552.08c38d4c@kernel.org \
--to=kuba@kernel.org \
--cc=andy@greyhouse.net \
--cc=ap420073@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=j.vosburgh@gmail.com \
--cc=jarod@redhat.com \
--cc=jiri@resnulli.us \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=simon.horman@corigine.com \
--cc=syzbot+60748c96cf5c6df8e581@syzkaller.appspotmail.com \
--cc=wangyufen@huawei.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 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).