[ntp:hackers] kern_ntptime and FreeBSD 6.1

todd glassey tglassey at earthlink.net
Mon Jan 22 07:46:07 PST 2007


Judah - have you found the same problem in 6.2 and has PHK seen it as well? 
I ask because I was about to upgrade a couple of systems from 5.x to 6.2...

Todd Glassey

----- Original Message ----- 
From: "Warner Losh" <imp at bsdimp.com>
To: <mills at udel.edu>
Cc: <hackers at lists.ntp.isc.org>; <judah at jilau1.colorado.edu>; 
<phk at FreeBSD.org>
Sent: Friday, January 19, 2007 10:23 PM
Subject: Re: [ntp:hackers] kern_ntptime and FreeBSD 6.1


> David,
>
>> I was kinda confused. You mentioned opensolaris as culprit and provided
>> what I thought was a patch to NTP to make it work with that system. Now
>> it appears the patch is for FreeBSD versions prior to 6.1, which I run
>> on all Intel and Alpha boxes here. I haven't had problems with any prior
>> and current FreeBSD, Solaris, SunOS or Alpha, which I have used at one
>> time or another since the first kernel version in 1992. Of course, while
>> I wrote the original code, usually somebody else integrated it with
>> their brand of copyin/copyout and Unix persuasion.
>
> Understood.  FreeBSD used to have this function as a sysctl wrapper
> rather than a real system call until recently, at least through 5.x.
> In 6.0 it was made a system call, and no body noticed the problem
> until Judah ran his program on it.  So only 6.0 and 6.1 were affected.
> And unless you actually looked at the return value during a leap
> second expecting to find it, you'd never notice anything was amiss.
> If time wasn't good and locked, you'd also notice a problem, but it
> would return '0' which I think masked the problem for so long.
>
> Sorry to confuse you with an OpenSolaris reference.  I just mentioned
> it as one place that definitely returned -1 in a few places.  FreeBSD
> just does this if you pass in a bogus address and copyout fails.
>
> Thanks for doing the original implementation that has been so widely
> adapted.
>
> Warner
>
>> Dave
>>
>> M. Warner Losh wrote:
>>
>> > In message: <45AFD7A4.7090801 at udel.edu>
>> > "David L. Mills" <mills at udel.edu> writes:
>> > : Your attachment was eaten by our virus filters.
>> >
>> > Bummer.
>> >
>> > : I wrote the original ntptime some years ago, but apparently busy
>> > fingers
>> > : have hideously transformed it. I wrote the kernel code as well, but
>> > : others might have broken that. As per spec in the timex.h header 
>> > file,
>> > : the NTP kernel code does not return a negative number, except 
>> > possibly
>> > : in case of root violation or copyin/copyout problem. As specified in
>> > the
>> > : timex.h header file, it returns an integer 0 - 5 rpresenting the leap
>> > : condition, with 5 reserved for error.
>> >
>> > Correct. I had some trouble finding the exact spec that said this,
>> > but did find it in the end. Thanks for the confirmation...
>> >
>> > : The error return of 5 was purposely chosen to be non-negative, as the
>> > : intended action is to inspect the status word returned by the call.
>> > This
>> > : leaves room for the operating system to intercede with one of its own
>> > : codes. Therefore, a negatie return indicates a kernel problem, not a
>> > NTP
>> > : problem.
>> >
>> > Right. The kernel has a 'weird' return value for system calls it
>> > implements. In the FreeBSD kernel, a 0 return value means that the
>> > value from td_retval[0] is copied to userland and used as the return
>> > value (variations on this theme exist for any BSD kernel). A positive
>> > value causes that value to be copied out to userland for an errno
>> > value and -1 is returned from the function.
>> >
>> > The problem was that td_retval wasn't getting set, so the userland
>> > function only ever returned -1 or 0, which was clearly wrong. The fix
>> > for that can be found here:
>> >
>> > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_ntptime.c.diff?r1=1.60&r2=1.61
>> >
>> > It is easy to apply this to the pervious versions of FreeBSD that got
>> > it wrong :-(.
>> >
>> > Warner
>> >
>> > : Dave
>> > :
>> > : M. Warner Losh wrote:
>> > :
>> > : > btw, it looks like opensolaris returns -1 on fault conditions and 
>> > much
>> > : > of the ntp code assumes that < 0 is an error... The enclosed patch
>> > : > will fix that.
>> > : >
>> > : > Warner
>> > : >
>> > :
>> > :
>>
>>
>>
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers 



More information about the hackers mailing list