netdev - Re: [PATCH net-next v2 2/3] ptp: support multiple timestamp event readers

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87jzssel0p.fsf@intel.com>
Date: Thu, 14 Sep 2023 10:12:54 -0700
From: Vinicius Costa Gomes <vinicius.gomes@...el.com>
To: Richard Cochran <richardcochran@...il.com>
Cc: Xabier Marquiegui <xabier.marquiegui@...il.com>, alex.maftei@....com,
 chrony-dev@...ony.tuxfamily.org, davem@...emloft.net, horms@...nel.org,
 mlichvar@...hat.com, netdev@...r.kernel.org, ntp-lists@...tcorallo.com,
 reibax@...il.com, rrameshbabu@...dia.com, shuah@...nel.org
Subject: Re: [PATCH net-next v2 2/3] ptp: support multiple timestamp event
 readers

Hi Richard,

Richard Cochran <richardcochran@...il.com> writes:

> On Wed, Sep 13, 2023 at 02:25:48PM -0700, Vinicius Costa Gomes wrote:
>
>> Taking a quick look, it seems that you would have to change 'struct
>> posix_clock_file_operations' to also pass around the 'struct file' of
>> the file being used.
>
> And let drivers compare struct file pointers from different consumers?
>

That was the first idea, not very good I admit.

What you said below sounds better, more "final product".

>> That way we can track each user/"open()". And if one program decides
>> that it needs to have have multiple fds with different masks, and so
>> different queues, it should just work.
>> 
>> What do you think?
>
> See posix-clock.c : posix_clock_open()
>
> When the file is opened, the fp->private_data is used to track the
> posix_clock that was registered as a character device by the ptp
> clock instance.
>
> That character device may be opened multiple times, each time there is
> a unique fp, but fp->private_data points to the same ptp clock instance.
>
> So the information of which fp is being read() is lost.

yeah, that's the core issue.

>
> Looks like you will have to re-work posix-clock.c to allow drivers to
> provide their own "private" data populated during posix_clock_operations::open()
>
> Needs thought...
>


Cheers,
-- 
Vinicius