From: Xabier Marquiegui <reibax@gmail.com>
To: reibax@gmail.com
Cc: chrony-dev@chrony.tuxfamily.org, davem@davemloft.net,
horms@kernel.org, jstultz@google.com, mlichvar@redhat.com,
netdev@vger.kernel.org, ntp-lists@mattcorallo.com,
richardcochran@gmail.com, rrameshbabu@nvidia.com,
shuah@kernel.org, tglx@linutronix.de, vinicius.gomes@intel.com
Subject: Re: [PATCH net-next v4 4/6] ptp: support event queue reader channel masks
Date: Sat, 7 Oct 2023 01:35:37 +0200 [thread overview]
Message-ID: <20231006233537.7721-1-reibax@gmail.com> (raw)
In-Reply-To: <5525d56c5feff9b28c6caa93e03d8f198d7412ce.1696511486.git.reibax@gmail.com>
Simon Horman said:
> Hi Xabier,
>
> queue appears to be leaked here.
>
> As flagged by Smatch.
Nice catch Simon. Thank you very much. I think I know how to fix it. I
will keep it in mind for the next revision.
Vinicius Costa Gomes said:
> Sorry that I only noticed a (possible) change in behavior now.
>
> Before this series, when there was a single queue, events where
> accumulated until the application reads the fd associated with the PTP
> device. i.e. it doesn't matter when the application calls open().
You are totally correct about that observation. I had never thought of
this angle until you mentioned it. Thank you for bringing it up.
> AFter this series events, are only accumulated after the queue
> associated with that fd is created, i.e. after open(). Events that
> happened before open() are lost (is this true? are we leaking them?).
Old events are indeed lost for a new reader, but I don't see how that
could be causing a leak. The way it works is, we always have at least
one queue: the one corresponding to sysfs.
Whenever a new reader accesses the device, a new queue is created and
starts to get fed with new coming timestamps alongside the rest of
existing queues.
> Is this a desired/wanted change? Is it possible that we have
> applications that depend on the "old" behavior?
I would really like to hear the voice of more experience people on this.
On my limited experience this is a non-issue because I can control the
sequencing and I am sure to have the reader ready before I trigger events,
but you might be right that there might be some use-cases I didn't imagine
that could be affected by this change in behavior.
We could tweak the system a little bit by having an additional reference
fifo with no readers. Whenever a new ptp_open happens, I could just copy
the entire reference fifo to the new one. I guess this would bring back
the need to have the fifo mutex.
If this idea works we could be maintaining the same functionality, at the
cost of making the system be more complex and slower. Is it worth it?
I look forward to hearing opinions on this. Thank you everyone for your
feedback.
next prev parent reply other threads:[~2023-10-06 23:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 13:53 [PATCH net-next v4 0/6] ptp: Support for multiple filtered timestamp event queue readers Xabier Marquiegui
2023-10-05 13:53 ` [PATCH net-next v4 1/6] posix-clock: introduce posix_clock_context concept Xabier Marquiegui
2023-10-06 11:02 ` Simon Horman
2023-10-05 13:53 ` [PATCH net-next v4 2/6] ptp: Replace timestamp event queue with linked list Xabier Marquiegui
2023-10-05 13:53 ` [PATCH net-next v4 3/6] ptp: support multiple timestamp event readers Xabier Marquiegui
2023-10-05 13:53 ` [PATCH net-next v4 4/6] ptp: support event queue reader channel masks Xabier Marquiegui
2023-10-06 11:01 ` Simon Horman
2023-10-06 22:05 ` Vinicius Costa Gomes
2023-10-07 3:53 ` Richard Cochran
2023-10-06 23:35 ` Xabier Marquiegui [this message]
2023-10-07 0:35 ` Vinicius Costa Gomes
2023-10-05 13:53 ` [PATCH net-next v4 5/6] ptp: add debugfs interface to see applied " Xabier Marquiegui
2023-10-05 13:53 ` [PATCH net-next v4 6/6] ptp: add testptp mask test Xabier Marquiegui
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=20231006233537.7721-1-reibax@gmail.com \
--to=reibax@gmail.com \
--cc=chrony-dev@chrony.tuxfamily.org \
--cc=davem@davemloft.net \
--cc=horms@kernel.org \
--cc=jstultz@google.com \
--cc=mlichvar@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=ntp-lists@mattcorallo.com \
--cc=richardcochran@gmail.com \
--cc=rrameshbabu@nvidia.com \
--cc=shuah@kernel.org \
--cc=tglx@linutronix.de \
--cc=vinicius.gomes@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).