Re: replace microtime with getmicrouptime in ip_mroute.c

2016-09-08 Thread Florian Obser
OK florian@

On Thu, Sep 08, 2016 at 11:54:01AM +1000, David Gwynne wrote:
> it uses the time to rate limit the sending of assertion messages.
> 
> there are two reasons for this change.
> 
> firstly, using uptime instead of wall time means the intervals will
> be measured against a a monotonic clock that isnt skewed by clock
> changes. it should therefore always be rate limited to 30 seconds,
> even if the clock jumps in the middle of that interval.
> 
> secondly, using the get variant of the api means it can use a cached clock 
> time at the expense of accuracy. accuracy between 30s intervals isnt 
> necessary in this use case, but making it use the faster clock read is good 
> cos this path is in response to packets, so it will mitigate a DoS.
> 
> ok?
> 
> after this i intend to tweak the code to use ratecheck().
> 
> Index: ip_mroute.c
> ===
> RCS file: /cvs/src/sys/netinet/ip_mroute.c,v
> retrieving revision 1.90
> diff -u -p -r1.90 ip_mroute.c
> --- ip_mroute.c   7 Mar 2016 18:44:00 -   1.90
> +++ ip_mroute.c   8 Sep 2016 01:49:05 -
> @@ -1482,7 +1482,7 @@ ip_mdq(struct mbuf *m, struct ifnet *ifp
>   return (0);
>   }
>  
> - microtime();
> + getmicrouptime();
>  
>   TV_DELTA(rt->mfc_last_assert, now, delta);
>  
> 

-- 
I'm not entirely sure you are real.



Re: replace microtime with getmicrouptime in ip_mroute.c

2016-09-07 Thread Claudio Jeker
On Thu, Sep 08, 2016 at 11:54:01AM +1000, David Gwynne wrote:
> it uses the time to rate limit the sending of assertion messages.
> 
> there are two reasons for this change.
> 
> firstly, using uptime instead of wall time means the intervals will
> be measured against a a monotonic clock that isnt skewed by clock
> changes. it should therefore always be rate limited to 30 seconds,
> even if the clock jumps in the middle of that interval.
> 
> secondly, using the get variant of the api means it can use a cached clock 
> time at the expense of accuracy. accuracy between 30s intervals isnt 
> necessary in this use case, but making it use the faster clock read is good 
> cos this path is in response to packets, so it will mitigate a DoS.
> 
> ok?

OK claudio@
 
> after this i intend to tweak the code to use ratecheck().
> 
> Index: ip_mroute.c
> ===
> RCS file: /cvs/src/sys/netinet/ip_mroute.c,v
> retrieving revision 1.90
> diff -u -p -r1.90 ip_mroute.c
> --- ip_mroute.c   7 Mar 2016 18:44:00 -   1.90
> +++ ip_mroute.c   8 Sep 2016 01:49:05 -
> @@ -1482,7 +1482,7 @@ ip_mdq(struct mbuf *m, struct ifnet *ifp
>   return (0);
>   }
>  
> - microtime();
> + getmicrouptime();
>  
>   TV_DELTA(rt->mfc_last_assert, now, delta);
>  
> 

-- 
:wq Claudio