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: <cd18410f-7065-ebea-74c5-4c016a3f1436@gmail.com>
Date:   Tue, 18 Feb 2020 18:05:58 -0700
From:   David Ahern <dsahern@...il.com>
To:     Carmine Scarpitta <carmine.scarpitta@...roma2.it>
Cc:     davem@...emloft.net, kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org,
        kuba@...nel.org, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, ahmed.abdelsalam@...i.it,
        dav.lebrun@...il.com, andrea.mayer@...roma2.it,
        paolo.lungaroni@...t.it
Subject: Re: [net-next 1/2] Perform IPv4 FIB lookup in a predefined FIB table

On 2/18/20 4:50 PM, Carmine Scarpitta wrote:
> Indeed both call fib_table_lookup and rt_dst_alloc are exported for modules. 
> However, several functions defined in route.c are not exported:
> - the two functions rt_cache_valid and rt_cache_route required to handle the routing cache
> - find_exception, required to support fib exceptions.
> This would require duplicating a lot of the IPv4 routing code. 
> The reason behind this change is really to reuse the IPv4 routing code instead of doing a duplication. 
> 
> For the fi member of the struct fib_result, we will fix it by initializing before "if (!tbl_known)"

The route.c code does not need to know about the fib table or fib
policy. Why do all of the existing policy options (mark, L3 domains,
uid) to direct the lookup to the table of interest not work for this use
case?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ