netdev - Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method

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]

Date:	Wed, 21 Mar 2012 11:00:59 -0400
From:	chetan loke <loke.chetan@...il.com>
To:	Richard Cochran <richardcochran@...il.com>
Cc:	netdev@...r.kernel.org, e1000-devel@...ts.sourceforge.net,
	jacob.e.keller@...el.com, jeffrey.t.kirsher@...el.com,
	john.ronciak@...el.com, john.stultz@...aro.org, tglx@...utronix.de
Subject: Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the
 timecompare method

On Fri, Mar 16, 2012 at 2:55 AM, Richard Cochran
<richardcochran@...il.com> wrote:
> On Thu, Mar 15, 2012 at 01:18:26PM -0400, chetan loke wrote:
>>
>> 1) how can I use igb->PHC to set/discipline my system time?
>>  a) clock_gettime(IGB_CLK_ID...);
>>  b) clock_settime(REAL_TIME,...) ? Good/bad idea?
>
> This is a very crude method, and it will cause frequent jumps in your
> system clock.

Of course it's crude :). I wanted to make sure if my understanding was correct.

>> 4) possible contention on tmreg_lock?
>> I will read previous emails/patches shortly but I was thinking - what
>> if there are many readers who would like to use PHC as reference time?
>> Then do we want them to block the driver who wants to time-stamp the
>> packet?
>>  igb_gettime->spin_lock::tmreg_lock         <---contention--->  driver
>> ->igb_systim_to_hwtstamp->spin_lock::tmreg_lock
>
> Under normal use cases, I would not expect much contention at all.
>

Once PHC->gettime goes live(aka exported to user space), we can't
really control how users will use it in their applications. There
could be 100+ apps all trying to get real-time from the network to do
some time-keeping stuff. They might pound the ioctls at high rate. The
last thing we would want is to self-induce a light weight DOS. What
Eric Dumazet mentioned in the very first patch set seems like a good
comment. seqlock or whatever it is we use for jiffies.
We shouldn't let get_time block network traffic under cases when there
is high load and large number of threads are pounding get-time.
Reader's *must* wait.

reminder to myself: once this patch is applied, tpacket_v3 will
break(not because of spinlock but in general) under specific
conditions. Fix tpacket_v3.

> HTH,
>
> Richard

Chetan
--
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