All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julian Anastasov <ja@ssi.bg>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, Thomas Graf <tgraf@infradead.org>
Subject: rt_iif conversions (was Re: return of ip_rt_bug())
Date: Thu, 11 Aug 2011 19:36:37 +0300 (EEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.1108111919250.1494@ja.ssi.bg> (raw)
In-Reply-To: <20110811.060057.36747750681761864.davem@davemloft.net>


	Hello,

On Thu, 11 Aug 2011, David Miller wrote:

> From: Julian Anastasov <ja@ssi.bg>
> Date: Tue, 9 Aug 2011 16:51:26 +0300 (EEST)
> 
> > 	There are other places that used fl.iif (0 for output
> > routes) but are now using rt_iif instead of rt_route_iif,
> > not sure if this change is fatal for them because:
> > 
> > - net/sched/cls_route.c, route4_classify() gets optional
> > iif, so it can be 0, may be to match output route? And
> > later route4_classify does exact match for rt_iif. Does
> > it mean that now we can not match output packets without
> > providing "fromif OUTDEV" ?

	It seems the user space for route filter treats
0 as error, so "fromif if0" was never supported. So, using
rt_iif is a better choice here.

> > - net/sched/em_meta.c: now int_rtiif (being rt_iif) is
> > always != 0, may be not good to match output routes?

	May be using 'rt_iif eq 0' is silly for the meta match.
It is preferred to use rt_iif instead of rt_route_iif so that
one can match even packets from loopback.

> > 	In short, the fl.iif -> rt_iif conversion is risky
> > at some places.
> 
> If we convert em_meta.c and cls_route.c to use rt_route_iif
> we should be OK right?  Please patches to do this if so.

	It seems no patches are needed. Sorry for the confusion.

Regards

--
Julian Anastasov <ja@ssi.bg>

  reply	other threads:[~2011-08-11 16:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-02 17:09 return of ip_rt_bug() Dave Jones
2011-08-04  7:23 ` David Miller
2011-08-04 12:20 ` Julian Anastasov
2011-08-04 13:14   ` Tom London
2011-08-04 17:37     ` Julian Anastasov
2011-08-04 17:48       ` Tom London
2011-08-05  2:45         ` Tom London
2011-08-05  7:56           ` Julian Anastasov
2011-08-05 13:18             ` Tom London
2011-08-05 13:30               ` Tom London
2011-08-05 13:37                 ` Tom London
2011-08-06 22:14                   ` Julian Anastasov
2011-08-08  5:20                     ` David Miller
2011-08-09 13:51                       ` Julian Anastasov
2011-08-11 13:00                         ` David Miller
2011-08-11 16:36                           ` Julian Anastasov [this message]
2011-08-12  1:01                             ` rt_iif conversions David Miller
2011-08-05 16:36               ` return of ip_rt_bug() Julian Anastasov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.1108111919250.1494@ja.ssi.bg \
    --to=ja@ssi.bg \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=tgraf@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.