From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.codeweavers.com (mail.codeweavers.com [4.36.192.163]) (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 66A9D33D515 for ; Thu, 21 May 2026 04:01:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=4.36.192.163 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779336083; cv=none; b=B73dxWQB7080S6qLhFMVLIEJCzYbqbjrqxNTvLuFdwfx4BPH90mVf0c4tHZpsWacrDVN5ozbpDxOVnW0A4O6WGYNIXJxUjamtoq56uZQLpUhbmQIpETPmuYxq/25vP0l12iMFeFNvLLIsJSF4U+yLgYGbwRFmVuqcyNb26iLxzg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779336083; c=relaxed/simple; bh=VXCzMP4hxv1hDlbnmHSZtkp9JnXXi+yL3x/3q3he8o8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mUyrfqMQqtm/Dt7naRa1de+x6f62m19dJJ7g6ksNkqIXKeYHPB6pfPxMeXyhs78d8NegiFtYVRlCtiPO01vROMCgx37lHnoWWPz+ScFRcwIcO43sPJLwNjU1QHPj7X95Upy1kQT2b7Kvb7lYjpD5YV7Ilhbad35yeWUUdfV0qgg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=codeweavers.com; spf=pass smtp.mailfrom=codeweavers.com; dkim=pass (2048-bit key) header.d=codeweavers.com header.i=@codeweavers.com header.b=X5Ou+hul; arc=none smtp.client-ip=4.36.192.163 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=codeweavers.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=codeweavers.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=codeweavers.com header.i=@codeweavers.com header.b="X5Ou+hul" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codeweavers.com; s=s1; h=Content-Type:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5RiQu/P5N/Mulf6u4QytO5hm82kaNAykUjUlJ0MINq4=; b=X5Ou+hul/0fBVPvsKRWt94cMzc 7UN2ikQm+S1za4tdBFd8YC/iCRs3ifRXArLYjOOez9CluCEgqXljuYe5h4gcjuXhy22vSgVTPaCcl 7BEQOjiHSBT62BYmrIBOC+Rmb0l0jYPLATJzHXPLDT9rKokubRA64IqaEM+wgMA5c4EsVYQD/vc3U lbBth80PO6HDeZDXweOhGrXs0gRK90TWG0OEM1igpmCBzJ45qN2GN0oHb6BjNfFT6BbsOujFpYEre VPIJKUxLa01W7Iiank4f/aqS0s9QqjFAAs+679yk/4hQZT2sTMI4HVDikYPp20sCKI5hfobAJJHDt BxKbMSKw==; Received: from cw137ip160.mn.codeweavers.com ([10.69.137.160] helo=camazotz.localnet) by mail.codeweavers.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wPuKR-000uog-0r; Wed, 20 May 2026 22:44:11 -0500 From: Elizabeth Figura To: arnd@arndb.de, Greg Kroah-Hartman , Maoyi Xie Cc: wine-devel@winehq.org, linux-kernel@vger.kernel.org Subject: Re: ntsync: absolute MONOTONIC timeout ignores time namespace offset Date: Wed, 20 May 2026 22:44:10 -0500 Message-ID: <53921477.W1JGFHXlht@camazotz> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" On Monday, 18 May 2026 05:21:08 CDT Maoyi Xie wrote: > Hi all, > > While reading drivers/misc/ntsync.c I noticed something that > might be a time-namespace bug. I would appreciate it if you > could take a look and let me know whether this is a real bug, > and whether it is worth fixing. > > ntsync_schedule() takes the user-supplied absolute timeout > 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 other absolute-timeout consumers (timerfd, posix-timers, > alarmtimer, posix-stubs, futex) all run user-supplied > absolute MONOTONIC ktime through timens_ktime_to_host() > before hrtimer. ntsync was added post-5.17 and seems to have > missed that step. > > /dev/ntsync is mode 0666, so any user in a time namespace > that can open it is affected. The user-visible impact is > wrong timeout behaviour for Wine inside a container that > sets a CLOCK_MONOTONIC offset. > > Attached PoC: baseline run elapsed ~100 ms; the --in-timens > run inside a -10s namespace elapsed ~0 ms. > > A candidate fix would call timens_ktime_to_host(clock, timeout) > in the else branch (i.e., when NTSYNC_WAIT_REALTIME is not set) > before passing the value to schedule_hrtimeout_range_clock(). > > If this is intentional or already known, please disregard. I was not aware of time namespaces, so no, this was not intentional, and there's no reason to keep it this way. I don't remember at this point if I wrote the timeout logic using any other code as a model... you'd think I would have used futex, but evidently I either didn't or missed the timens call. Thank you for catching this. > Otherwise, I am happy to send a [PATCH] or to leave the fix to you. No strong feelings here, so I suppose whoever gets to it first ;-) > Thank you for your time, and sorry for the noise if this is not actually > a bug or has already been spotted. > > Thanks, > Maoyi Xie > https://maoyixie.com/ >