Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 1/1] ipv6: Add sockopt IPV6_MULTICAST_ALL analogue to
 IP_MULTICAST_ALL
To:     =?UTF-8?Q?Maciej_=c5=bbenczykowski?= <maze@google.com>
Cc:     Linux NetDev <netdev@vger.kernel.org>,
        Kernel hackers <linux-kernel@vger.kernel.org>,
        "David S. Miller" <davem@davemloft.net>, kuznet@ms2.inr.ac.ru,
        Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Erik Kline <ek@google.com>,
        Thomas Gleixner <tglx@linutronix.de>, Shaohua Li <shli@fb.com>,
        Kate Stewart <kstewart@linuxfoundation.org>,
        Philippe Ombredanne <pombredanne@nexb.com>
References: <20180910082715.11506-1-nautsch2@gmail.com>
 <20180910082715.11506-2-nautsch2@gmail.com>
 <CANP3RGfGkH33mYDrenwWVkQ4uG4qyrddA+yvJ+t+=y6wGd7uDA@mail.gmail.com>
From:   Andre Naujoks <nautsch2@gmail.com>
Openpgp: preference=signencrypt
Autocrypt: addr=nautsch2@gmail.com; prefer-encrypt=mutual; keydata=
 mQENBEuVIO4BCADaPWxLdKao/quVbf1+wVSuDMf1tJmEpeEZ6qojmlR/5vcTj+me6c5UvBSr
 wBckL0EK/JdzZMVwny1oFfAjTgO252A7Mn1Q+ss8w4RJBI6YnpeAlQIyNm7UTN2wUCY90ObO
 z019BQs3BpQ7iHG2cUWy0KunRMj6dOIGvMKCpETyI83R5annZAR0+5ZhcCB3embvKzRySf7/
 YfAXXBGYkMV9ND7r66BECmDVH/MHTENCqMOvbfVOCKwj1JdVYx/WUqLd48flZ6sx/Psfp/r1
 mY1sN0yebElCkUNzOWonqlgr5kwMZh0+lD1DSQnNhdH2FL5Vvo8qbQ/WTdJd1Equ5BejABEB
 AAG0IkFuZHJlIE5hdWpva3MgPG5hdXRzY2gyQGdtYWlsLmNvbT6JATgEEwECACIFAlO0ExIC
 GwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEFjpxyF47AzYIPEH/jTWaF3CnPugN3CI
 6AfbNP6T46tpDZ1e4QuWBZdFY2eBfDkajfWtqoLCqU7xctmkcuRtFULHnMZwu0dUAXVExlMi
 VYRTLCLYWzFrZ26P7KIudHFyb8XWSh/HTEdahRv4JKscR66kHzM4jdYeKJCud18+gxepPvPi
 7X6sJvA4JlFnomIjW4UHJByif0LRR47KOtOQD5oVon7urSE+K2ib2BqgFIy8o7+laq3/KKhI
 92/ZnNBX/KoZVChFkBCSJEKmaLQCQdCnjXDx+nz6wJT3JYF1FkrGx49An/yTHlEv3nwwDLFF
 0Ff24e/E9PpQ4lIupfqWMfgYhNCbMe2mScwZoWi5AQ0ES5Ug7gEIAMexJPQTFF+ENQxNHFGU
 dw/vq19odo/iB6CgoySTxO28FCbh00Yo/Xw9/CZgKaLxsBuA+Wie1t/MEN/6/pNVpOaTqc7O
 fR4oSbRIsthSHUAQYPAo+bES7jBu+uIO8WNWk2B6sqb2JgS104yHKtlmeZP7+VhEe1nekTkv
 i2ASyywgwkH4dFrMjjkYCt6tTqE7QDRrMmrx6NW31nOjLKSA2Nst3o62b1Z0D+YZeVUspytz
 rAuuv0bKT5GH0zsc9+yNtOYLvkmVhi4x3VW0CD0aLsIq7E9kellZ0oRh4xT9ObuAstI1mG1Q
 yAufU8LZyPRjLVcqrNzemekB59w3gmcMmKEAEQEAAYkBHwQYAQIACQUCS5Ug7gIbDAAKCRBY
 6ccheOwM2KXwCAC3D+3yvZwBycTofZ60G7xvdp2NYBZOszVRFvZK5JRsoI7tNTF635BPJ1Sd
 1Pv/FFt5FUSt/Fv7G9ibunh8He2cbcA5TjwbihhxNT1yAWd6pPKgNlUDMPlHYLBTHq5vwIDz
 3WVq651ihMFwJ9MSSLUbo5PyUpvMEVHPcChUD+nKNufI4/Y7Ob4I90nXgHB3OUXbmOcwZ9+S
 YpcJso4jCmjGBOcaOKZHCN+OX2r4nzE+vMDGWephhg5d8HLxFFDiD+Buw2SsOVxH1qXhG8nk
 AGjD/Q5oL3gtVPTrPh0XTk3JN3LLFOddMQ8oZcuIAh+4aLlGEmK+L5RPAbcigApJNjcZ
Message-ID: <5532db3d-5387-8347-e017-6443d0096d08@gmail.com>
Date:   Mon, 10 Sep 2018 11:30:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <CANP3RGfGkH33mYDrenwWVkQ4uG4qyrddA+yvJ+t+=y6wGd7uDA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 9/10/18 11:07 AM, Maciej Żenczykowski wrote:
> Any reason not to use the same bit that is used by ipv4?
> (as in add the setsockopt/getsockopt but just toggle the v4 bit)
> 

I wanted to keep the current behavior for an ipv6 socket as is. I think
user space api/behavioral changes are frowned upon!?

Currently the bit is settable for an ipv6 socket and changes the
handling for ipv4 multicasts for that socket. If I had just added the
socket option and set the v4 bit, you would get maybe unexpected
behavior from that, if you used it for ipv4 multicasts.

Another approach I tried, was to just honor the v4 bit in v6 context,
like this:

diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 4ae54aaca373..af1659327d46 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@ -636,7 +636,7 @@ bool inet6_mc_check(struct sock *sk, const struct
in6_addr *mc_addr,
 	}
 	if (!mc) {
 		rcu_read_unlock();
-		return true;
+		return inet_sk(sk)->mc_all;
 	}
 	read_lock(&mc->sflock);
 	psl = mc->sflist;


But that has the same problem of changing current behavior in a possibly
unexpected way.

Regards
  Andre