Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <72641fb1-f547-197b-b319-ce3b943b192d@intel.com>
Date:   Mon, 19 Dec 2022 10:25:27 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.0
Subject: Re: [PATCH v7] igb: Assign random MAC address instead of fail in case
 of invalid one
Content-Language: en-US
To:     Alexander Duyck <alexander.duyck@gmail.com>,
        Heiner Kallweit <hkallweit1@gmail.com>
CC:     Jakub Kicinski <kuba@kernel.org>,
        Leon Romanovsky <leon@kernel.org>,
        "Lixue Liang" <lianglixuehao@126.com>,
        <anthony.l.nguyen@intel.com>, <linux-kernel@vger.kernel.org>,
        <jesse.brandeburg@intel.com>, <davem@davemloft.net>,
        <edumazet@google.com>, <pabeni@redhat.com>,
        <netdev@vger.kernel.org>, <lianglixue@greatwall.com.cn>
References: <20221213074726.51756-1-lianglixuehao@126.com>
 <Y5l5pUKBW9DvHJAW@unreal> <20221214085106.42a88df1@kernel.org>
 <Y5obql8TVeYEsRw8@unreal> <20221214125016.5a23c32a@kernel.org>
 <4576ee79-1040-1998-6d91-7ef836ae123b@gmail.com>
 <CAKgT0UdZUmFD8qYdF6k47ZmRgB0jS-graOYgB5Se+y+4fKqW8w@mail.gmail.com>
From:   Jacob Keller <jacob.e.keller@intel.com>
In-Reply-To: <CAKgT0UdZUmFD8qYdF6k47ZmRgB0jS-graOYgB5Se+y+4fKqW8w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YkxYb2xabW5QUUNLTS9uNjF3czh0bi9mUDdiK2tPMUcxa1NqQlJubkIyenZL?=
 =?utf-8?B?dnlUNkY3UzQ1UnVZc3VoMVkzTm4wbFYzeTE5UDFYMVV1ZlZEaVNZNnVzUC8y?=
 =?utf-8?B?KzdvclhKU3lSZTBnSzZUaXRwTE94RFhrYU9iTjYzcG5qSFJYa1FGRDBVK0ZK?=
 =?utf-8?B?WnFLTFMzejR5N3JaTTVmQysyek9nYnQ0c200YStGamRFTHUvWU1ROXdlL21n?=
 =?utf-8?B?YkJiQ3VzV1FrTVVpMlJRajJNczY2SXNHZXhWK1NNaUIwOXpVOTU2bTNWZnEz?=
 =?utf-8?B?M0swdWtqNUFYbUtnd0J4SUV0UXcxT1gxT2RtUllPSlZlc1k3cDZFRUhYWUJY?=
 =?utf-8?B?U3BCUVJLL1pJZFo1ZXlzeTU0bk85QzExanJDVUZQcVJPV1lidWRTYXJQOHkv?=
 =?utf-8?B?cURhOUo4MStYRjVIL3hFVjYzdGhsVENwdUFrVnhwM2FjMW1qenBETTVZcjB5?=
 =?utf-8?B?ZFl3YVFXMlFVY0FITVdvOXoyYTU4L2dFOFVJV3Z2b3hyUlJWNUwzTzQzaHg4?=
 =?utf-8?B?YmVNQ044bjU1NXRWcGM2T3dWT001bTVMZVdWUG8xakVsRFBTL1hFTzkyRjc0?=
 =?utf-8?B?b2E3a2R0MXJSK1N5QUNGelJMTldDQzZrSkhXdWV5S1o2REtRVzlrZXY0Nm5D?=
 =?utf-8?B?TktBMkMyUVJBN1cxU1haV0Zra1N1Y2d0cHZLNTBDVmZRWDlRdnI3Y2h1czFo?=
 =?utf-8?B?RE84UnRlSi8xVnBvQXRRaXlNQmVkWnRCVGt5bXByUmVqQ1QwN2VtN3RKVTVr?=
 =?utf-8?B?WjI4NTdTWWtxS2NsVmdZYUMvcUMwNXQxaStxL0FtYlVQdmNsUlpiK2syU1B4?=
 =?utf-8?B?NTk5SVhPTktrVmRkbWhucUZxb1ZXSFNaenZrTjVkeXZGekVoNGpPTlBCcC90?=
 =?utf-8?B?YjRyRm04dXh4ZG5wckp1VUcrSjNHNXpjRUgyS3c2Z3doUUZSQXR4N0RlV0wz?=
 =?utf-8?B?NW9lUUIxR1RiZGJHaW1uUnpyMFNtcXFZcXM3QjBHUXQ5TFV1bnJNWWp0R0dR?=
 =?utf-8?B?YUIvVTQrSEZieWtxQjhkSU5aL2d0ajc3c0t6RUx5enJ6NStSaVNmbmFtVkVj?=
 =?utf-8?B?N3lIQ0gxdi9LdGlOdmhBdm1TMGg5Z2tFWDhLMG1wSFZuQzBKL2dwUmRNcWRG?=
 =?utf-8?B?cEJFU2xWaVE0aFZSV3VHbjhhR3dLdENkTEorQTk3OUdZV0gwYWdXb1BGOFdl?=
 =?utf-8?B?TVlML1lyOFIxMTFlcklHNG0vazBEM0JHNmdRVTQvZGYvcjFzQ2w2WGIvQUNq?=
 =?utf-8?B?NDBZdmtCNEMrZGhGK1RqeWxPblphWlYxemVCd3FQdndCV1k5VEZmbklueEZa?=
 =?utf-8?B?Z1Z0VVFHa0d5SVJLdGprZEhvZ3hvWk5SUGVQamxESDdFV25WYTJKQVZFdjV1?=
 =?utf-8?B?cXIxMEFnTDZZcExWMitOZ1dOT0dIV3Bldk9IV2F4WXJZdTRISk9vd2ZPYjlx?=
 =?utf-8?B?bENCSTJPZW1Md2lnZ1pyWFBTcUgvQUNucHRYbHg2Q25FNHZGVFlaUC92SXJh?=
 =?utf-8?B?NTgwb2NSeGFPTWNNdUw5QngrN0VhVHpqb0o5N0hhQ05vS2NSM3JWa2ZsL0FY?=
 =?utf-8?B?QWRQZzFGc0hKWmJtMkR2Wkg4cGV3VFJjRWt3dmhxQ29sWGlJNEZJcGJTM2RS?=
 =?utf-8?B?VXl2Rk8xNHlhOTBXV2QyVC9FSWQxbFNzMDZQMzI4b3BrZGg5SmtSWS85Nmpr?=
 =?utf-8?B?Vy9PMTZOODZ0dmo1S0dLYjd2TkZPTUlrMUFsRlovUlhFUzNhZ1g3WGFxUmNw?=
 =?utf-8?B?ZXk4YmJkOW1GakdmRkh1L1VjbERpM0VqMW1xZ2JnblZLeDBDNnRpRXdheW9j?=
 =?utf-8?B?QnVocU4weFpZcW51SE1CMWZCNGhOL0pFc1JFN1dRallycGF5aUpQZm02QjRD?=
 =?utf-8?B?aEwzTnNUSGNadFRYZE41d2NRY2xXd25Ga1FyY21pYitVSmZpbDQ5WmJKajFE?=
 =?utf-8?B?U2hJNjV2S2p0UDMybE8yT2U4NnN2TVN2NHBTamRPRXJ3TzBMWGcramNxNlMr?=
 =?utf-8?B?WGJEb3VjSEQwaktScEVsNG40WUdHeDk2Y2J4aW5BWmZFS0FKNnBKY1ZwZ1FQ?=
 =?utf-8?B?M2hLMlhad0Jud1dRZENuZEZoNTZhMGlZdUIxcHNKbllQMjVRam1CZWF4b1Nl?=
 =?utf-8?B?UTdKTllaVlg5QkpZTE9zYnVrNUJTeHB3U1F2Qk5SWms5ZmdvVkpobVVlZWw2?=
 =?utf-8?B?Zmc9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: c83e6cfe-6e73-44b3-4212-08dae1ee68e0
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5089.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2022 18:25:30.6384
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: opadi4PtveFuN1AJOR+JTSiyHRx7euZDNvG8J3cR8Wg4iwH/iJgg3/cW/9hZxYxICZ+7jg7Iq3a5nmt3jieef9DX33FGxw+z6hv9WL6ADNU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR11MB6228
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 12/14/2022 3:17 PM, Alexander Duyck wrote:
> On Wed, Dec 14, 2022 at 1:43 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> As far as the discussion for module parameter vs something else. The
> problem with the driver is that it is monolithic so it isn't as if
> there is a devlink interface to configure a per-network parameter
> before the network portion is loaded. The module parameter is a
> compromise that should only be used to enable the workaround so that
> the driver can be loaded so that the EEPROM can then be edited. If
> anything, tying the EEPROM to ethtool is the issue. If somebody wants
> to look at providing an option to edit the EEPROM via devlink that
> would solve the issue as then the driver could expose the devlink
> interface to edit the EEPROM without having to allocate and register a
> netdev.


Right. Since igb only has netdev as the way to change the MAC or edit
the EEPROM, there is no way to fix this if the driver doesn't load.

Ideally the driver would instead still be able to register and expose an
interface (devlink?) that does not depend on the MAC, and when the MAC
is invalid it just would not register a netdevice. Another option might
me some method of a netdev to say "I don't have a valid MAC, so don't
allow me to do traffic"?

A global sysctl policy as discussed elsewhere in the thread also seems
reasonable to me, given that modifying the driver to expose devlink is a
lot more work. Of course we'd also need to check and get other drivers
to use the same global policy as well.

Thanks,
Jake