[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201208112730.05d13f3d@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com>
Date: Tue, 8 Dec 2020 11:27:30 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jarod Wilson <jarod@...hat.com>
Cc: linux-kernel@...r.kernel.org, Ivan Vecera <ivecera@...hat.com>,
Jay Vosburgh <j.vosburgh@...il.com>,
Veaceslav Falico <vfalico@...il.com>,
Andy Gospodarek <andy@...yhouse.net>,
"David S. Miller" <davem@...emloft.net>,
Thomas Davis <tadavis@....gov>, netdev@...r.kernel.org
Subject: Re: [PATCH net v4] bonding: fix feature flag setting at init time
On Sat, 5 Dec 2020 12:22:29 -0500 Jarod Wilson wrote:
> Don't try to adjust XFRM support flags if the bond device isn't yet
> registered. Bad things can currently happen when netdev_change_features()
> is called without having wanted_features fully filled in yet. This code
> runs both on post-module-load mode changes, as well as at module init
> time, and when run at module init time, it is before register_netdevice()
> has been called and filled in wanted_features. The empty wanted_features
> led to features also getting emptied out, which was definitely not the
> intended behavior, so prevent that from happening.
>
> Originally, I'd hoped to stop adjusting wanted_features at all in the
> bonding driver, as it's documented as being something only the network
> core should touch, but we actually do need to do this to properly update
> both the features and wanted_features fields when changing the bond type,
> or we get to a situation where ethtool sees:
>
> esp-hw-offload: off [requested on]
>
> I do think we should be using netdev_update_features instead of
> netdev_change_features here though, so we only send notifiers when the
> features actually changed.
>
> Fixes: a3b658cfb664 ("bonding: allow xfrm offload setup post-module-load")
> Reported-by: Ivan Vecera <ivecera@...hat.com>
> Suggested-by: Ivan Vecera <ivecera@...hat.com>
Applied, thanks!
Powered by blists - more mailing lists