From: Dan Williams <dcbw@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: lucien.xin@gmail.com, netdev@vger.kernel.org, hannes@stressinduktion.org
Subject: Re: [PATCHv3 net-next] ipv6: allow routes to be configured with expire values
Date: Thu, 17 Dec 2015 14:23:57 -0600 [thread overview]
Message-ID: <1450383837.28806.4.camel@redhat.com> (raw)
In-Reply-To: <20151217.150826.320110242014234511.davem@davemloft.net>
On Thu, 2015-12-17 at 15:08 -0500, David Miller wrote:
> From: Dan Williams <dcbw@redhat.com>
> Date: Wed, 16 Dec 2015 11:03:52 -0600
>
> > On Wed, 2015-12-16 at 17:50 +0800, Xin Long wrote:
> >> Add the support for adding expire value to routes, requested by
> >> Tom Gundersen <teg@jklm.no> for systemd-networkd, and
> NetworkManager
> >> wants it too.
> >>
> >> implement it by adding the new RTNETLINK attribute RTA_EXPIRES.
> >
> > Could you also add bits to send RTA_EXPIRES back to userspace in
> the
> > route dump in rt6_fill_node(), so that userspace can figure out
> when
> > RTA_EXPIRES is supported or not?
> >
> > (obviously having it there isn't foolproof as if there are no
> routes on
> > the system yet userspace can't figure out support, but it's better
> than
> > nothing...)
>
> That brings up an interesting issue, and I do not agree that we
> should
> publish the value for the purpose of determining if the kernel
> supports
> it or not.
That said, userspace still needs to read back the EXPIRES attribute, if
only for iproute. The program setting RTA_EXPIRES isn't the only thing
that wants to know about the route's details.
> We need to come up with a policy for handling unknown attributes
> because what we do now doesn't work.
Definitely agree.
> I'm almost positive that the right thing to do is to unilaterally
> making nlmsg_parse() error out on out-of-range attribute type
> numbers,
> and then backport that to all -stable branches.
This works for one attribute because then userspace gets an error like
EOPNOTSUPP or something. But which attribute caused it? Does
userspace then have to retry the operation a couple times with all the
different combinations of potentially unsupported options?
If we're going to error out on unrecognized options, I'd really like to
see some kind of netlink features bitmap or something that positively
indicates which options the kernel will accept.
Dan
next prev parent reply other threads:[~2015-12-17 20:23 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 9:50 [PATCHv3 net-next] ipv6: allow routes to be configured with expire values Xin Long
2015-12-16 11:19 ` Hannes Frederic Sowa
2015-12-16 17:03 ` Dan Williams
2015-12-17 20:08 ` David Miller
2015-12-17 20:23 ` Dan Williams [this message]
2015-12-17 20:32 ` Hannes Frederic Sowa
2015-12-17 21:26 ` David Miller
2015-12-17 20:09 ` 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=1450383837.28806.4.camel@redhat.com \
--to=dcbw@redhat.com \
--cc=davem@davemloft.net \
--cc=hannes@stressinduktion.org \
--cc=lucien.xin@gmail.com \
--cc=netdev@vger.kernel.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.