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
| ||
|
Date: Mon, 26 Mar 2012 15:32: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 Mon, Mar 26, 2012 at 2:56 PM, Keller, Jacob E <jacob.e.keller@...el.com> wrote: > I am curious how you see a kernel thread resolving the Tx/Rx issue? or is the > kernel thread being used by gettime? I don't believe we can wait for the Tx/Rx tx, rx path and kernel thread will use seq_lock_isave(tmreg_lock). A new 'u64 cached_ns' will be introduced. tx and rx path can update 'cached_ns' when they read the NIC counter. A kernel-thread should be scheduled periodically, will read the NIC counter and update cached_ns. It will use a _trylock variant. If the lock fails then its a hint that 'cached_ns' is getting updated somewhere, so just refresh the timer. Periodic update is needed to handle idle/bursty link conditions because the Rx/tx path may not run that often. gettime uses read_seq_lock and reads 'cached_ns'. I mean we could also do a atomic_read(?). > path, because if we take too long the software sees it as a dropped timestamp. What code-path is this? > How would we only allow one app? Any app with permissions could call the ioctls. > I do agree that having too many ioctls is a problem. Even in cases where PTP is We don't. So this is what I'm thinking. Ideally speaking only 1 app should be adjusting the host-clock and 1 app per NIC if you adjust NIC's clock. Ignore the host-clock app. Once you enforce the rate-limit, driver will return -EBUSY if you exceed it. Too many EBUSYs will provide a hint on user-side. 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
Powered by blists - more mailing lists