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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgT0UcuvFGJTCxMwVa+rEnQHaNg0V6EH4XpO29fXuFADSBpAQ@mail.gmail.com>
Date:	Fri, 27 Jul 2012 23:41:50 -0700
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH 0/7] Deconstruct struct fib_result

On Fri, Jul 27, 2012 at 9:18 PM, David Miller <davem@...emloft.net> wrote:
>
> This patch set tries to move towards reducing struct fib_result down
> to it's absolute minimum.
>
> The eventual idea is to make it so that fib_lookup() simply
> returns a "struct fib_nh *" and pointer encoded errnos, instead
> of writing into a complicated structure as the return value on
> the stack as is done now.
>
> Signed-off-by: David S. Miller <davem@...emloft.net>

I was wondering why you couldn't wrap the tclassid value in result
with an #ifdef CONFIG_IP_ROUTE_CLASSID so that it is stripped if you
don't have that defined?  I did a quick grep through the kernel and it
seems like there are only a few spots that are accessing it without
the define being checked and most of those are just setting it to 0.

Also is there any specific reason to be passing the trie pointer to
check_leaf?  From what I can tell it looks like that it is just used
for updating the trie stats that are stripped if we want performance,
and the trie pointer should be retrievable via the fib table pointer
if we really wanted it anyway.

Thanks,

Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ