netdev - Re: [PATCH] ipv4: some rt_iif -> rt_route

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]

Message-Id: <20110811.060110.955532382602835203.davem@davemloft.net>
Date:	Thu, 11 Aug 2011 06:01:10 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	ja@....bg
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] ipv4: some rt_iif -> rt_route_iif conversions

From: Julian Anastasov <ja@....bg>
Date: Tue, 9 Aug 2011 17:01:16 +0300 (EEST)

> 
> 	As rt_iif represents input device even for packets
> coming from loopback with output route, it is not an unique
> key specific to input routes. Now rt_route_iif has such role,
> it was fl.iif in 2.6.38, so better to change the checks at
> some places to save CPU cycles and to restore 2.6.38 semantics.
> 
> compare_keys:
> 	- input routes: only rt_route_iif matters, rt_iif is same
> 	- output routes: only rt_oif matters, rt_iif is not
> 		used for matching in __ip_route_output_key
> 	- now we are back to 2.6.38 state
> 
> ip_route_input_common:
> 	- matching rt_route_iif implies input route
> 	- compared to 2.6.38 we eliminated one rth->fl.oif check
> 	because it was not needed even for 2.6.38
> 
> compare_hash_inputs:
> 	Only the change here is not an optimization, it has
> 	effect only for output routes. I assume I'm restoring
> 	the original intention to ignore oif, it was using fl.iif
> 	- now we are back to 2.6.38 state
> 
> Signed-off-by: Julian Anastasov <ja@....bg>

Applied, thanks a lot for doing these audits.
--
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