netdev - Re: [PATCHv4 net] ipv6: no need to check rt->dst.error when get route info

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 31 Jul 2017 16:39:14 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     dsahern@...il.com
Cc:     liuhangbin@...il.com, netdev@...r.kernel.org,
        xiyou.wangcong@...il.com, roopa@...ulusnetworks.com
Subject: Re: [PATCHv4 net] ipv6: no need to check rt->dst.error when get
 route info

From: David Ahern <dsahern@...il.com>
Date: Mon, 31 Jul 2017 17:34:09 -0600

> On 7/31/17 5:22 PM, David Miller wrote:
>> From: Hangbin Liu <liuhangbin@...il.com>
>> Date: Fri, 28 Jul 2017 00:25:36 +0800
>> 
>>> After commit 18c3a61c4264 ("net: ipv6: RTM_GETROUTE: return matched fib
>>> result when requested"). When we get a prohibit ertry, we will return
>>> -EACCES directly instead of dump route info.
>>>
>>> Fix it by remove the rt->dst.error check.
>> ...
>>> Fixes: 18c3a61c4264 ("net: ipv6: RTM_GETROUTE: return matched fib...")
>>> Signed-off-by: Hangbin Liu <liuhangbin@...il.com>
>> 
>> David A., where are we on this?
>> 
> 
> Dizzy from running in circles.

:-)

> Question I posed to you Saturday morning, 8:41 MDT [1]:
> 
> "... Roopa's fibmatch patches caused a change in user behavior in IPv6
> getroute for prohibit, blackhole and unreachable route entries. Opinions
> on whether we should limit that new behavior to just the fibmatch lookup
> in which case a patch is needed or take the new behavior and consistency
> in which case nothing is needed?"
> 
> Personally, after all the discussion I think the behavior as it is right
> now is best.
> 
> [1] https://www.spinics.net/lists/netdev/msg446571.html

I agree with you that we should keep the behavior as is.