On Wed, Oct 12, 2022 at 03:23:18PM -0700, Jacob Keller wrote:
> For the record I suspect this is related to Linux kernel commit
> 5c35bad5ffe5 ("ptp: provide the clock's adjusted frequency"). This
> landed in v3.7, so its pretty old, and I think dropping support for it
> is probably fine.
>
> Interestingly, it looks like the kernel tried to return EOPNOTSUP. I
> don't know why this would silently fail... Any recollection?
I think it's f0dbe81f0e7c ("posix-timers: Fix clock_adjtime to always
return timex data on success"). That was an issue with CLOCK_REALTIME,
which caused clock_adjtime() to not return the data if the clock was
not synchronized or had a leap second.
> I guess it doesn't "silently" fail, the function logs an error with
> fprintf, but it doesn't have any way to report the error back to the
> caller, so the caller sees "0" with a log message, which is the "silent"
> failure you mentioned.
>
> Alternatively this could be fixed by refactoring clockadj_get_freq to
> return its integer error code and put the value into an argument instead?
>
> That would catch errors related to other failures such as access or
> permission. This would also work properly at least on the versions of
> the kernel I checked.
>
> Thoughts?
Could all these be handled as a fatal error, causing the program to
exit as there is no reasonable recovery? Or is it possible to get
EBUSY like with clock_gettime() and the SYS_OFFSET ioctls?
--
Miroslav Lichvar
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
