netdev - Re: [net-next 5/6] igb: fix timecompare

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 14 Oct 2011 11:26:46 +0200
From:	Richard Cochran <richardcochran@...il.com>
To:	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Cc:	davem@...emloft.net, Jacob Keller <jacob.e.keller@...el.com>,
	netdev@...r.kernel.org, gospo@...hat.com, sassmann@...hat.com
Subject: Re: [net-next 5/6] igb: fix timecompare_upate race condition

On Thu, Oct 13, 2011 at 11:21:27PM -0700, Jeff Kirsher wrote:
> From: Jacob Keller <jacob.e.keller@...el.com>
> 
> This patch closes a possible race condition when timestamping using
> the timecompare_update function as a method to detect clock skew of
> the internal cycle counter. Because timecompare_update usually allows
> skew detection no more than once a second, if ptpd or other software
> performs a clock offset (for example, using the "date" command), there
> is a small window of time where the clock skew will not match the
> current kernel wall time. This patch forces the timecompare_update to
> calculate skew every time we timestamp a packet, which removes the
> possibility of this race condition.

NAK.

What will happen when you use the card for the telecom profile?

In that case you can expect 32 sync packets per second (plus delay
requests times number of clients).

A better way is to remove the timecompare stuff and offer a PTP
Hardware Clock instead. That would make the race condition a non-issue
and also enable the nice hardware clock offered by the card(s).

Thanks,
Richard

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