On Tue, 9 May 2023 at 14:33, Miroslav Lichvar <mlich...@redhat.com> wrote: > On Tue, May 09, 2023 at 02:02:05PM +0200, Andrew Zaborowski wrote: > > Per https://www.kernel.org/doc/Documentation/networking/timestamping.txt > > section 3: > > "User space is responsible to ensure that multiple processes don't interfere > > with each other and that the settings are reset." > > > > Add locking for the interface's HW timestamping mode to ensure that in a > > setup with multiple ptp4l sessions sharing interfaces the sessions don't > > overwrite each other's timestamping mode and that there is one session > > responsible for resetting the mode on exit. > > Is this intended to catch misconfigurations where different ptp4l > instances are setting incompatible RX filters?
Yes. The original intent (in a patch by Chris Hall using pthread semaphores and SHM) was to protect the setup only but I extended it to keep the lock for the whole runtime. > > If I understand the solution correctly, stopping ptp4l would break > another ptp4l instance if they don't share the same filesystem (e.g. > containers), Yep, I guess that will break unless you take care to stop the instances in the reverse order to that in which they were started. Is there a use case for multiple ptp4l instances in different containers? You'd have to coordinate the instances in terms of using unique clockIdentities and unique vclocks too. > or a different program is using HW timestamping (e.g. > chronyd). True. To handle that case I'd need to drop the cleanup part in this patch,... or add a compatible mechanism in chronyd. Or again the user would have to keep track of the shutdown order. Best regards _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
