From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: Xabier Marquiegui <xabier.marquiegui@gmail.com>
Cc: alex.maftei@amd.com, chrony-dev@chrony.tuxfamily.org,
davem@davemloft.net, horms@kernel.org, mlichvar@redhat.com,
netdev@vger.kernel.org, ntp-lists@mattcorallo.com,
reibax@gmail.com, richardcochran@gmail.com,
rrameshbabu@nvidia.com, shuah@kernel.org
Subject: Re: [PATCH net-next v2 2/3] ptp: support multiple timestamp event readers
Date: Wed, 13 Sep 2023 14:25:48 -0700 [thread overview]
Message-ID: <87wmwtojdv.fsf@intel.com> (raw)
In-Reply-To: <20230913085737.2214180-1-xmarquiegui@ainguraiiot.com>
Xabier Marquiegui <xabier.marquiegui@gmail.com> writes:
>> Using the pid of the task will break when using some form of file
>> descriptor passing. e.g. Task A opened the chardev, called the ioctl()
>> with some mask and then passed the fd to Task B, that's actually going
>> to use the fd.
>>
>> Is this something that we want to support? Am I missing something?
>
> Thank you very much for your valuable comments Vinicius,
>
> Let me try to confirm if I understand what you are observing here.
>
> Let's say we have a process with two threads. One of them opens the device
> file to do IOCTL operations, and the other one opens the device file to
> read timestamp events. Since both have the same PID, all the operations
> (read,release...) would fail because I designed them under the assumption
> that only one open operation would happen per PID.
>
I was initially thinking about another scenario: when Process A passes
the open file descriptor via SCM_RIGHTS to Process B.
But your scenario also shows the limitations of the current approach.
> This is indeed not as safe as it should be and I should try to improve it.
>
> I am already looking at alternatives, but maybe someone can give me a hint.
> Do you have any suggestions on what I could do to have file operations
> (read, release...) determine which open instance they belong to?
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?
Cheers,
--
Vinicius
next prev parent reply other threads:[~2023-09-13 21:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-12 22:02 [PATCH net-next v2 1/3] ptp: Replace timestamp event queue with linked list Xabier Marquiegui
2023-09-12 22:02 ` [PATCH net-next v2 2/3] ptp: support multiple timestamp event readers Xabier Marquiegui
2023-09-13 0:10 ` Vinicius Costa Gomes
2023-09-13 8:57 ` Xabier Marquiegui
2023-09-13 21:25 ` Vinicius Costa Gomes [this message]
2023-09-14 10:02 ` Xabier Marquiegui
2023-09-14 15:09 ` Richard Cochran
2023-09-14 17:12 ` Vinicius Costa Gomes
2023-09-19 15:15 ` kernel test robot
2023-09-12 22:02 ` [PATCH net-next v2 3/3] ptp: support event queue reader channel masks Xabier Marquiegui
2023-09-13 0:05 ` [PATCH net-next v2 1/3] ptp: Replace timestamp event queue with linked list Vinicius Costa Gomes
2023-09-13 7:56 ` Jiri Pirko
2023-09-14 14:21 ` Richard Cochran
2023-09-20 15:40 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wmwtojdv.fsf@intel.com \
--to=vinicius.gomes@intel.com \
--cc=alex.maftei@amd.com \
--cc=chrony-dev@chrony.tuxfamily.org \
--cc=davem@davemloft.net \
--cc=horms@kernel.org \
--cc=mlichvar@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=ntp-lists@mattcorallo.com \
--cc=reibax@gmail.com \
--cc=richardcochran@gmail.com \
--cc=rrameshbabu@nvidia.com \
--cc=shuah@kernel.org \
--cc=xabier.marquiegui@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.