From: Marcelo Ricardo Leitner <mleitner@redhat.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
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>,
lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] ipvs: prevent some underflows
Date: Tue, 09 Jun 2015 12:26:30 +0000 [thread overview]
Message-ID: <20150609122630.GA4060@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.11.1506082137420.1552@ja.home.ssi.bg>
Hi,
On Mon, Jun 08, 2015 at 10:16:23PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Fri, 5 Jun 2015, Dan Carpenter wrote:
>
> > @@ -1363,7 +1363,8 @@ static int set_sync_mesg_maxlen(struct net *net, int sync_state)
>
> May be we should use min(dev->mtu, 1500) instead of
> dev->mtu to avoid sending too large packets for the common
> case.
That will put an upper limit on it, no? If the load balancers share a
big MTU, why not use it?
Thanks,
Marcelo
> > sizeof(struct udphdr) -
> > SYNC_MESG_HEADER_LEN - 20) / SIMPLE_CONN_SIZE;
> > ipvs->send_mesg_maxlen = SYNC_MESG_HEADER_LEN +
> > - SIMPLE_CONN_SIZE * min(num, MAX_CONNS_PER_SYNCBUFF);
> > + SIMPLE_CONN_SIZE * min_t(uint, num,
> > + MAX_CONNS_PER_SYNCBUFF);
>
> ipvs->send_mesg_maxlen = max(min(dev->mtu, 1500) -
> sizeof(struct iphdr) - sizeof(struct udphdr),
> /* Some new const is needed here: */
> 2 * FULL_CONN_SIZE);
>
> And may be we should add more correct checks in
> ip_vs_sync_conn() in case dev->mtu was changed after thread
> start. Currently, it is assumed that fresh new buffer from
> ip_vs_sync_buff_create() will have space for at least one
> message... We can even set inet->pmtudisc to IP_PMTUDISC_DONT
> so that packets can be fragmented for too small MTU.
>
> > IP_VS_DBG(7, "setting the maximum length of sync sending "
> > "message %d.\n", ipvs->send_mesg_maxlen);
> > } else if (sync_state = IP_VS_STATE_BACKUP) {
> > @@ -1371,8 +1372,11 @@ static int set_sync_mesg_maxlen(struct net *net, int sync_state)
> > if (!dev)
> > return -ENODEV;
> >
> > - ipvs->recv_mesg_maxlen = dev->mtu -
> > - sizeof(struct iphdr) - sizeof(struct udphdr);
> > + if (dev->mtu < sizeof(struct iphdr) + sizeof(struct udphdr))
> > + ipvs->recv_mesg_maxlen = 0;
> > + else
> > + ipvs->recv_mesg_maxlen = dev->mtu -
> > + sizeof(struct iphdr) - sizeof(struct udphdr);
>
> May be ipvs->recv_mesg_maxlen = max(dev->mtu, 1500);
> This is single buffer allocated when backup starts...
>
> > IP_VS_DBG(7, "setting the maximum length of sync receiving "
> > "message %d.\n", ipvs->recv_mesg_maxlen);
> > }
> >
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
> --
> To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <mleitner@redhat.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
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>,
lvs-devel@vger.kernel.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org, kernel-janitors@vger.kernel.org
Subject: Re: [patch] ipvs: prevent some underflows
Date: Tue, 9 Jun 2015 09:26:30 -0300 [thread overview]
Message-ID: <20150609122630.GA4060@localhost.localdomain> (raw)
In-Reply-To: <alpine.LFD.2.11.1506082137420.1552@ja.home.ssi.bg>
Hi,
On Mon, Jun 08, 2015 at 10:16:23PM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Fri, 5 Jun 2015, Dan Carpenter wrote:
>
> > @@ -1363,7 +1363,8 @@ static int set_sync_mesg_maxlen(struct net *net, int sync_state)
>
> May be we should use min(dev->mtu, 1500) instead of
> dev->mtu to avoid sending too large packets for the common
> case.
That will put an upper limit on it, no? If the load balancers share a
big MTU, why not use it?
Thanks,
Marcelo
> > sizeof(struct udphdr) -
> > SYNC_MESG_HEADER_LEN - 20) / SIMPLE_CONN_SIZE;
> > ipvs->send_mesg_maxlen = SYNC_MESG_HEADER_LEN +
> > - SIMPLE_CONN_SIZE * min(num, MAX_CONNS_PER_SYNCBUFF);
> > + SIMPLE_CONN_SIZE * min_t(uint, num,
> > + MAX_CONNS_PER_SYNCBUFF);
>
> ipvs->send_mesg_maxlen = max(min(dev->mtu, 1500) -
> sizeof(struct iphdr) - sizeof(struct udphdr),
> /* Some new const is needed here: */
> 2 * FULL_CONN_SIZE);
>
> And may be we should add more correct checks in
> ip_vs_sync_conn() in case dev->mtu was changed after thread
> start. Currently, it is assumed that fresh new buffer from
> ip_vs_sync_buff_create() will have space for at least one
> message... We can even set inet->pmtudisc to IP_PMTUDISC_DONT
> so that packets can be fragmented for too small MTU.
>
> > IP_VS_DBG(7, "setting the maximum length of sync sending "
> > "message %d.\n", ipvs->send_mesg_maxlen);
> > } else if (sync_state == IP_VS_STATE_BACKUP) {
> > @@ -1371,8 +1372,11 @@ static int set_sync_mesg_maxlen(struct net *net, int sync_state)
> > if (!dev)
> > return -ENODEV;
> >
> > - ipvs->recv_mesg_maxlen = dev->mtu -
> > - sizeof(struct iphdr) - sizeof(struct udphdr);
> > + if (dev->mtu < sizeof(struct iphdr) + sizeof(struct udphdr))
> > + ipvs->recv_mesg_maxlen = 0;
> > + else
> > + ipvs->recv_mesg_maxlen = dev->mtu -
> > + sizeof(struct iphdr) - sizeof(struct udphdr);
>
> May be ipvs->recv_mesg_maxlen = max(dev->mtu, 1500);
> This is single buffer allocated when backup starts...
>
> > IP_VS_DBG(7, "setting the maximum length of sync receiving "
> > "message %d.\n", ipvs->recv_mesg_maxlen);
> > }
> >
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
> --
> To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2015-06-09 12:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-05 9:33 [patch] ipvs: prevent some underflows Dan Carpenter
2015-06-05 9:33 ` Dan Carpenter
2015-06-08 19:16 ` Julian Anastasov
2015-06-08 19:16 ` Julian Anastasov
2015-06-09 12:26 ` Marcelo Ricardo Leitner [this message]
2015-06-09 12:26 ` Marcelo Ricardo Leitner
2015-06-11 5:18 ` Julian Anastasov
2015-06-11 5:18 ` Julian Anastasov
2015-06-11 12:57 ` Marcelo Ricardo Leitner
2015-06-11 12:57 ` Marcelo Ricardo Leitner
2015-06-11 13:17 ` Dan Carpenter
2015-06-11 13:17 ` Dan Carpenter
2015-06-16 19:28 ` Julian Anastasov
2015-06-16 19:28 ` Julian Anastasov
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=20150609122630.GA4060@localhost.localdomain \
--to=mleitner@redhat.com \
--cc=coreteam@netfilter.org \
--cc=dan.carpenter@oracle.com \
--cc=davem@davemloft.net \
--cc=horms@verge.net.au \
--cc=ja@ssi.bg \
--cc=kaber@trash.net \
--cc=kadlec@blackhole.kfki.hu \
--cc=kernel-janitors@vger.kernel.org \
--cc=lvs-devel@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
--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 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.