Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH net-next v4] ipv6: add IFLA_INET6_RA_MTU to expose mtu
 value in the RA message
To:     Rocco Yue <rocco.yue@mediatek.com>
Cc:     "David S . Miller" <davem@davemloft.net>,
        Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
        David Ahern <dsahern@kernel.org>,
        Jakub Kicinski <kuba@kernel.org>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org, rocco.yue@gmail.com,
        chao.song@mediatek.com, zhuoliang.zhang@mediatek.com
References: <ad32c931-3056-cdef-4b9b-aab654c61cb9@gmail.com>
 <20210821061030.26632-1-rocco.yue@mediatek.com>
From:   David Ahern <dsahern@gmail.com>
Message-ID: <a4a52162-c645-b369-a9f3-120f48115cde@gmail.com>
Date:   Sun, 22 Aug 2021 20:01:44 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <20210821061030.26632-1-rocco.yue@mediatek.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 8/21/21 12:10 AM, Rocco Yue wrote:
> In this patch, if an RA no longer carries an MTU or if accept_ra_mtu is reset,
> in6_dev->ra_mtu will not be reset to 0, its value will remain the previous
> accept_ra_mtu=1 and the value of the mtu carried in the RA msg. This behavior
> is same with mtu6. This should be reasonable, it would show that the device
> had indeed received the ra_mtu before set accept_ra_mtu to 0 or an RA no longer
> carries an mtu value. I am willing to listen to your suggestions and make
> changes if needed, maybe it needs to add a new separate proc handler for
> accept_ra_mtu.

fair point. Consistency is important.


> 
> In addition, at your prompt, I find that this patch maybe have a defect for
> some types of virtual devices, that is, when the state of the virtual device
> updates the value of ra_mtu during the UP period, when its state is set to
> DOWN, ra_mtu is not reset to 0, so that its ra_mtu value remains the previous
> value after the interface is re-UP. I think I need to fix it.
> 

Please do. Also, that problem should apply to all netdev's not just
virtual devices if you are referring to admin down (e.g., ip link set
$DEV down)