netdev - [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: <20230914100218.648085-1-xmarquiegui@ainguraiiot.com>
Date: Thu, 14 Sep 2023 12:02:18 +0200
From: Xabier Marquiegui <xabier.marquiegui@...il.com>
To: vinicius.gomes@...el.com
Cc: 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,
	richardcochran@...il.com,
	rrameshbabu@...dia.com,
	shuah@...nel.org,
	xabier.marquiegui@...il.com
Subject: [PATCH net-next v2 2/3] ptp: support multiple timestamp event readers

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

Thank you for the suggestion Vinicius. That was my initial approach, but I
couldn't make it work. Maybe I'm missing something. I searched struct file
for some variable that would help identifying the open/read/release instance
a call belongs to, but couldn't find any.

After that, I tried printing the struct file *fp pointer on every open call.
Unless I did something wrong I would say that it points to the same address
every time for a specific device file. My understanding is that if it was
different for each time open gets called, it would help us identify the user
of the rest of file operation calls, but not if it's the same. It is true that
I did this verification on kernel 6.1.38 and not the latest, but I don't think
that specific aspect has changed.

I will keep looking for options, but any help would be appreciated.

Thanks.
--
Xabier.