From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47D1EC27C40 for ; Wed, 22 Nov 2023 20:36:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE2E26B060B; Wed, 22 Nov 2023 15:36:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C932F6B060E; Wed, 22 Nov 2023 15:36:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5B276B061E; Wed, 22 Nov 2023 15:36:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A290B6B060B for ; Wed, 22 Nov 2023 15:36:25 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 7AAD41A131F for ; Wed, 22 Nov 2023 20:36:25 +0000 (UTC) X-FDA: 81486747930.30.ED8D473 Received: from mail-ua1-f42.google.com (mail-ua1-f42.google.com [209.85.222.42]) by imf14.hostedemail.com (Postfix) with ESMTP id CB2B610000A for ; Wed, 22 Nov 2023 20:36:23 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=A3KEpKka; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of elver@google.com designates 209.85.222.42 as permitted sender) smtp.mailfrom=elver@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700685383; a=rsa-sha256; cv=none; b=3I/ne7WzOmMK/qoPCtB1SQJovx3KRGAjhG1QK/wP8yVNCyCCIonsNMlfaLhuFAWJio7KhM wNedNUYTBzP/Fpm02HTpN2Fj0xi0YBOXFJRd7UmkuTaoMkQEm34Gza3YdupAcdEeNNsS4q AWM4p9EnYp8fY3RjMvFaweRJ2CBng9g= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=A3KEpKka; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of elver@google.com designates 209.85.222.42 as permitted sender) smtp.mailfrom=elver@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700685383; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vkfEHr78Ys9Zl8oeeDr7y3wj216XnJVscyV3Cx1FHDQ=; b=hvrdnmUYokvwKuyOQCnI9DY01+P3FNBuWZduDEARf+5E8K5QSiP8X+Q8P7LhvgIaPk/+10 kcge1y1N9Mw70+nSEVNivrpEHHz4il7NwOIdq9uop770t3lKhdxAAWyFNRUWqTAHuJLfVR NbIMp8AacS/MgAARjygi9zpn5J1xo+o= Received: by mail-ua1-f42.google.com with SMTP id a1e0cc1a2514c-7c45bee5fdaso42005241.1 for ; Wed, 22 Nov 2023 12:36:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1700685383; x=1701290183; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vkfEHr78Ys9Zl8oeeDr7y3wj216XnJVscyV3Cx1FHDQ=; b=A3KEpKkaE6kajfzk9FsfoCDJElD7/faXRyh6MYoSE1OvW42/ItShxzPYsRzLz9f9Wn lfGsK1cPy4lNcOfTJ/X/+nbUCAh+db81BJBen51Z9tnwPpfRaKbqEKGtBvahAtyVr263 o2VZMqrj4bchWNJzWqaySpQuEjvZzFml/PAOPIO+BzaYaOjrLLeUtTqbRfEmUULcj+RW Y5uuus1FcPbgvB7IIlCvOikk8VKrPPkaO0nnFUYuqMl4q1ofJ0U1PeLd25K6odPnRXOB hh2In5fvIqjWbU7r1XhMFZQLSJBLgCp6TpX4WC4T33eEClrTc/nX+hP0OJBK/tkjAc6l LK9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700685383; x=1701290183; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vkfEHr78Ys9Zl8oeeDr7y3wj216XnJVscyV3Cx1FHDQ=; b=Bg2+vbkyMm1wbJwr9OtiHItc/E4FdqNfdy6+NfDjtWnSDZ2HpNAPIanCkB5uYOmK6v oPJncZrGv0WirSKCeZQ9zbiRWNSdxP6vR6TmJJc400+qXwLJbVE1xz/Ss43xrOkhG/bI FDXwIWq9YRz7GtuCrOSPbVtalipg9To07gss9v+o0WN91nA0Yka0+XhvunXotU+KjLrQ noxqwz/2ZjZZuui0zS9NykxFkOSzWLBobPfPrYGMkGLYf5v6vbot208dRNUI6klCMWjM reWB3EZZV8fQ/HhTT1tkv7nn5B1PzsK2xI9rFS0x08vfwNDAOOlUL6daqw/fTK2z7Mf8 lx/A== X-Gm-Message-State: AOJu0YyXuCaGYgNgQFgcLsp/Mk6KIzCT2G7d2MnyBSK9whKF19gB14xl 1f/vK4QPVLY5T+I7JKXkuDre9wFWZZRGndnBcodkPA== X-Google-Smtp-Source: AGHT+IEaacdnUa59qnize/3QcKbGSEsX/+QaFt9aREFTu+hko0hMQ/cZ5K0QHHgTXpOhmPH20kWi4VltLof9HqTi4Bs= X-Received: by 2002:a1f:4c04:0:b0:4ac:c52d:70f9 with SMTP id z4-20020a1f4c04000000b004acc52d70f9mr3579163vka.10.1700685382734; Wed, 22 Nov 2023 12:36:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Marco Elver Date: Wed, 22 Nov 2023 21:35:44 +0100 Message-ID: Subject: Re: [PATCH] kfence: Replace local_clock() with ktime_get_boot_fast_ns() To: Juntong Deng Cc: glider@google.com, dvyukov@google.com, akpm@linux-foundation.org, kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kernel-mentees@lists.linuxfoundation.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CB2B610000A X-Stat-Signature: uj7ukibz6ssetq4rd6qdmc6gp7pa7xkh X-HE-Tag: 1700685383-515669 X-HE-Meta: U2FsdGVkX1/NE0oF7YgGyF4GcWR83gSVa873bFikEg/Gt3pntrRCExkgMP75ykXirYs30n4/hI0kHX4vOjimx/RqCzcf08Fsc5h4k1Car1fUQuj29M0NQxTZCkYUoGOTfRAkptAzT7f9Zzl2YTLWNynftRtwO0XgBLfZrSlxzMrsms9X4POhcsTdv6JLFwjCp8UNjaUSeOxQKJJOlwIiblotchGlW3UElzf3vTv9RrZ+I0AHHcYNzhqhIYtEkzK0QJdlAEnoye+wn3ZtDMTK4F5MwEylittyV1QwjXN/8gHhjBur2yU+zfEjp1F0PttZKsT6LMN+/WHGWuYMuzW2Wcaiq4mW/oGhSvNlXdGKEACvpOXJqevdPvIpoHGwdF+Soz7kMitCpigyPGm0VhUUH1ezky5Q5Bi+CTJvBCTKU7F8jK4LebdZL/Q8mKmj7ZPRbXZ+YV+ZAhCfPAACEScnXoLZf5D2RuO2tdD5fXrbFxcXRCfeJ23UWSb2mSdeVmIco6TzwwK8oHUUL8NrZmossN2/URmB5pzmXZIc51bEA0jSYjTQAohecKm+gtrUjnVIUFBdSEhAc6V/aJrIGLH7OL2c5DGGVhTAPSma3meAumjqJCGtx01AJuFYa111WoFPMoOR4Jd+LMaBanlu+6HBsipTCgal2HyXuBiWDDl2QCgcG7WAGS8mvLhdydmlReTJPbh+WmsN2HFLenry2srO7cFJqdgQ5AohSu7u7PXbmpaJVn0cFL7te5DEhqWatEHh7fUpkRO4aTYQGUTaGfslJiobpaZ2S85UZ0LF4HxWqxMcYPp/Tv7mR0I4r4uxgZAmNE5lWRhf6Fnw6n8ki0dhJQuGiWh/yEyKwT4QFmDc0cLUXxUCUVpKOzKD9jzuNR+wTokvkaMa/0RfluFtz0KnO1alXd9CaV2Cscg7oJY1OqKEsKv84AVmSDMmmAwHzdvf2BQ5xRDto+HJJU1V62X BNrDTATC WgR6XtIgaAXblZWgIEktlxlFtjARUuYjCOVAS/jw4s8khNZcWOWz3+49wiYSEX8kV9ZeWldY+IOOCiqzhJBXUeHlYibnZgg16ouG49gm31zciOnH6PIGLCEgUMz8t9azUkx7WM5DWBF8Z8Bnw8ENNph2Tzo6qWuMvXlo8m40OD4cTZTtgDSE0ihgerRlLiphVTjFB+o91rJve7pmHBrv857yiT2NNjuX5KJ1qK6haUHQiw5oTY4idXnUz+tlgTPueA4+WlBgcdGpygybVk6lv011dA2HJhkCbLh/l X-Bogosity: Ham, tests=bogofilter, spamicity=0.110155, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, 22 Nov 2023 at 21:01, Juntong Deng wrote: > > The time obtained by local_clock() is the local CPU time, which may > drift between CPUs and is not suitable for comparison across CPUs. > > It is possible for allocation and free to occur on different CPUs, > and using local_clock() to record timestamps may cause confusion. The same problem exists with printk logging. > ktime_get_boot_fast_ns() is based on clock sources and can be used > reliably and accurately for comparison across CPUs. You may be right here, however, the choice of local_clock() was deliberate: it's the same timestamp source that printk uses. Also, on systems where there is drift, the arch selects CONFIG_HAVE_UNSTABLE_SCHED_CLOCK (like on x86) and the drift is generally bounded. > Signed-off-by: Juntong Deng > --- > mm/kfence/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/kfence/core.c b/mm/kfence/core.c > index 3872528d0963..041c03394193 100644 > --- a/mm/kfence/core.c > +++ b/mm/kfence/core.c > @@ -295,7 +295,7 @@ metadata_update_state(struct kfence_metadata *meta, enum kfence_object_state nex > track->num_stack_entries = num_stack_entries; > track->pid = task_pid_nr(current); > track->cpu = raw_smp_processor_id(); > - track->ts_nsec = local_clock(); /* Same source as printk timestamps. */ > + track->ts_nsec = ktime_get_boot_fast_ns(); You have ignored the comment placed here - now it's no longer the same source as printk timestamps. I think not being able to correlate information from KFENCE reports with timestamps in lines from printk is worse. For now, I have to Nack: Unless you can prove that ktime_get_boot_fast_ns() can still be correlated with timestamps from printk timestamps, I think this change only trades one problem for another. Thanks, -- Marco