From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (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 29D95335564 for ; Thu, 28 May 2026 06:33:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779950005; cv=none; b=Cnw1qqeN9OGzLr5x26BBOIvRABzBnHYKTERBmzSf9+EgwgLTxkKzfI2T+JrWcSEg5NET0HE9qj2pjEas5pZn9zmPku3dt4mnL7KIafJezvIKaAKrL6Xa5EvLPukDuMcfbExsqIGDpPR4ANd9I4nL05FG1GfCMR2yRzU5SF/ndEw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779950005; c=relaxed/simple; bh=aro1TDCeOiWY0+RzyW2elDOAf2h3a+8DCzCJJvqEZLQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=BFDYZd82IGwllLcJw29XywSmBQ6Dha/ALdoQMxF7M6EoGh9Qh+C5S29qWM+FD/ImTIf/P/9CU355IgCXB+DMgF9EbAftvH2aQ2vVUtSbMR785BCXx+vL+1ZBGtly0r9ZkTUGB22t9MQgtyCY5PRRSjj8DNiw+/pp6KufCIQ7SDY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=gBZEd604; arc=none smtp.client-ip=209.85.210.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="gBZEd604" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-82fbf5d4dc2so8676339b3a.1 for ; Wed, 27 May 2026 23:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779950002; x=1780554802; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=qZfTQcGtDAIuHbsFKSWK4VJ69GdmAZwJ+7pbD2EwyB0=; b=gBZEd604Esd4+rWrApOgBltIbx4tbLfU5Ezx7+c/Xj7rkAGYz0zj40tYs7MWwJpMrF 6jHldbEynVNAqvUIxpV7w2ncHJ6COt3f3HQ3RMiu+x1j/mCUmHsr6RSKS2+3tCjiOosy 8vPAdxF77QsoJgOA4oFv9JovF2+MCMSXqpemwc5+aXtIDB73jchUTSTs+6uVycijophP Pa2S7JDCvt+/K1kSYkPijPNTcwWePx9oHbvwm6QYTCsM9oThMnOMbf2ldBQax55cZTEZ kq+wcFXGcxFr+4bhMgTRleYSfqX9dylaFZUyvpQntzKBLJfc1mgVrCGW9VLb1Njbg7Ny loEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779950002; x=1780554802; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=qZfTQcGtDAIuHbsFKSWK4VJ69GdmAZwJ+7pbD2EwyB0=; b=AoJnfLwCE6CMnUr5aSXs9QIUozUuDWITgw6Iy4tCALZDKvBHTiX44e2hIOJEH+e7B3 eG5thf6G2q0m8fvSP5orAAxzlAXetRx6+SzBXUqJPzu4QsX6+Q6bwBg7xpzEA2G9Cau9 smXPFyjnm8aPE36A94B6NVeY47S5IHBtyCOW8Cp+nME7kAKuaSxZI5ZfRYntIq/xjmm7 NPTkeAYshfkUZJSLdlNNX31pKtoYNFeT57TKVcGkSqha7kVm0pXdf3BkpFkThrqgHTCb cJDfpR3C+viLfqlTyd1QuBwO1K7v7z/hSqTDpWhBx86BZ+n/vOChMMPMNalF1MpBb2My HLog== X-Gm-Message-State: AOJu0YwMV1nLhnK55M+8lN/020zc/wruMqRPLuTjKsq5nlRuaXmNaSJn OgI9Rla7hwzfjui+V2EVXJF/dYMnBkaj5gEy3V67Z8NHhM+L1mAmSsTN X-Gm-Gg: Acq92OEwMoUdfrBThOsXSek+Wlb8j68noItL09QPeOxoJHIb35mpYysfAnc7CMWeUMI UwSc4XCQEp1fPujudF3m7fyFHzzUlO0aJrN+QXD5AxxC/VZbvzYHqIw114XH+IHuL9pbjhK6s6u HeNc8ceF3y+oC7CqSSa6tcaTUXJD1HiVPOgLwGugg7paYYS916x03d9gLjsp9JE2CHbhBvB3Il6 YGud5gAEbA9yCe1Dv8pml00X3421QJU8LzIUauiBpRvEq86r0VR77loRm++l2GlhIhWDiUynsSJ yrWGrC+lIT67zqpdPPxXoTWjY045hA/Ija/JXTVBv8cwpbY/hV9W/wvwr9p5PYozUX7nlKP4eL2 WuIizfWW9pSw5tZnFhZoE/EoFK6A284OoQ167oqsKpxxGhEL97NAChFL4N6qDpRpgGvhUePYcQZ zP8xl+LyPIBRVIsxTRKKe2wFNJ/8KBLk7Al1i9muYtyj+iZnmgbiHeuYrrl1E= X-Received: by 2002:a05:6a00:4482:b0:82f:a89e:e16f with SMTP id d2e1a72fcca58-8415f3fdbd5mr24554235b3a.14.1779950002362; Wed, 27 May 2026 23:33:22 -0700 (PDT) Received: from csl-conti-dell7858.ntu.edu.sg ([155.69.195.57]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-841d6d60d07sm5628781b3a.0.2026.05.27.23.33.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 May 2026 23:33:21 -0700 (PDT) From: Maoyi Xie To: Thomas Gleixner , Anna-Maria Behnsen , Frederic Weisbecker , Elizabeth Figura , Arnd Bergmann , Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, Maoyi Xie , stable@vger.kernel.org Subject: [PATCH 2/2] ntsync: honour caller's time namespace for absolute MONOTONIC timeouts Date: Thu, 28 May 2026 14:33:11 +0800 Message-Id: <20260528063311.3300393-3-maoyixie.tju@gmail.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260528063311.3300393-1-maoyixie.tju@gmail.com> References: <20260528063311.3300393-1-maoyixie.tju@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ntsync_schedule() takes the absolute timeout from userspace and hands it to schedule_hrtimeout_range_clock() with HRTIMER_MODE_ABS. For the default CLOCK_MONOTONIC path, it does not call timens_ktime_to_host() first. A process inside a CLOCK_MONOTONIC time namespace computes the absolute timeout in its own clock view. The kernel reads the same value against the host clock. The two differ by the namespace offset. The timeout then fires too early or too late. Other consumers of absolute timeouts run the ktime through timens_ktime_to_host() before hrtimer. Examples are timerfd, posix-timers, alarmtimer, posix-stubs and futex. ntsync was added later and missed that step. /dev/ntsync is mode 0666. Any user inside a time namespace that can open it is affected. The visible effect is wrong timeout behaviour for Wine in a container that sets a CLOCK_MONOTONIC offset. Reproducer: unshare --user --time, set the monotonic offset to -10s, issue NTSYNC_IOC_WAIT_ANY with a 100 ms absolute MONOTONIC timeout. The baseline run elapses about 100 ms. The run inside the namespace elapses about 0 ms. Apply timens_ktime_to_host() to the parsed timeout when the caller did not set NTSYNC_WAIT_REALTIME. The helper does nothing in the initial time namespace, so the fast path is unchanged. Fixes: b4a7b5fe3f51 ("ntsync: Introduce NTSYNC_IOC_WAIT_ANY.") Cc: stable@vger.kernel.org # v6.14+ Signed-off-by: Maoyi Xie --- drivers/misc/ntsync.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/misc/ntsync.c b/drivers/misc/ntsync.c index 30af282262ef..02c9d1192812 100644 --- a/drivers/misc/ntsync.c +++ b/drivers/misc/ntsync.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #define NTSYNC_NAME "ntsync" @@ -836,6 +837,8 @@ static int ntsync_schedule(const struct ntsync_q *q, const struct ntsync_wait_ar if (args->flags & NTSYNC_WAIT_REALTIME) clock = CLOCK_REALTIME; + else + timeout = timens_ktime_to_host(clock, timeout); do { if (signal_pending(current)) { -- 2.34.1