Hello,

On Wed, 30 May 2007, KOVACS Krisztian wrote:

  I'm just about to publish the next round of tproxy patches (with the 
routing code modifications completely removed), but this issue is still 
present.

  I've posted a few patches making omitting this check possible 
selectively back in March. Do those changes look acceptable?

  http://marc.info/?l=linux-netdev&m=117310979823297&w=3

	Just a small note for now:

	The code
	'if (dev_out == NULL && !(oldflp->flags & FLOWI_FLAG_TRANSPARENT))'
can lead to problem in 'fl.oif = dev_out->ifindex;' if fl4_src is not
present.

	Also, i'm not sure if FLOWI_FLAG_TRANSPARENT should cause
different values for flags to be cached many times. Users without this
flag get EINVAL when fl4_src is not configured, other failures are not 
cached too. And as fl4_src is considered in both cases (both kinds of 
callers get same path on success) we don't need changes except in 
ip_route_output_slow()? By this way I hope we can avoid any possible 
forking of cache entries just by different flags.

	Then we can use some more generic name, only for the flowi flag,
eg. FLOWI_FLAG_ANYSRC or something better?