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:	Fri, 23 Mar 2012 15:39:08 -0400
From:	chetan loke <loke.chetan@...il.com>
To:	"Keller, Jacob E" <jacob.e.keller@...el.com>
Cc:	Richard Cochran <richardcochran@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>,
	"john.stultz@...aro.org" <john.stultz@...aro.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>
Subject: Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the
 timecompare method

On Fri, Mar 23, 2012 at 2:27 PM, Keller, Jacob E
<jacob.e.keller@...el.com> wrote:

> However the try_cnt would not work, because of a case where the timecounter is just about to roll over. (So last check was 25 seconds ago.) Then the cyc2time function is called, determines that some RX timestamp is in the 'future'. At this point on another CPU the timecounter_read is run, and updates the nsec value in the timecounter by 25 seconds, and stores the last read timestamp value. Now the cyc2time function uses the 'new' values, but doesn't know to correct for it by using the "in the past" subtraction. Thus, the resulting ns returned by cyc2time would be 25 seconds in the future. This isn't just not accurate, it is very wrong and could throw of PTP calculations.
>

PS: for some reason the line endings were messed up already when I hit
reply to this msg.

So, how is it working today? Because we could have tx and rx
completions on different CPUs. Is it not possible to have the
following race today - between timecompare_update->timecompare_offset
-> timecounter_readdelta of say Rx and timecounter_cyc2time from Tx?



> The solution here is when the try_cnt runs out, drop the timestamp or return 0 as the value. (So that the PTP app knows the timestamp was bad.) However this is introducing more potentially dropped timestamps,  which could be an issue.
>
> I think a better way to solve this problem is throttle the ioctls. Would it be possible to detect users spamming the ioctls and return some sort of 'EBUSY' error? Maybe by using spin_trylock? That would prevent the starvation issues mentioned if a user were to spam set/get/adj in some weird loop, without a potentially dangerous locking scheme.
>
>

I was thinking of caching the tstamp values from the Tx/Rx path () and
also firing a kernel-thread per-driver to update the cached value. So
gettime (ab)users could be taken care off that way by returning the
cached value. But settime/adjtime would still be left.

So yes, rate limiting ioctls seems like a good idea.

How about rate limiting at the PHC class driver level? And then it
will work across the board for all the adapters at the device level.

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