linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Julian Anastasov <ja@ssi.bg>
To: Quentin Armitage <quentin@armitage.org.uk>
Cc: Wensong Zhang <wensong@linux-vs.org>,
	Simon Horman <horms@verge.net.au>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	Patrick McHardy <kaber@trash.net>,
	Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org, lvs-devel@vger.kernel.org,
	netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/5] ipvs: fix backup sync daemon with IPv6, and minor updates
Date: Wed, 15 Jun 2016 22:52:22 +0300 (EEST)	[thread overview]
Message-ID: <alpine.LFD.2.11.1606152209001.1950@ja.home.ssi.bg> (raw)
In-Reply-To: <1465978975.2737.264.camel@samson1.armitage.org.uk>


	Hello,

On Wed, 15 Jun 2016, Quentin Armitage wrote:

> I am updating the patches in line with your comments, but I'm not sure about
> a couple of points.
> 
> Patch 4:
> 
> You state that before bind(), such changes should be safe. However, from the
> function make_send_sock(), when the functions set_mcast_if(),
> set_mcast_loop(), set_mcast_ttl() and set_mcast_pmtudisc() are called before
> connect(), they all lock the socket before modifying it. Patch 4 was
> intended to make the setting of REUSE consistent.
> 
> If the locking is not necessary, would it be better to remove the locks from
> the set_mcast_...() functions referred to above.

	This is a slow path, so it does not matter much.
There is no concurrent access to the socket, the only
risk is some call into the stack that checks with lockdep
for the missing lock. Such example but for another lock
we already hold is ASSERT_RTNL in ip_mc_join_group. But for simple
sk vars lock is not needed. You can safely remove locks before
connect/bind if only sk fields are accessed directly.
We can keep it only in join_mcast_group*(), especially
because they are called after bind().

> Re patch 1 setting 'sock->sk->sk_bound_dev_if = ifindex;', I presume the
> locking should be consistent with what is done in the other functions.

	It is a simple var, so it can work without lock.

> Your comments on the above would be really helpful.
> 
> Patch 5:
> 
> You state 'The indentation of existing pr_info in both cases should not be
> changed". I'm not clear exactly what that means. Does it mean that the
> spaces at the beginning of the pr_info() strings which report group, port
> and ttl should be removed?

	No, here is example from your patch:

        pr_info("sync thread started: state = MASTER, mcast_ifn = %s, "
-               "syncid = %d, id = %d\n",
-               ipvs->mcfg.mcast_ifn, ipvs->mcfg.syncid, tinfo->id);
+                       "syncid = %d, id = %d, maxlen = %d\n",
+                       ipvs->mcfg.mcast_ifn, ipvs->mcfg.syncid,
+                       tinfo->id, ipvs->mcfg.sync_maxlen);

	"syncid = " was at the same column as "sync thread started",
you added another tab, may be to align with the args in new pr_info.
The result is:

	pr_info("sync thread started: state = MASTER, mcast_ifn = %s, "
			"syncid = %d, id = %d, maxlen = %d\n",
			ipvs->mcfg.mcast_ifn, ipvs->mcfg.syncid,
			tinfo->id, ipvs->mcfg.sync_maxlen);
	<--- 2 TABs --->

	But it should be:

	pr_info("sync thread started: state = MASTER, mcast_ifn = %s, "
		"syncid = %d, id = %d, maxlen = %d\n",
		ipvs->mcfg.mcast_ifn, ipvs->mcfg.syncid,
		tinfo->id, ipvs->mcfg.sync_maxlen);
	< 1 TAB>

	Also, the new pr_info calls exceed 80 columns.
May be you can reduce the many spaces.

Regards

--
Julian Anastasov <ja@ssi.bg>

  parent reply	other threads:[~2016-06-15 19:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-14 14:24 [PATCH v2 0/5] ipvs: fix backup sync daemon with IPv6, and minor updates Quentin Armitage
2016-06-14 14:24 ` [PATCH v2 1/5] ipvs: Enable setting IPv6 multicast address for ipvs sync daemon backup Quentin Armitage
2016-06-14 14:24 ` [PATCH v2 2/5] ipvs: Stop calling __dev_get_by_name() repeatedly when starting sync daemon Quentin Armitage
2016-06-14 14:24 ` [PATCH v2 3/5] ipvs: Don't check result < 0 after setting result = 0 Quentin Armitage
2016-06-14 14:24 ` [PATCH v2 4/5] ipvs: Lock socket before setting SK_CAN_REUSE Quentin Armitage
2016-06-14 14:24 ` [PATCH v2 5/5] ipvs: log additional sync daemon parameters Quentin Armitage
2016-06-15  5:21 ` [PATCH v2 0/5] ipvs: fix backup sync daemon with IPv6, and minor updates Julian Anastasov
     [not found]   ` <1465978975.2737.264.camel@samson1.armitage.org.uk>
2016-06-15 19:52     ` Julian Anastasov [this message]
2016-06-15 21:42 ` [PATCH v3 0/4] " Quentin Armitage
2016-06-15 21:42   ` [PATCH v3 1/4] ipvs: Enable setting IPv6 multicast address for ipvs Quentin Armitage
2016-06-15 21:42   ` [PATCH v3 2/4] ipvs: Stop calling __dev_get_by_name() repeatedly when starting sync daemon Quentin Armitage
2016-06-15 21:42   ` [PATCH v3 3/4] ipvs: Don't check result < 0 after setting result = 0 Quentin Armitage
2016-06-15 21:42   ` [PATCH v3 4/4] ipvs: log additional sync daemon parameters Quentin Armitage
2016-06-16  6:17   ` [PATCH v3 0/4] ipvs: fix backup sync daemon with IPv6, and minor updates Julian Anastasov
     [not found] <Message-id: <alpine.LFD.2.11.1606160912380.2490@ja.home.ssi.bg>
2016-06-16  7:00 ` [PATCH v4 net] ipvs: fix bind to link-local mcast IPv6 address in backup Quentin Armitage
2016-06-17  6:42   ` Julian Anastasov
2016-06-23  1:27     ` Simon Horman
2016-06-16  7:00 ` [PATCH net-next v4 1/3] ipvs: Stop calling __dev_get_by_name() repeatedly when starting sync daemon Quentin Armitage
2016-06-16  7:00   ` [PATCH net-next v4 2/3] ipvs: Don't check result < 0 after setting result = 0 Quentin Armitage
2016-06-16  7:00   ` [PATCH net-next v4 3/3] ipvs: log additional sync daemon parameters Quentin Armitage

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=alpine.LFD.2.11.1606152209001.1950@ja.home.ssi.bg \
    --to=ja@ssi.bg \
    --cc=coreteam@netfilter.org \
    --cc=davem@davemloft.net \
    --cc=horms@verge.net.au \
    --cc=kaber@trash.net \
    --cc=kadlec@blackhole.kfki.hu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lvs-devel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=quentin@armitage.org.uk \
    --cc=wensong@linux-vs.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).