netdev - Re: [PATCH 2/3 Rev4] Initilize and populate age field

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: <20070930.174154.39184307.davem@davemloft.net>
Date:	Sun, 30 Sep 2007 17:41:54 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	varunc@...ux.vnet.ibm.com
Cc:	netdev@...r.kernel.org, kaber@...sh.net, socketcan@...tkopp.net,
	shemminger@...ux-foundation.org, krkumar2@...ibm.com,
	tgraf@...g.ch, varuncha@...ibm.com
Subject: Re: [PATCH 2/3 Rev4] Initilize and populate age field

From: Varun Chandramohan <varunc@...ux.vnet.ibm.com>
Date: Thu, 20 Sep 2007 20:57:51 +0530

> @@ -420,6 +421,7 @@ static int fn_hash_insert(struct fib_tab
>  	else
>  		fa = fib_find_alias(&f->fn_alias, tos, fi->fib_priority);
>  
> +	do_gettimeofday(&tv);
>  	/* Now fa, if non-NULL, points to the first fib alias
>  	 * with the same keys [prefix,tos,priority], if such key already
>  	 * exists or to the node before which we will insert new one.

gettimeofday() is expensive, we don't even use it to timestamp every
incoming packet and we therefore should not do it every route cache
entry we create in order to handle DoS situations efficiently

I honestly don't like these patches.  I literally cringe every time
you post a new revision.  It's either going to add new costs to route
management or be so inaccurate as to be useless.

I question it's usefulness even if implemented efficiently and
accurately.  I really don't see people lining up asking for a route
aging metric.

We could report zero and be compliant with the RFC, we don't age our
route entries like the model of the SNMP vars seems to suggest, so
it's honestly accurate.  And this would mean no kernel changes, as the
userland program could just report zero in the absense of a kernel
provided value.
-
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