netdev - Re: [RESEND] [NET] fib_rules: Flush route cache after rule modifications

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: <20070329100326.GA1772@ff.dom.local>
Date:	Thu, 29 Mar 2007 12:03:26 +0200
From:	Jarek Poplawski <jarkao2@...pl>
To:	Thomas Graf <tgraf@...g.ch>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	muli@...ibm.com
Subject: Re: [RESEND] [NET] fib_rules: Flush route cache after rule modifications

On Wed, Mar 28, 2007 at 09:34:36PM +0200, Thomas Graf wrote:
> * David Miller <davem@...emloft.net> 2007-03-28 11:24
> > Another idea Thomas and I tossed around was to have some kind of way
> > for the rule insertion to indicate that the flush should be deferred
> > and I kind of prefer that explicitness.
> 
> Right, although I believe the flag should not only defer it
> but not flush at all. This would be the optimal solution
> for scripts which can do a ip ro flush cache as they know
> what they're doing.
> 
> > By default it's better the flush immediately, because the old
> > behavior is totally unexpected.  "I insert a rule and it dosn't
> > show up?", nobody expects that.
> 
> It's a tough call, I'd favour immediate flush as well but I can
> see the point in delaying by ip_rt_min_delay which can be
> configured by the user. So people can choose to immediately flush
> by setting it to 0. It would also be consistent to the flush
> after route changes, the same delay is used there.
> 

Of course you both are right - but (...I've some doubts):

- there is a difference between tools: route or ip route
(as a successor) and ip rule; the latter is intended for
advanced things, so users have to expect... (or RTFM!).
 
- of course immediate flush seems to be more natural, but
it isn't like that and rules (other rules) are changed,
so maybe some transitory way is needed; these 2s look
like a good compromise, but after looking into
rt_cache_flush - it's not for all (I know - we don't like
multipath - but untill it's here...) and these locks and
timers aren't for free, too; so, IMHO, something like
-n[oflush] option is a mustbe.

- for consistency probably all ip "objects" should be
verified: "to flush or not to flush" by default.

Cheers,
Jarek P.
-
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