[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230517114552.08c38d4c@kernel.org>
Date: Wed, 17 May 2023 11:45:52 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Taehee Yoo <ap420073@...il.com>
Cc: davem@...emloft.net, pabeni@...hat.com, edumazet@...gle.com,
jiri@...nulli.us, j.vosburgh@...il.com, andy@...yhouse.net,
netdev@...r.kernel.org, jarod@...hat.com, razor@...ckwall.org,
simon.horman@...igine.com, wangyufen@...wei.com,
syzbot+60748c96cf5c6df8e581@...kaller.appspotmail.com
Subject: Re: [PATCH net v2] net: fix stack overflow when LRO is disabled for
virtual interfaces
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?
Powered by blists - more mailing lists