On 10/13/2022 9:04 AM, Miroslav Lichvar wrote:
> 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.
>
Ok, this is v3.9, and is a possible path for returning zero without an
error.
>> 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?
>
It looks like we can return out of ptp_clock_adjtime with the following
flows:
a) -EBUSY if ptp_clock_freerun is true
b) -EFAULT if copy_from_user or copy_to_user fails
c) -EOPNOTSUPP on kernels older than v3.7
d) -EACCESS if the fmode on the clock is not write
e) an error if get_clock_desc fails
I think a fatal error here is sufficient, and would catch everything
except the posix-timers bug that you fixed above.
Thanks,
Jake
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
