Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp3482302pxv; Mon, 12 Jul 2021 19:07:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxyrU4fInJv5E5xuIxPqpVvA38tLUJUt3Eiq4ufTNwrQN+HE6YBp1MsIgGDInIU7At2FKFO X-Received: by 2002:a05:6402:2206:: with SMTP id cq6mr2341869edb.209.1626142052479; Mon, 12 Jul 2021 19:07:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626142052; cv=none; d=google.com; s=arc-20160816; b=DmL69CJ92tXe97U3+PyFS77O07lNxXO/Ly5eJGZ/wXkmpRIa1PbiAcKp8J2soSNKBt YiKGVNw8/pQ5wJjf/ppQ3Eb5W0uoPr1VzEQCAt/l5OG8r5eyT1TLrZCgtPBPiuTFxOOr rzx02RnLwbiveCiOI7k9TlfYRRPjm8a8IF/aiTCJZDhgrjPw0x2/WAQyYm/CvzmlZwtZ mYN7mJE7eyENs4h3UOK63GDLNMn96JYBSIY7hPxj3i8CW1pHJfftLL0LjUUC+jx99/uM VWFV1UUEE81gYnBv8loGRaET7nyVhQP1tsLzRowTg1Zvzj9EhGz5bPfXtmDd/j9VtaEJ DfiQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=XDdgqtjk8+QR6f9GPv23SppKLIeSkPrV7ytOtO5MnmM=; b=cPkDJ6FuCEAlSu+J4e1NEHwuu7lxNG+nSXAefMaMqIDs7vuLKkm3C1Rdwc2kkPDtoE rBlof00WWdb5TwT7GcQblld9ZNj4WZ/iM5h1n1sZOYcjrN07mkr6ZdXi8yJZiksSh/3r mtEVhsqx91vByq5jX7W1/SUFneax+eLouKrlaimR6vxYT/C3gCNCM9DUcZJBORDvDc8N +PbZ4xfQf4tIlFEy0qFtNTcoA7hjHnvWFbsHHKNP2nJn3aGpYluDNDRnybYBZIg0jLkX J+dvWy+hjmbLGhaHQ0MOxO9DHrSx60rzpLUzx+51YlIxJCIOKHuEcO00VE7L1tl4jthy fVbg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u26si13615936ejz.460.2021.07.12.19.06.57; Mon, 12 Jul 2021 19:07:32 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230022AbhGMCHz (ORCPT + 99 others); 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