From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx.treblig.org (mx.treblig.org [46.235.229.95]) (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 34D9D2A1B2 for ; Sun, 12 Jan 2025 16:01:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=46.235.229.95 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736697702; cv=none; b=Oo5WzA+p2ZwIZ59szB3sfN0XGy/bIsn3C2AAzJFEQ8NCOlU8wSTTcLj6L47rfeh3JKJ0Pt0Kb0ZUZ4v2tWqWlcPukweseCcPO+GvDyPw/ZOMizSxYXkPI22tkp4bJlVuVPHyX9IuAkabpp5wfc6jtCJqB2O6VdcKAfZz4s9ARIU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736697702; c=relaxed/simple; bh=nQ0ljl7Pta5B6SJdKHlupwEZY83PvA+1zGIVWExrYF0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=tiX+zEg4x7sRKq6RG8QL/mSHN7/AZc7bNwrW03AU5V330TxRlyJnroPi28ihPIDRWqxvjvVyvw13ETpsBwt7eVhWxBaJeFKM039fnwlFFca06q+HsFWrcSjN6DL/IS3R2Afly30/mDhfd91lQ+/yRVzYpIUQG49mHHDhrBmD9Fw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=treblig.org; spf=pass smtp.mailfrom=treblig.org; dkim=pass (2048-bit key) header.d=treblig.org header.i=@treblig.org header.b=rdLfPD6i; arc=none smtp.client-ip=46.235.229.95 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=treblig.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=treblig.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=treblig.org header.i=@treblig.org header.b="rdLfPD6i" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=treblig.org ; s=bytemarkmx; h=MIME-Version:Message-ID:Date:Subject:From:Content-Type:From :Subject; bh=kn5S0KVI6IVD8pKbXdTM5SU+CLoNg+vLp9lJeiuuVyc=; b=rdLfPD6iHvnHWfrx KWcDAvY/TNf61GJpSKL6xCuZTLF4eaa+O0m/1QGafPTWRRWb6EthElfiop14+M/aPPnQAMb6Vd2Ei no3R6b0mowWZXOfzZlM9nFSXmeql5IkWie4g8egbmbM9HHamM5NWrwsoGFjfmlItNb7cVQPpduIax +nUXSViuF8OBPW09nljtclVy3oaK6i0754ho0BfBvf/JNnEtMhWeWL89g6U88FicJfQVCe2w83s95 QNoZ6ZPfUHjoTP6LBugdvOQBsOJfbeJv+JYByPpkiRnd/T74nBEfUi5AJXoIUoZhZ+2ty13n/yYAk Qg1pldV0ZmeHNWUpuA==; Received: from localhost ([127.0.0.1] helo=dalek.home.treblig.org) by mx.treblig.org with esmtp (Exim 4.96) (envelope-from ) id 1tX0P6-009kLK-29; Sun, 12 Jan 2025 16:01:32 +0000 From: linux@treblig.org To: jstultz@google.com, tglx@linutronix.de, sboyd@kernel.org Cc: linux-kernel@vger.kernel.org, "Dr. David Alan Gilbert" Subject: [PATCH] timekeeping: Remove unused ktime_get_fast_timestamps Date: Sun, 12 Jan 2025 16:01:32 +0000 Message-ID: <20250112160132.450209-1-linux@treblig.org> X-Mailer: git-send-email 2.47.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Dr. David Alan Gilbert" ktime_get_fast_timestamps() was added in 2020 by commit e2d977c9f1ab ("timekeeping: Provide multi-timestamp accessor to NMI safe timekeeper") but has remained unused. Remove it. (Perhaps it's worth just reverting the entire commit, the only bit left is the extra parameter on __ktime_get_real_fast which is now always NULL). Signed-off-by: Dr. David Alan Gilbert --- include/linux/timekeeping.h | 15 ----------- kernel/time/timekeeping.c | 54 ------------------------------------- 2 files changed, 69 deletions(-) diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h index 0e035f675efe..542773650200 100644 --- a/include/linux/timekeeping.h +++ b/include/linux/timekeeping.h @@ -263,18 +263,6 @@ extern bool timekeeping_rtc_skipresume(void); extern void timekeeping_inject_sleeptime64(const struct timespec64 *delta); -/** - * struct ktime_timestamps - Simultaneous mono/boot/real timestamps - * @mono: Monotonic timestamp - * @boot: Boottime timestamp - * @real: Realtime timestamp - */ -struct ktime_timestamps { - u64 mono; - u64 boot; - u64 real; -}; - /** * struct system_time_snapshot - simultaneous raw/real time capture with * counter value @@ -345,9 +333,6 @@ extern int get_device_system_crosststamp( */ extern void ktime_get_snapshot(struct system_time_snapshot *systime_snapshot); -/* NMI safe mono/boot/realtime timestamps */ -extern void ktime_get_fast_timestamps(struct ktime_timestamps *snap); - /* * Persistent clock related interfaces */ diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 3d128825d343..2f9de089bc0d 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -515,60 +515,6 @@ u64 ktime_get_real_fast_ns(void) } EXPORT_SYMBOL_GPL(ktime_get_real_fast_ns); -/** - * ktime_get_fast_timestamps: - NMI safe timestamps - * @snapshot: Pointer to timestamp storage - * - * Stores clock monotonic, boottime and realtime timestamps. - * - * Boot time is a racy access on 32bit systems if the sleep time injection - * happens late during resume and not in timekeeping_resume(). That could - * be avoided by expanding struct tk_read_base with boot offset for 32bit - * and adding more overhead to the update. As this is a hard to observe - * once per resume event which can be filtered with reasonable effort using - * the accurate mono/real timestamps, it's probably not worth the trouble. - * - * Aside of that it might be possible on 32 and 64 bit to observe the - * following when the sleep time injection happens late: - * - * CPU 0 CPU 1 - * timekeeping_resume() - * ktime_get_fast_timestamps() - * mono, real = __ktime_get_real_fast() - * inject_sleep_time() - * update boot offset - * boot = mono + bootoffset; - * - * That means that boot time already has the sleep time adjustment, but - * real time does not. On the next readout both are in sync again. - * - * Preventing this for 64bit is not really feasible without destroying the - * careful cache layout of the timekeeper because the sequence count and - * struct tk_read_base would then need two cache lines instead of one. - * - * Access to the time keeper clock source is disabled across the innermost - * steps of suspend/resume. The accessors still work, but the timestamps - * are frozen until time keeping is resumed which happens very early. - * - * For regular suspend/resume there is no observable difference vs. sched - * clock, but it might affect some of the nasty low level debug printks. - * - * OTOH, access to sched clock is not guaranteed across suspend/resume on - * all systems either so it depends on the hardware in use. - * - * If that turns out to be a real problem then this could be mitigated by - * using sched clock in a similar way as during early boot. But it's not as - * trivial as on early boot because it needs some careful protection - * against the clock monotonic timestamp jumping backwards on resume. - */ -void ktime_get_fast_timestamps(struct ktime_timestamps *snapshot) -{ - struct timekeeper *tk = &tk_core.timekeeper; - - snapshot->real = __ktime_get_real_fast(&tk_fast_mono, &snapshot->mono); - snapshot->boot = snapshot->mono + ktime_to_ns(data_race(tk->offs_boot)); -} - /** * halt_fast_timekeeper - Prevent fast timekeeper from accessing clocksource. * @tk: Timekeeper to snapshot. -- 2.47.1