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 X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, UNPARSEABLE_RELAY,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E76BC07E9A for ; Tue, 13 Jul 2021 02:05:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 756E46101B for ; Tue, 13 Jul 2021 02:05:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231179AbhGMCHz (ORCPT ); Mon, 12 Jul 2021 22:07:55 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:60346 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S229581AbhGMCHy (ORCPT ); Mon, 12 Jul 2021 22:07:54 -0400 X-UUID: 69e3afa93de54c77b21be6682f21871a-20210713 X-UUID: 69e3afa93de54c77b21be6682f21871a-20210713 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 1515791918; Tue, 13 Jul 2021 10:05:00 +0800 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkmbs01n1.mediatek.inc (172.21.101.68) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 13 Jul 2021 10:04:58 +0800 Received: from localhost.localdomain (10.15.20.246) by mtkcas11.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 13 Jul 2021 10:04:57 +0800 From: Rocco Yue To: David Ahern CC: "David S . Miller" , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , Matthias Brugger , , , , , , , , , , , , Rocco Yue Subject: Re: [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode Date: Tue, 13 Jul 2021 09:49:24 +0800 Message-ID: <20210713014924.1831-1-rocco.yue@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <40951584-8f53-4e95-4a6b-14ae1cf7f011@gmail.com> References: <40951584-8f53-4e95-4a6b-14ae1cf7f011@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> According to your suggestion, I checked the ipv6 code again. In my >> opinion, adding another addr_gen_mode may not be suitable. >> >> (1) >> In the user space, the process enable the ipv6 stable privacy mode by >> setting the "/proc/sys/net/ipv6/conf//stable_secret". >> >> In the kernel, the addr_gen_mode of a networking device is switched to >> IN6_ADDR_GEN_MODE_STABLE_PRIVACY by judging the bool value of >> "cnf.stable_secret.initialized". > > and that can be updated. If the default (inherited) setting is > IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA, then do not change to > IN6_ADDR_GEN_MODE_STABLE_PRIVACY. > >> >> So, although adding an additional IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA, >> user space process has some trouble to let kernel switch the iface's >> addr_gen_mode to the IN6_ADDR_GEN_MODE_STABLE_PRIVACY_NO_LLA. >> >> This is not as flexible as adding a separate sysctl. >> >> (2) >> After adding "proc/sys/net/ipv6//disable_gen_linklocal_addr", >> so that kernel can keep the original code logic of the stable_secret >> proc file, and expand when the subsequent kernel adds a new add_gen_mode >> more flexibility and applicability. >> >> And we only need to care about the networking device that do not >> generate an ipv6 link-local address, and not the addr_gen_mode that >> this device is using. >> >> Maybe adding a separate sysctl is a better choice. >> Looking forward to your professional reply again. > > per device sysctl's are not free. I do not see a valid reason for a > separate disable knob. Hi David, Thanks for your reply, honstly, this separate sysctl is really useful and convenient. It allows users to simply configure the disable_gen_linklocal_addr proc file to achieve customized configuration of ipv6 link-local address without worrying about when the kernel will automatically generate a link-local address. At the same time, maybe a new addr_gen_mode will be added in the future. If the method of adding a sysctl is adopted, we don't need to consider the existing addr_gen_mode and the impact of adding another new addr_gen_mode in the future. Just simply echoing different values to the disable_gen_linklocal_addr proc file can achieve this needs. Thanks, Rocco