netdev - Re: [PATCH net-next 2/9] net: Remove e_inval label from ip_route_input

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: <5602DDC1.2080403@cumulusnetworks.com>
Date:	Wed, 23 Sep 2015 11:13:37 -0600
From:	David Ahern <dsa@...ulusnetworks.com>
To:	Alexander Duyck <alexander.duyck@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 2/9] net: Remove e_inval label from
 ip_route_input_slow

On 9/23/15 10:31 AM, Alexander Duyck wrote:
>
> Just as you said, that code would be an intermediate step.  Going though
> and adding more points where you are updating err and just exchanging
> one jump label for another doesn't help anything.  You are better off
> pulling apart the spaghetti right from the start and then rearranging
> the code.  If nothing else it helps to make things more readable.
>
> In a couple of patches from here you are going to have to pull out the
> local_input helper.  Rather than adding a new jump label inside of it
> for out you could save yourself a few steps and just return the error
> values.  If you do this correctly what you should end up with is a
> series of functions that all converge on one end point anyway.
>
> Also as far as the multiple returns issue it isn't much of a problem
> since ip_output_input_slow ends up being compiled into
> ip_route_input_noref anyway.  As such the return statements end up just
> being jumps to the bits for the rcu_read_unlock and returning the error
> value.

I chose this series of steps because it is easy to follow each change to 
ensure I do not introduce bugs with the patches. Small, focused changes 
to evolve the code.

The first 3 patches appear to have *zero* impact on what the compiler 
generates.

Do you object to the end result of this patch series? ie. do you have 
concerns about what the end code looks like?
--
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