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: <ZQMiKE6x/euOv3Hc@hoboy.vegasvil.org>
Date: Thu, 14 Sep 2023 08:09:28 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Vinicius Costa Gomes <vinicius.gomes@...el.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

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 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.

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...

Thanks,
Richard