All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rocco Yue <rocco.yue@mediatek.com>
To: David Ahern <dsahern@gmail.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>, <maze@google.com>,
	<lorenzo@google.com>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>, <wsd_upstream@mediatek.com>,
	<rocco.yue@gmail.com>, <chao.song@mediatek.com>,
	<kuohong.wang@mediatek.com>, <zhuoliang.zhang@mediatek.com>,
	Rocco Yue <rocco.yue@mediatek.com>
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	[thread overview]
Message-ID: <20210713014924.1831-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <40951584-8f53-4e95-4a6b-14ae1cf7f011@gmail.com>

>> 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/<iface>/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/<iface>/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

WARNING: multiple messages have this Message-ID (diff)
From: Rocco Yue <rocco.yue@mediatek.com>
To: David Ahern <dsahern@gmail.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>, <maze@google.com>,
	<lorenzo@google.com>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>, <wsd_upstream@mediatek.com>,
	<rocco.yue@gmail.com>, <chao.song@mediatek.com>,
	<kuohong.wang@mediatek.com>,  <zhuoliang.zhang@mediatek.com>,
	Rocco Yue <rocco.yue@mediatek.com>
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	[thread overview]
Message-ID: <20210713014924.1831-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <40951584-8f53-4e95-4a6b-14ae1cf7f011@gmail.com>

>> 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/<iface>/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/<iface>/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
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Rocco Yue <rocco.yue@mediatek.com>
To: David Ahern <dsahern@gmail.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>, <maze@google.com>,
	<lorenzo@google.com>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>, <wsd_upstream@mediatek.com>,
	<rocco.yue@gmail.com>, <chao.song@mediatek.com>,
	<kuohong.wang@mediatek.com>,  <zhuoliang.zhang@mediatek.com>,
	Rocco Yue <rocco.yue@mediatek.com>
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	[thread overview]
Message-ID: <20210713014924.1831-1-rocco.yue@mediatek.com> (raw)
In-Reply-To: <40951584-8f53-4e95-4a6b-14ae1cf7f011@gmail.com>

>> 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/<iface>/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/<iface>/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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-07-13  2:05 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01  1:59 [PATCH] net: ipv6: don't generate link-local address in any addr_gen_mode Rocco Yue
2021-07-01  1:59 ` Rocco Yue
2021-07-01  1:59 ` Rocco Yue
2021-07-01  3:03 ` David Ahern
2021-07-01  3:03   ` David Ahern
2021-07-01  3:03   ` David Ahern
2021-07-01  3:39   ` Rocco Yue
2021-07-01  3:39     ` Rocco Yue
2021-07-01  3:39     ` Rocco Yue
2021-07-01  4:41     ` David Ahern
2021-07-01  4:41       ` David Ahern
2021-07-01  4:41       ` David Ahern
2021-07-01  8:51       ` Rocco Yue
2021-07-01  8:51         ` Rocco Yue
2021-07-01  8:51         ` Rocco Yue
2021-07-05  5:48         ` Rocco Yue
2021-07-05  5:48           ` Rocco Yue
2021-07-05  5:48           ` Rocco Yue
2021-07-05 16:35         ` David Ahern
2021-07-05 16:35           ` David Ahern
2021-07-05 16:35           ` David Ahern
2021-07-06 12:37           ` Rocco Yue
2021-07-06 12:37             ` Rocco Yue
2021-07-06 12:37             ` Rocco Yue
2021-07-07 14:39             ` David Ahern
2021-07-07 14:39               ` David Ahern
2021-07-07 14:39               ` David Ahern
2021-07-13  1:49               ` Rocco Yue [this message]
2021-07-13  1:49                 ` Rocco Yue
2021-07-13  1:49                 ` Rocco Yue
2021-09-09  6:20           ` Lorenzo Colitti
2021-09-09  6:20             ` Lorenzo Colitti
2021-09-09  6:20             ` Lorenzo Colitti
2021-09-09 19:12             ` David Ahern
2021-09-09 19:12               ` David Ahern
2021-09-09 19:12               ` David Ahern
2021-09-12 15:47               ` Mark Smith
2021-09-12 15:47                 ` Mark Smith
2021-09-12 15:47                 ` Mark Smith
2021-09-13  9:38                 ` Lorenzo Colitti
2021-09-13  9:38                   ` Lorenzo Colitti
2021-09-13  9:38                   ` Lorenzo Colitti
2021-09-13 15:22                   ` Mark Smith
2021-09-13 15:22                     ` Mark Smith
2021-09-13 15:22                     ` Mark Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210713014924.1831-1-rocco.yue@mediatek.com \
    --to=rocco.yue@mediatek.com \
    --cc=chao.song@mediatek.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=dsahern@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=lorenzo@google.com \
    --cc=matthias.bgg@gmail.com \
    --cc=maze@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=rocco.yue@gmail.com \
    --cc=wsd_upstream@mediatek.com \
    --cc=yoshfuji@linux-ipv6.org \
    --cc=zhuoliang.zhang@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.