From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (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 E429E1DD87D for ; Sat, 15 Mar 2025 23:22:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742080968; cv=none; b=pL6PW/kfjyuG99Xkm+b3ZrxKi6JJ9y9/x1d8vPuI1GQhovVG+T7Oc5Q3OuIyxtrIMFir/T+8mkDbEr2GQFnTHB7XcgZs8IKw1k96sxhfHymzaIgZB1545B3LFxSn552Bu6fz6V5/e8cfDZFCcU2wO37xeCoosmhPVkGD7CZ2uY4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742080968; c=relaxed/simple; bh=yNaoFHNvsRgrKLIIXbY1OLgrHQAve7Ng1Ej6GhX1j/o=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=gqlMnn2K0NhpO7DABKv6Bjsn4xB8WJKhQq2eH3vJG0hC71+poGpoipO7n5SsaAyjkMscT7DiAs/3sA3o+zHvbhkY6WUrpb57R37IEuttg0lhA7VYHEy+SqxTHVIyk9zec819kvK0l/hK/htOfZ6NtTr7IPz86jYb1Ko8gsEqLWk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=EFVB5mBM; arc=none smtp.client-ip=209.85.167.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="EFVB5mBM" Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-547bcef2f96so3609261e87.1 for ; Sat, 15 Mar 2025 16:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1742080965; x=1742685765; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=EefKwIQk/c3BzKg46/rkLNUtfV5M7e4WxDiNJGdBaK4=; b=EFVB5mBMqJtdcY+i2Xpu6vGS6nZNLKupBzMlN1wH5ASUYoFVv3FxHdyZSEUKWqpQfV 1aIbVUrym2YHK4nSwbES05CS4qxqDUTmI30D6Jy//m1j6Lrz+ma05l/bNdyeuZJhhArE /wzH90Okn9rKuxfueMigMFctpv/T0biQUUjv83amYlIiJAGJh96VLhgEO9S1SQxvPwzp iXxuOOPJtU8kIdJKyXisAZvnZxERWcMyaiDn5Dcylu0TifBz3zYROT/FZlCObR++FS9s +zyKUGybzOD0USyAeGM7sr8RZJoq+GhASGUQUiYdPcfw1HTSODRdbwRhlp3n+n/P5VEK LVJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742080965; x=1742685765; h=content-transfer-encoding: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=EefKwIQk/c3BzKg46/rkLNUtfV5M7e4WxDiNJGdBaK4=; b=jYQtAOQCRW7UlYCbp3LGtfl7BbJSNsqgZbACLffvfvXxuDUSgvMci/QpQTfmYfo99O 3GQ2r8J3So8D5yn8KFeL25lI24gT1IkuxBasdi5MMXZhC0AKbRr7dSe62pvI7VivzNSB F7yU2AMKwBSRFbN9cN1vMhaMNdXALjJcloKNqvPRIzf3xBe2GulykEYCvuCHUvJTk5nr R1HjrlzHNj1CE+4l7BtRO4Y2qs0kAiu4GJQ8zXApAoJg9KxpnjNgNNA06t5PWKr6NowP MVr56qmxGAthvJ9zJzIOcUf4R7R8ii2iXSDmDaDYg+kZtjC/xG1JTQxLKJtBD6PQ8Cg2 xxyA== X-Gm-Message-State: AOJu0YxL1v9aCYphyU+lbvTtRSXz0z4U7p17axgXWx5zp/NZXUGjpbPs T+byGCPnZWMK4LDxdlqJYp28z+15dE80nPdNbH5LUBI3Y2nJyv0AO+gDNCtZSac8/BE1aA+Pf1I SB4af6luvV1t3US4x7jWApSR2m5uM3YnPyZ8= X-Gm-Gg: ASbGncssEj3B8lis+6h+0TtWERzErZn6TnL792Ecv1I59aNwlUmk3q9Jw7girTtqs3u LRh9//Omj5dfppldviWpOsXv2ZfOjZdko64UUOU6pZzbWNY10ormCHtuBfePsaIWFzcDHOEQSFi GK3np4OVsAZv2alKSIKhTTmRU= X-Google-Smtp-Source: AGHT+IFqXySBquMSOg3NeTSpFmh8r8wJRIdEXBekJ8c/KO3XV5blNMGC43iqUJn5zChXka+JzIh80b8UmBY8qMw2EuE= X-Received: by 2002:a05:6512:ac6:b0:545:225d:6463 with SMTP id 2adb3069b0e04-549c3989a09mr2309850e87.42.1742080964693; Sat, 15 Mar 2025 16:22:44 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250315003800.3054684-1-jstultz@google.com> <877c4q5c9i.ffs@tglx> In-Reply-To: <877c4q5c9i.ffs@tglx> From: John Stultz Date: Sat, 15 Mar 2025 16:22:31 -0700 X-Gm-Features: AQ5f1JqZOBd0eK-IeI1kmw23yAU3IShwRh1wrzTVoSYG74q1BSpXea1M-rNonf4 Message-ID: Subject: Re: [RFC PATCH 1/2] time/timekeeping: Fix possible inconsistencies in _COARSE clockids To: Thomas Gleixner Cc: LKML , Stephen Boyd , Anna-Maria Behnsen , Frederic Weisbecker , Shuah Khan , Miroslav Lichvar , linux-kselftest@vger.kernel.org, kernel-team@android.com, Lei Chen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 15, 2025 at 12:23=E2=80=AFPM Thomas Gleixner wrote: > On Fri, Mar 14 2025 at 17:37, John Stultz wrote: > > Here because we did not accumulate anything, we have a window > > where the _COARSE clockids that don't utilize the mult*offset > > value, can see an inconsistency. > > > > So to fix this, rework the timekeeping_advance() logic a bit > > so that when we are called from do_adjtimex() and the offset > > is smaller then cycle_interval, that we call > > timekeeping_forward(), to first accumulate the sub-interval > > time into xtime_nsec. Then with no unaccumulated cycles in > > offset, we can do the mult adjustment without worry of the > > subtraction having an impact. > > It's a smart solution. I briefly pondered something similar, but I'm not > really fond of the fact, that it causes a clock_was_set() event for no > good reason. > > clock_was_set() means that there is a time jump. But that's absolutely > not the case with do_adjtimex() changing the frequency for quick > adjustments. That does not affect continuity at all. Oh, good point. I wasn't thinking clearly about the semantics, and was being a little paranoid there (as most calls to timekeeping_forward_now() have clock_was_set() calls that follow). I suspect I can do away with that bit and avoid it. I'll respin later this week. > That event causes avoidable overhead in the kernel, but it's also > exposed to user space via timerfd TFD_TIMER_CANCEL_ON_SET. > > I have no really strong opinion about that, but the route through > clock_was_set() triggers my semantical mismatch sensors :) Yeah, it's a fair point, thanks for raising it! > > NOTE: This was implemented as a potential alternative to > > Thomas' approach here: > > https://lore.kernel.org/lkml/87cyej5rid.ffs@tglx/ > > > > And similarly, it needs some additional review and testing, > > as it was developed while packing for conference travel. > > We can debate that next week over your favourite beverage :) Looking forward to it :) -john