From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id EA71FC6FD20 for ; Wed, 22 Mar 2023 02:28:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230250AbjCVC2m (ORCPT ); Tue, 21 Mar 2023 22:28:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230257AbjCVC2k (ORCPT ); Tue, 21 Mar 2023 22:28:40 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88F7720058 for ; Tue, 21 Mar 2023 19:28:35 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E8A9961F19 for ; Wed, 22 Mar 2023 02:28:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC6B0C433EF; Wed, 22 Mar 2023 02:28:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679452114; bh=HovZ2sXmU8iM02tE4arDfrKzjV08qXfZqz+CpXmKK2U=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=MXAfie6uVLPKK/gOmAXRMtvBDDvIVYAxrMtrVfgqAWiLPq8NoHepPUOMNkHUmHqVU rBqy0p/N+Z3SA3+DwczieQ4bjSa3M/yQnVZcKmGUTu1+jFNWjx5XckhFMiT3pj3zRV 4siWV85at3hm0sAzwjDONY49/ODuR/LzrYtv8/kKwxDlk6MgilVal+xgLQ4tJ07y9f hNQzvYTnAyueMdFzM5HFsu3SRXo96DfcsySewfvXBkk51Zbmd+E3mYCXhqMF15N43O 69BWneSE1A9nWH94O41urMbfUY7Zvu8bM3RucN0nWf/vlLETixNpNLAVPylEh8Q6uF My7VaRN263+2A== Message-ID: <43d833dd-2e1f-d225-bb56-6eed43243cb2@kernel.org> Date: Tue, 21 Mar 2023 20:28:33 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: [PATCH net-next 1/3] net: ipv4: Allow changing IPv4 address protocol Content-Language: en-US To: Petr Machata , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org Cc: Shuah Khan , Ido Schimmel , Jacques de Laval References: <6ffecb0f77dc6e444e3a130a09b4fd5d717e6504.1679399108.git.petrm@nvidia.com> From: David Ahern In-Reply-To: <6ffecb0f77dc6e444e3a130a09b4fd5d717e6504.1679399108.git.petrm@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 3/21/23 5:51 AM, Petr Machata wrote: > When IP address protocol field was added in commit 47f0bd503210 ("net: Add > new protocol attribute to IP addresses"), the semantics included the > ability to change the protocol for IPv6 addresses, but not for IPv4 > addresses. It seems this was not deliberate, but rather by accident. > > A userspace that wants to change the protocol of an address might drop and > recreate the address, but that disrupts routing and is just impractical. > > So in this patch, when an IPv4 address is replaced (through RTM_NEWADDR > request with NLM_F_REPLACE flag), update the proto at the address to the > one given in the request, or zero if none is given. This matches the > behavior of IPv6. Previously, any new value given was simply ignored. > > Signed-off-by: Petr Machata > Reviewed-by: Ido Schimmel > --- > net/ipv4/devinet.c | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: David Ahern