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: Thu, 4 Aug 2016 19:34:35 +0000 From: "Brown, Aaron F" <aaron.f.brown@...el.com> To: "Woodford, Timothy W." <Timothy.Woodford@...apl.edu>, "Avargil, Raanan" <raanan.avargil@...el.com>, Jarod Wilson <jarod@...hat.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Hall, Christopher S" <christopher.s.hall@...el.com> CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org> Subject: RE: [Intel-wired-lan] [PATCH net-next v3 1/2] e1000e: factor out systim sanitization > From: Intel-wired-lan [mailto:intel-wired-lan-bounces@...ts.osuosl.org] On > Behalf Of Woodford, Timothy W. > Sent: Friday, July 29, 2016 7:41 AM > To: Woodford, Timothy W. <Timothy.Woodford@...apl.edu>; Avargil, > Raanan <raanan.avargil@...el.com>; Jarod Wilson <jarod@...hat.com>; > linux-kernel@...r.kernel.org; Hall, Christopher S > <christopher.s.hall@...el.com> > Cc: netdev@...r.kernel.org; intel-wired-lan@...ts.osuosl.org > Subject: Re: [Intel-wired-lan] [PATCH net-next v3 1/2] e1000e: factor out > systim sanitization > > >>> This is prepatory work for an expanding list of adapter families that have > occasional ~10 hour clock jumps when being used for PTP. Factor out the > sanitization function and convert to using a feature (bug) flag, per suggestion > from Jesse Brandeburg. > >>> > >>> Littering functional code with device-specific checks is much messier than > simply checking a flag, and having device-specific init set flags as needed. > >>> There are probably a number of other cases in the e1000e code that > could/should be converted similarly. > >> > >> Looks ok to me. > >> Adding Chris who asked what happens if we reach the max retry counter > (E1000_MAX_82574_SYSTIM_REREAD)? > >> This counter is set to 50. > >> Can you, for testing purposes, decreased this value (or even set it to 0) > and see what happens? > > I'll set the max retry counter to 1 and run an overnight test to see what > happens. > > After running with this configuration for about 36 hours, I haven't seen any > timing jumps. Either this configuration eliminates the error, or it makes it > significantly less likely to occur. > > Tim Woodford Feel free to throw a Tested-by: on it if you like. Not a big deal either way, I managed to get enough cycles in on it I'm pretty happy with it as well. > _______________________________________________ > Intel-wired-lan mailing list > Intel-wired-lan@...ts.osuosl.org > http://lists.osuosl.org/mailman/listinfo/intel-wired-lan
Powered by blists - more mailing lists