From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B72763E639A for ; Mon, 25 May 2026 09:30:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779701414; cv=none; b=MuwC5zLf5GpEbgAfxM2QpT3YIO16gE4og8+/Jb7YzFW0E98xX5kTgemDFU1p+gj9TA//fHXB5BQEugV40C7vQp9up+CR2TtBjX4y4/B0zTM0Ldu2prp//N/CIy8E0HLXMM/+z8in5AgLt2y9WbNPB9AyGF6c4svuQ+W4pYEsVAs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779701414; c=relaxed/simple; bh=MvC1QNZte1vXP30R+G20GuddcKWpV0IYT/a6vIu6DaU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=C0C0/M6QyOlCQpySmnLd2KrFTYd//wy0WCiMedEa8gv6gZwUbRETVBCFDXmhucL+WuiwrwplpEpgbDVt2jwV6o8YcqHTOlLBJ17jqp1jtzfB1eweAW3unHBZSpgz2Kh2P16LCuvKRpwLjThkvaHiEH+eoH6uunytQA32WPKZjRs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=DYdAla2C; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="DYdAla2C" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-49042aeeb75so40251055e9.1 for ; Mon, 25 May 2026 02:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1779701411; x=1780306211; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=nB5ICFmJn075+3/3lOrlZN7qx0yIhMuY0YXM2boINM4=; b=DYdAla2Cz5ErQNWX4OcY+3a/+hvknse4lj7uCCfqVN1Jy6XutlCydsaSM9gYPo/q+t zFGaIXl27VJehXCpXl7NIlMUOZ3guzho3Ika+2hMqFC4Wdf55nT/Ycy9p5siA7VtprpK BGPVTRq+sXMDpZuY5DLNxhKsCbpIsMSWAL17tHPDf3oe49KOsKvC1F0iBz4gJAnle6kr sRwCZOJRCaKVHiap+YRE1EUwOGnMspKsbEH+N7yB7pUUlGEgdtDlmdFGFUATiwxfAtTz okwy4G4wuO7W8G6ZzykModQDQ1xi7A2ivM6QjITctOi41943lVPU4tzyCHkVTgz0cSt4 0Fmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779701411; x=1780306211; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nB5ICFmJn075+3/3lOrlZN7qx0yIhMuY0YXM2boINM4=; b=nwgQQc8OFx2mBO3DkianmzIjIq9iKSGdP38dKFREgIVDPJllUdoNP+Em5ksXnaV03o Vu5ukl4IpsJhuLh1DsHxeGJmqsWcTzn8WCmNzCVSWCxxjTp+oxVZIDsOUBt4fi1l1QE2 SbUIjMhfNEEgLRUemlylYnCM5xdoZQuXb1xO6DjUICHTtYZNwpdIESgKp9OrWZFj8Ryr jJDj24Gx63uRw2stRWPu20C896wyauDnTS1XITtlY1DqU5HayRgIbAGQtq0lvhXgoN+e oxSfuqPNx6WoXIKHV8R/UM8LJeY89FTfci8BxUptDzIKME5PTohBaEN8qHlQJw9JT0A/ lKgA== X-Forwarded-Encrypted: i=1; AFNElJ/L21biUMpQ1icJWzQviq0OrqC86pIgg7QA3mJc+Ue9dVwW0j2XVTBcs1XJ9DaKk6OQmHsyni1/efFXLlw=@vger.kernel.org X-Gm-Message-State: AOJu0YzPRqNW6Tmelki1C6AfnunZqhgAgHU+zhOzqM2K6jrP13zhFhcy uPIq1mmrciWNhMpNZzsbi2ZmKnHcaGy8NMLgZqn8HsYjBE62cMh7iRQN8+UAwuTJzeI= X-Gm-Gg: Acq92OGz/2Cx+HN9yy4yfnBV24imjoVOrCRQJVIoYfTyegM+LTNL0rzcZgthKuAZ267 td8pJIoh18pX9qq4duNeoXOSbvVw4AdsBX2j/XcaWVeNnbERDmcfYCjU6sfiL+mj3PXE0x5FaeK 9rd3XRZgmb70DwyYsxDrAJXKPMAh72En+LzzrYUCLh1mMn5zZasPY88cCvuogPP8ptSZ/Z96E5U b61rZ7U/JbzvU3D0hgPnrWd3cB8pWFEqsnGQaIsm+zT+K89FYu1z3gPPKmdPYEIAesQy+mtHs0T 7tUhT5nEmG/+32uek3DcZ1zG3GnP5XCn6TgkzEfY+yG+luuTF81AkTDEdVzTfLJYOA5y23UFL3/ 3ErL1Fd14M3+jkM9Njzha2JA30JuFc8ZW4WOis3E3dX6askOhzT0neGtn5/OuLGDST7oUGvKlSX eY+KJ29Ij+djbXbmn8uYUJsKl2yAwso+oRahzE X-Received: by 2002:a05:600c:3b97:b0:490:52fb:12dd with SMTP id 5b1f17b1804b1-49052fb14fdmr165699725e9.10.1779701411103; Mon, 25 May 2026 02:30:11 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490454db285sm214565205e9.5.2026.05.25.02.30.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 May 2026 02:30:10 -0700 (PDT) Date: Mon, 25 May 2026 11:30:08 +0200 From: Petr Mladek To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: Steven Rostedt , John Ogness , Sergey Senozhatsky , linux-kernel@vger.kernel.org Subject: Re: [QUESTION] printk: time namespaces and printk timestamps Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Mon 2026-05-25 10:47:46, Thomas Weißschuh wrote: > On 2026-05-25 10:37:40+0200, Petr Mladek wrote: > > On Sat 2026-05-23 17:20:45, Thomas Weißschuh wrote: > > > It looks like the monotonic timestamps of printk records do not take the > > > callers time namespace into account when emitted through /dev/kmsg, > > > /proc/kmsg and syslog(2). > > > > > > To me this looks like a bug. What do you think? Should it be changed? > > > > To be honest, I have never heard about time namespaces before ;-) > > > > So, you propose to use the timestamp with the namespace-specific > > offset when a message is added from the given namespace, e.g. via: > > > > echo "This message is from another time space" > /dev/kmsg > > > > Do I get it correctly? > > My idea was rather to do the conversion when *reading* the message from > a time namespaced user process. I see. But it might produce messages with negative timestamps. I am not sure if it is a good idea. I guess that many tools might get confused. > > I see two potential problems: > > > > 1. printk() historically used a monotonic clock. I am not sure if any > > usespace application depends on it but there is a risk of breaking > > something. > > >From the perspective of the namespaced process currently the timestamps > from printk may in fact not be CLOCK_MONOTONIC. The messages stored in the kernel ring buffer currently always have monotonic timestamps. I guess that you talk about matching kernel messages with other userspace logs. But they might be inconsistent also because of using different clocks... There were several discussions in the past about storing more timestamps from different clocks in the printk ring buffer. But it never went anywhere. Best Regards, Petr