From: David Miller <davem@davemloft.net>
To: mkubecek@suse.cz
Cc: netdev@vger.kernel.org, kuznet@ms2.inr.ac.ru, jmorris@namei.org,
yoshfuji@linux-ipv6.org, kaber@trash.net
Subject: Re: [PATCH net] ipv6: do not overwrite inetpeer metrics prematurely
Date: Fri, 07 Mar 2014 15:52:58 -0500 (EST) [thread overview]
Message-ID: <20140307.155258.463380957582451300.davem@davemloft.net> (raw)
In-Reply-To: <20140306200658.GA32699@unicorn.suse.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Thu, 6 Mar 2014 21:06:58 +0100
> On Thu, Mar 06, 2014 at 02:24:25PM -0500, David Miller wrote:
>>
>> > +static void rt6_metrics_to_peer(struct rt6_info *rt)
>> > +{
>> > + struct inet_peer *peer = rt6_has_peer(rt) ? rt6_peer_ptr(rt) : NULL;
>> > + struct dst_entry *dst = &rt->dst;
>> > + unsigned long old = dst->_metrics;
>> > +
>> > + if (!(rt->dst.flags & DST_HOST) || dst_metrics_read_only(dst))
>> > + return;
>> > + if (peer && dst_metrics_ptr(dst) == peer->metrics)
>> > + return;
>> > +
>> > + dst->ops->cow_metrics(dst, old);
>> > + if (dst->_metrics != old) {
>> > + u32 *old_p = __DST_METRICS_PTR(old);
>> > +
>> > + memcpy(dst_metrics_ptr(dst), old_p, RTAX_MAX * sizeof(u32));
>> > + kfree(old_p);
>> > + }
>> > +}
>>
>> Hmmm... if inet_metrics_new() is true then ->cow_metrics() will copy the
>> metrics from old to new. So you therefore shouldn't have to do the copy
>> explicitly here.
>
> If we are replacing an existing host route with metrics, e.g.
>
> ip route add fec0::1 dev eth0 rto_min 1000
> ip route change fec0::1 dev eth0 rto_min 1500
>
> then peer will be the existing inetpeer and inet_metrics_new() will be
> false. However, we still need to copy the new metrics from the netlink
> message over the old ones.
>
>> If inet_metrics_new() is not true, you are overwriting non-new metrics.
>
> The only problem with this is IMHO that if inet_metrics_new() is true,
> i.e. when adding a new route with new inetpeer (or old inetpeer whose
> metrics were not used before), the memcpy() is done twice, once in
> ipv6_cow_metrics() and once in rt6_metrics_to_peer(). We are copying the
> same data twice so that the result is correct but it's not efficient and
> it's not nice.
>
> The only way I can see to avoid this (except using own metrics always
> instead of those in struct inetpeer as we do for non-host routes) would
> be not to call ipv6_cow_metrics() at all and write a special function
> for this purpose in net/ipv6/route.c which would duplicate the parts of
> ipv6_cow_metrics() we really need (and add the free()). Do you think
> this is the way to go?
Thank you for explaining all of this, I would like to think about this
some more.
My initial suspicion is that the something about the test in cow
metrics might need to be adjusted.
The conceptual attributes we have built for inetpeer metrics, that of
"newness" and "read-only", might not be built adequately for the task
at hand here.
next prev parent reply other threads:[~2014-03-07 20:53 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-06 9:50 [PATCH net] ipv6: do not overwrite inetpeer metrics prematurely Michal Kubecek
2014-03-06 19:24 ` David Miller
2014-03-06 20:06 ` Michal Kubecek
2014-03-07 12:36 ` [PATCH net v2] " Michal Kubecek
2014-03-07 20:52 ` David Miller [this message]
2014-03-07 21:38 ` [PATCH net] " Michal Kubecek
2014-03-08 8:34 ` Hannes Frederic Sowa
2014-03-08 8:06 ` Hannes Frederic Sowa
2014-03-10 0:26 ` David Miller
2014-03-10 0:52 ` Hannes Frederic Sowa
2014-03-10 5:03 ` David Miller
2014-03-10 8:15 ` Michal Kubecek
2014-03-10 12:00 ` Hannes Frederic Sowa
2014-03-10 13:15 ` Michal Kubecek
2014-03-11 2:38 ` David Miller
2014-03-11 9:53 ` Michal Kubecek
2014-03-11 15:08 ` Michal Kubecek
2014-03-11 15:20 ` Hannes Frederic Sowa
2014-03-11 15:39 ` Michal Kubecek
2014-03-25 19:11 ` Hannes Frederic Sowa
2014-03-26 15:09 ` Michal Kubecek
2014-03-26 15:42 ` [PATCH net-next v3] " Michal Kubecek
2014-03-26 15:50 ` Hannes Frederic Sowa
2014-03-26 15:56 ` Michal Kubecek
2014-03-26 16:05 ` [PATCH net-next v4] " Michal Kubecek
2014-03-27 5:06 ` Hannes Frederic Sowa
2014-03-27 7:43 ` Michal Kubecek
2014-03-27 12:04 ` [PATCH net-next v5] " Michal Kubecek
2014-03-27 16:30 ` Hannes Frederic Sowa
2014-03-27 19:09 ` David Miller
2014-03-12 20:54 ` [PATCH net] " David Miller
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=20140307.155258.463380957582451300.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.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).