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;
Date:   Tue, 2 May 2023 08:57:18 -0700
From:   Jakub Kicinski <kuba@kernel.org>
To:     Ganesh Babu <ganesh.babu@ekinops.com>
Cc:     "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] net: mroute6.h: change type of mif6c_pifi to __u32
Message-ID: <20230502085718.0551a86d@kernel.org>
In-Reply-To: <PAZP264MB406414BA18689729DDE24F3DFC659@PAZP264MB4064.FRAP264.PROD.OUTLOOK.COM>
References: <PAZP264MB4064279CBAB0D7672726F4A1FC889@PAZP264MB4064.FRAP264.PROD.OUTLOOK.COM>
        <20230328191456.43d2222e@kernel.org>
        <PAZP264MB406414BA18689729DDE24F3DFC659@PAZP264MB4064.FRAP264.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Tue, 2 May 2023 08:07:10 +0000 Ganesh Babu wrote:
> Thank you for your response. Regarding the proposed change to
> the mif6ctl structure in mroute6.h, I would like to clarify,
> that changing the datatype of mif6c_pifi from __u16 to __u32
> will not change the offset of the structure members, which
> means that the size of the structure remains the same and
> the ABI remains compatible. Furthermore, ifindex is treated
> as an integer in all the subsystems of the kernel and not
> as a 16-bit value. Therefore, changing the datatype of
> mif6c_pifi from __u16 to __u32 is a natural and expected
> change that aligns with the existing practice in the kernel.
> I understand that the mif6ctl structure is part of the uAPI
> and changing its geometry is not allowed. However, in this
> case, we are not changing the geometry of the structure,
> as the size of the structure remains the same and the offset
> of the structure members will not change. Thus, the proposed
> change will not affect the ABI or the user API. Instead, it
> will allow the kernel to handle 32-bit ifindex values without
> any issues, which is essential for the smooth functioning of
> the PIM6 protocol. I hope this explanation clarifies any
> concerns you may have had. Let me know if you have any further
> questions or need any more details.

Please don't top post on the list.

How does the hole look on big endian? Does it occupy the low or 
the high bytes?

There's also the problem of old user space possibly not initializing
the hole, and passing in garbage.