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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f1e0a300-b4f1-edcb-5e00-2762609d5582@gmail.com>
Date:   Mon, 31 Jul 2017 17:34:09 -0600
From:   David Ahern <dsahern@...il.com>
To:     David Miller <davem@...emloft.net>, liuhangbin@...il.com
Cc:     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

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