From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B43A81078E for ; Tue, 20 Jun 2023 15:59:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C32D0C433C9; Tue, 20 Jun 2023 15:59:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1687276760; bh=JvRHHCpfUHPT1y5nSv1lOHmoL4oYB3Bie6coQ1YCqpU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ndYk6tuBUkmB2QJsWkmzvNPun5kdhr3H5rNYk5bHzBbHPLqM42qe77Ibp1mG8kFBD /oCyNdI2rvv1fMqbvf4L+jHJZmhS/ZXvMwxL86d4YbsNYB4VzETENq538CU9NRm10H +yJpfpHaw2L0RkdPjuKfIR/bR2Yp3cmwnJFb14QwdktFq3toQ69lpJq1zcSAmBFM32 PvEV6i/YZ1zMSoW2E1ACZONpekn0VByjNVkoewMyHGqjz1Rsgp4mS8ar6wHh8u8wTX cwXnlJOjBZwutDgk8mcyOWqQxwZBr4x/tZgiqz9vXD2uEFzks9jYnb8bt8vvUUOUO/ RRHdpPInU+9Wg== Date: Tue, 20 Jun 2023 08:59:19 -0700 From: Jakub Kicinski To: Gal Pressman Cc: Piotr Gardocki , netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org, przemyslaw.kitszel@intel.com, michal.swiatkowski@linux.intel.com, pmenzel@molgen.mpg.de, maciej.fijalkowski@intel.com, anthony.l.nguyen@intel.com, simon.horman@corigine.com, aleksander.lobakin@intel.com Subject: Re: [PATCH net-next v2 1/3] net: add check for current MAC address in dev_set_mac_address Message-ID: <20230620085919.497c3a03@kernel.org> In-Reply-To: <17cc8e10-3b54-7bb7-6245-eba11d049034@nvidia.com> References: <20230613122420.855486-1-piotrx.gardocki@intel.com> <20230613122420.855486-2-piotrx.gardocki@intel.com> <18b2b4a1-60b8-164f-ea31-5744950e138d@intel.com> <17cc8e10-3b54-7bb7-6245-eba11d049034@nvidia.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 20 Jun 2023 13:42:14 +0300 Gal Pressman wrote: > > I checked it, you're right. When the addr_assign_type is PERM or RANDOM > > and user or some driver sets the same MAC address the type doesn't change > > to NET_ADDR_SET. In my testing I didn't notice issues with that, but I'm > > sure there are cases I didn't cover. Did you discover any useful cases > > that broke after this patch or did you just notice it in code? > > This behavior change was caught in our regression tests. Why was the regression test written this way? I guess we won't flip it back to PERM if user sets a completely different address temporarily and then back to PERM - so for consistency going to SET even when the addr doesn't change may be reasonable. Piotr, you'll need to send a new followup patch on top of net-next.