From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0DAED3FA5DD for ; Tue, 26 May 2026 14:12:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779804745; cv=none; b=dMH/Um6sg1dvtxB+PcIGDkiezC8DNkjT57dF6ZgDmhMIGxQ9YqxSWdvt2VY5iLio9LGZSR5bIaITEY9kv+cXyw6+a0tC/eWEas8tTWopTU8W/ilX4e9SjPfVsbMFGze2L1TsE+VhjtiJA541KE9+PS/6+/ihelg7aZEy039BxR0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779804745; c=relaxed/simple; bh=oeKThGx+CcFe+7cW5KuuXEHw5DQDXx5TdinUJQniX0A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=ngOaZShQGupqHjxqJnNhOio04S6GJis76wthSCjg1ysr0T55U8loJesd4pCTcnEsu5TXQPZmqvAFa6NG0pxRNlgookJAw3NnbtgA54aO9ohed9qZBstaLCBqk/87jFukEJZtcuyYi4tGDXi5plvylMLmqqwfGaWtf5mbM7/yY2k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I41RH0Sy; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I41RH0Sy" Received: by smtp.kernel.org (Postfix) with UTF8SMTPSA id C536B1F000E9; Tue, 26 May 2026 14:12:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779804743; bh=NJF5UiBHnlGjCpRhvT12YCk152jchiINPDpbSGKP2AM=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=I41RH0Syh+czfhsBnCdGspTcaPo7r68aQEaQjTFY2wwchocJTOeyUaWrzOG1r5ojb OkkKtkbt5qQHwHlkuonlGEujHLQ+we/mLy3o8NYis8HvreISSBdtuQ6tb2FpV1kdvf DVhbDS5KqEplg1QphruCR0zXA3wmbclQaNqu1SZ7o5RjeQL0E5jfzegi+5KpMNFMMm 8IXBQ+e5VlPx+lyADTcKRaP6lABSDlKnpen2ZDp6XsJFpfx40i7kLHvXpePXP1wtEf XYa98lRSd0JWzos1z2ruai5TCEyyOXEoezV628HvdiVDiiDNXU861DPs7L3+sVEK0K ibwYsk9y2XFBA== From: Thomas Gleixner To: Arthur Kiyanovski Cc: David Woodhouse , Miroslav Lichvar , Richard Cochran , Wen Gu , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , John Stultz , Stephen Boyd , Anna-Maria Behnsen , Frederic Weisbecker , Shuah Khan , Peter Zijlstra , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Arnd Bergmann , Julien Ridoux , Ryan Luu , linux-kernel@vger.kernel.org, Marcelo Tosatti Subject: Re: [RFC PATCH v2 0/8] timekeeping: Fix draft tracking precision and add feed-forward discipline via vmclock In-Reply-To: <177969636528.22488.1740278196841124440.b4-reply@b4> References: <20260517220326.4625-1-dwmw2@infradead.org> <0d32da75fa88c92ac0225ef23a9045afdf2ac9fe.camel@infradead.org> <87o6i8vcni.ffs@tglx> <6c7137748ccea288fdf55e7c2e24817ccc1673ef.camel@infradead.org> <874ijzvpl8.ffs@tglx> <00609fa255442648e11e2b5596a3b80a29edcfc8.camel@infradead.org> <87v7cftqey.ffs@tglx> <87se7ht25o.ffs@tglx> <177969636528.22488.1740278196841124440.b4-reply@b4> Date: Tue, 26 May 2026 16:12:19 +0200 Message-ID: <877boqtg3g.ffs@tglx> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Arthur! On Mon, May 25 2026 at 08:06, Arthur Kiyanovski wrote: > On 2026-05-24 14:36:35+02:00, Thomas Gleixner wrote: >> On Fri, May 22 2026 at 17:23, David Woodhouse wrote: > I'm the author of the PHC timestamp attributes series [1] that this > applies to. Before I spin v4 based on this design, I want to confirm > three implementation details: > > 1. Counter IDs: No stable UAPI clocksource numbering exists today > (enum clocksource_ids is kernel-internal). I'll define stable constants > in include/uapi/linux/ptp_clock.h (e.g., PTP_CSID_X86_TSC, > PTP_CSID_ARM_ARCH) and map internal IDs in the chardev layer. Either that or we make the clocksource IDs part of UABI, which avoids back and forth mapping. > 2. Array sizing: The timestamps array will be fixed at PTP_MAX_SAMPLES (25) > in the ioctl struct, not a flexible array, to keep > copy_from_user/copy_to_user bounded. Why? If userspace allocates an array size of 10k then the kernel will still only copy out PTP_MAX_SAMPLES entries. If it allocates two and asks for 10, that's not a kernel problem when adjacent data is overwritten. That's not any different from read(2) or other syscalls which do what they are asked to. > 3. Ioctl numbers: Two separate ioctls (PTP_SYS_OFFSET_EXTENDED_ATTRS and > PTP_SYS_OFFSET_PRECISE_ATTRS) sharing the same payload struct, matching > existing PTP convention. As I said, I have no strong opinion on that and that's a question to be answered by user space people. I personally would prefer one just because I'm lazy :) Thanks, tglx