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: <20070328193436.GP521@postel.suug.ch>
Date:	Wed, 28 Mar 2007 21:34:36 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	David Miller <davem@...emloft.net>
Cc:	jarkao2@...pl, netdev@...r.kernel.org, muli@...ibm.com
Subject: Re: [RESEND] [NET] fib_rules: Flush route cache after rule modifications

* 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.
-
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