Re: [PATCH v2 2/2] ipv6: fixup RTF_* flags when restoring RTPROT_RA route from rtnetlink

Hello, 

Thanks for the review and feedback, one small clarification below.

On Fri, 19 Aug 2016, Sergei Shtylyov wrote:

Hello.

On 08/19/2016 07:41 PM, Andrew Yourtchenko wrote:

quoted

Fix the flags for RA-derived routes that were saved
via "ip -6 route save" and and subsequently restored via
"ip -6 route restore", allowing the incoming router advertisements
to update them, rather than complain about inability to do so.

Upon the restore of RA-derived saved routes, set the RTF_ADDRCONF
to indicate that the source of the route was originally
a router advertisement, and set the RTF_DEFAULT or RTF_ROUTEINFO
flag depending on prefix length. This can be considered a
sister change of f0396f60d7c165018c9b203fb9b89fb224835578, in

   It's enough to specify 12 digits but you also need to specify the commit
summary enclosed in ("").

Is just the first line of "ipv6: fix RTPROT_RA markup of RA routes 
w/nexthops" enough, or do I need to include the additional two 
paragraphs that follow ? (and can I keep the full hash rather than 
truncate down to 12 digits?)

quoted

the other direction.

Signed-off-by: Andrew Yourtchenko <redacted>
---
Changes since v1 [1]:
 * fixed the indentation of the basic blocks to be always a full TAB
   as per David Miller's review

[1] v1: http://marc.info/?l=linux-netdev&m=147135599322285&w=2

 net/ipv6/route.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index f5b987d..60d95cd 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c

@@ -2769,6 +2769,16 @@ static int rtm_to_fib6_config(struct sk_buff *skb,

struct nlmsghdr *nlh,
 	cfg->fc_protocol = rtm->rtm_protocol;
 	cfg->fc_type = rtm->rtm_type;

+	if (rtm->rtm_protocol == RTPROT_RA) {
+		/* RA-derived route: set flags accordingly. */
+		cfg->fc_flags |= RTF_ADDRCONF;
+		if (rtm->rtm_dst_len == 0) {
+			cfg->fc_flags |= RTF_DEFAULT;
+		} else {
+			cfg->fc_flags |= RTF_ROUTEINFO;
+		}

   {} not needed here and above.

Will fix in v3, thanks!

--a

[...]

MBR, Sergei