Re: [PATCH net-next v2 1/3] posix clocks: Store file pointer in clock context

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, Feb 13 2025 at 12:37, Paolo Abeni wrote:
> Posix clock maintainers have not being CC-ed, adding them.

Tx!

> $Subject: posix clocks: Store file pointer in clock context

s/posix_clocks:/posix-clock:/

s/clock context/struct posix_clock_context/

>> Dynamic clocks (e.g. PTP clocks) need access to the permissions with
>> which the clock was opened to enforce proper access control.
>> 
>> Native POSIX clocks have access to this information via
>> posix_clock_desc. However, it is not accessible from the implementation
>> of dynamic clocks.

>> Add struct file* to POSIX clock context for access from dynamic
>> clocks.

What is a native posix clock? posix_clock_desc is used in the context of
dynamic posix clocks, no?

I assume this wants to say:

 "The file descriptor based sys_clock_*() operations of dynamic posix
  clocks have access to the file pointer and implement permission checks
  in the generic code before invoking the relevant PTP clock callback.

  The character device operations (open, read, poll, ioctl) do not have
  a generic permission control and the PTP clock callbacks have no
  access to the file pointer to implement them.

  Extend struct posix_clock_context with a struct file pointer and
  initialize it in posix_clock_open(), so that all PTP clock callbacks
  can access it.

Or something like that, right?
 
>> @@ -95,10 +95,13 @@ struct posix_clock {
>>   * struct posix_clock_context - represents clock file operations context
>>   *
>>   * @clk:              Pointer to the clock
>> + * @fp:               Pointer to the file used for opening the clock
>>   * @private_clkdata:  Pointer to user data
>>   *
>>   * Drivers should use struct posix_clock_context during specific character
>> - * device file operation methods to access the posix clock.
>> + * device file operation methods to access the posix clock. In particular,
>> + * the file pointer can be used to verify correct access mode for custom
>> + * ioctl calls.

s/custom ioctl calls/ioctl() calls/

Other than that this looks sane.

Thanks,

        tglx