From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 C9BE417A2E6 for ; Tue, 23 Dec 2025 00:27:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766449666; cv=none; b=fVxQLWhdpaIXVnlmSNYuV2Rq0Vi2WltZ3YVyBx4pKt7sDEkJjrtvkFYcnnCRQ0vkpzb010OioKN0sraj/sKJtQQWzYPfL+aG0TuB1OTPfF1vaI0VSOjjW2BmVPy4uboI3wwys/6w4HDPsO85nDZT0e9aKA3UmR+vWr68BwvfTig= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766449666; c=relaxed/simple; bh=b7+HpRgt18ri51O6HCTR2OI3tAqxC0ytn2VnV1ruqDk=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=rGSHLALthBj4ozKQd1eAzLjMmsYE8tFDbWAouYHRE5HjxtlWQOCRkqRgelB0E8pJ9Jf4r6+9JmHuShbFEf6w4L89KUnA5kNnZrISZKDATg1hKUvViX4y2oLWT24JV4yHctRDpeHbTU+fh+aYKSm+ie8yVWBMTlqot4lCfBcOx74= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=DjyU8Ohi; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=IrdM9kjn; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="DjyU8Ohi"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="IrdM9kjn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1766449663; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cXRs2qyfIzNDHmuCaHGnowy87ug3QZOuT1wT+8nim0Y=; b=DjyU8OhiS5AEVoTvy76Fw0cElkwCxvNMfZq5KvlTR3V8ZwPzeEO3vhaKwCmOoppNXIiHUF 8rPDfG4PegJ0QOZZfd7DwtzS9k+E+BcB/EKdglW9JCU1PEG6N91Nl0Ry5h8vqu/+GbLxTw yIYujhpbe/3up4vWv/2G7gVsAODsL00= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-363-yeoSIQkjMWC0YKWMsVKJgA-1; Mon, 22 Dec 2025 19:27:42 -0500 X-MC-Unique: yeoSIQkjMWC0YKWMsVKJgA-1 X-Mimecast-MFC-AGG-ID: yeoSIQkjMWC0YKWMsVKJgA_1766449662 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-4f1dea13d34so101451891cf.1 for ; Mon, 22 Dec 2025 16:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1766449661; x=1767054461; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:from:to :cc:subject:date:message-id:reply-to; bh=cXRs2qyfIzNDHmuCaHGnowy87ug3QZOuT1wT+8nim0Y=; b=IrdM9kjnjj+DeW4WMpWOKN1BMYOQf9xBKdddAIY9zpF+WBRaHpL82yz8yGupeirsft Ey0lR6wVmxbSF3GOuDmSLX2vSejABXhGtl4uMoh6FKDPoOBohhWagbY+ps6QTgXRA27r vicgKOksyXbTu+EYIbJlA7qKcWywy1F/6pYjQndNmxTgdAfZiwcS88xV9rSFNcLZ/wvo BJ9KUoS/cOX1njVCJo5iIQ7IlIz1V5T7UPn2AFd43U85hIvuw1bC25E6dpV+e34d7t7L +wsfofRJYlSNlL+wtAW6Xmh/k11PtY8tgVJmRteHfW8tJKhhXs1+uZCwCH87zNyd8jVo EsGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766449661; x=1767054461; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=cXRs2qyfIzNDHmuCaHGnowy87ug3QZOuT1wT+8nim0Y=; b=BOGMtLTWm6ITdt2Gp2tZM83GFwQ8W+uoooszUbiNmaYz7PgHDCWAP0NHGTgEW+S/kr gy/eWHAtPXrO5cZCFVC9zddRh5inq3Iy/Axp8bwhDOP9P4eGMlbnlP/N/nSx2EH2VYF4 DtBA1UJVOvxPW0SU0xN1K9ojnOlO1MUcoez//UZluwScCwcqqs60OajQIaKhYLS+bSa4 Aau6TtfTrBsEFs9HD/mLzslIlOsKhDPkyuVL4uDlpsPkG4NewFFmqsEF/h8BR9B2KdA8 Q87CogSe5wMRoryKR9y0thyTI8Ds7S8Cexp4HG6f2BNG5hwZdvoFk88R0px12RqLsZ24 Ldkg== X-Forwarded-Encrypted: i=1; AJvYcCW+hXd+XoCKZSk6PIt2fQh3Rdlh2GnCQv5RTqtDgThTXrC/W88MSL/NyDpjZs5SNmMycjOUYAc+6tONr0I=@vger.kernel.org X-Gm-Message-State: AOJu0YwfOv8OVv/x49R3lWj/bwZvK7Q+VDddS5yM5+dB2vNzQDHjp8kK 0ZOr89uQR/ncnIlXdvMDeKysntG/uXf+dIayMs6jIwxnyKR51OkBmYaqGLi8T/Vd01XKgiGmn7B gpi+MJnOYBMpNjKVfgtxGe507Od0F66+H5XJSeoJXnqAWqAehI6hVtVUCbnX1qLlVKWh+CguYwg == X-Gm-Gg: AY/fxX7b4uM5FXVpzX4yODfGY+To0UzR0YEep2uKjlZ4YaKtsmSTJW36OHuE1bmVQtR iBWhKG0E0uv18AMQl3dozebBY527e6tR/og65j2YWGL3PPwSVkpjPbR0X4xXaT3zH3ECV3YoHvb UmMvnlDI2Qk68kzIgicIIIz1K6Lb1Rp4CxWRtGWBMapJdhrCQazjghCt6KWbSV8ZO1QF8i5pSIE yt+knVL9xOpq9URMTl1+UDyXolxNKTRBxfGdxVR+BKYQvjyNiJDDWt5p1obW9XFOwtoQs4KZodO zsoDvdqHQRtV0x8J8bvHejmDWRsEuHB9uc9Wt7LPcPyNCUdquNdAHwlVDsKQ0wh2mZrx6ox5HXs c9Q9DjO0KgrdMNCXY6nYsu7KCP77V5Tjc0t8fIgG3QrgBSnl49E8XjLXM X-Received: by 2002:ac8:5a95:0:b0:4ed:42a2:1293 with SMTP id d75a77b69052e-4f4abcd29eamr193353061cf.1.1766449661552; Mon, 22 Dec 2025 16:27:41 -0800 (PST) X-Google-Smtp-Source: AGHT+IFrzWtubWjAF1u/EJ9vYcxTmiLn9Z+SvzOhgqYSA/9Y3T9PwdKbN3Fyhw+1EEWjGfWddqEDkw== X-Received: by 2002:ac8:5a95:0:b0:4ed:42a2:1293 with SMTP id d75a77b69052e-4f4abcd29eamr193352861cf.1.1766449661107; Mon, 22 Dec 2025 16:27:41 -0800 (PST) Received: from ?IPV6:2601:600:947f:f020:85dc:d2b2:c5ee:e3c4? ([2601:600:947f:f020:85dc:d2b2:c5ee:e3c4]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-88d9a254849sm94586076d6.44.2025.12.22.16.27.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Dec 2025 16:27:40 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <8178bbf3-4a9d-4add-93bb-2ebd4dc03e9f@redhat.com> Date: Mon, 22 Dec 2025 19:27:38 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: clocksource: Reduce watchdog readout delay limit to prevent false positives To: Thomas Gleixner , LKML Cc: Daniel J Blueman , "Paul E. McKenney" , John Stultz , Peter Zijlstra , Dave Hansen , Tony Luck , Borislav Petkov , Stephen Boyd , Scott Hamilton References: <87bjjxc9dq.ffs@tglx> Content-Language: en-US In-Reply-To: <87bjjxc9dq.ffs@tglx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/17/25 12:21 PM, Thomas Gleixner wrote: > The "valid" readout delay between the two reads of the watchdog is larger > than the valid delta between the resulting watchdog and clocksource > intervals, which results in false positive watchdog results. > > Assume TSC is the clocksource and HPET is the watchdog and both have a > uncertainty margin of 250us (default). The watchdog readout does: > > 1) wdnow = read(HPET); > 2) csnow = read(TSC); > 3) wdend = read(HPET); > > The valid window for the delta between #1 and #3 is calculated by the > uncertainty margins of the watchdog and the clocksource: > > m = 2 * watchdog.uncertainty_margin + cs.uncertainty margin; > > which results in 750us for the TSC/HPET case. > > The actual interval comparison uses a smaller margin: > > m = watchdog.uncertainty_margin + cs.uncertainty margin; > > which results in 500us for the TSC/HPET case. > > That means the following scenario will trigger the watchdog: > > Watchdog cycle N: > > 1) wdnow[N] = read(HPET); > 2) csnow[N] = read(TSC); > 3) wdend[N] = read(HPET); > > Assume the delay between #1 and #2 is 100us and the delay between #1 and > #3 is within the 750us margin, i.e. the readout is considered valid. > > Watchdog cycle N + 1: > > 4) wdnow[N + 1] = read(HPET); > 5) csnow[N + 1] = read(TSC); > 6) wdend[N + 1] = read(HPET); > > If the delay between #4 and #6 is within the 750us margin then any delay > between #4 and #5 which is larger than 600us will fail the interval check > and mark the TSC unstable because the intervals are calculated against the > previous value: > > wd_int = wdnow[N + 1] - wdnow[N]; > cs_int = csnow[N + 1] - csnow[N]; > > Putting the above delays in place this results in: > > cs_int = (wdnow[N + 1] + 610us) - (wdnow[N] + 100us); > -> cs_int = wd_int + 510us; > > which is obviously larger than the allowed 500us margin and results in > marking TSC unstable. > > Fix this by using the same margin as the interval comparison. If the delay > between two watchdog reads is larger than that, then the readout was either > disturbed by interconnect congestion, NMIs or SMIs. > > Fixes: 4ac1dd3245b9 ("clocksource: Set cs_watchdog_read() checks based on .uncertainty_margin") > Reported-by: Daniel J Blueman > Signed-off-by: Thomas Gleixner > Link: https://lore.kernel.org/lkml/20250602223251.496591-1-daniel@quora.org/ > --- > kernel/time/clocksource.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > --- a/kernel/time/clocksource.c > +++ b/kernel/time/clocksource.c > @@ -252,7 +252,7 @@ enum wd_read_status { > > static enum wd_read_status cs_watchdog_read(struct clocksource *cs, u64 *csnow, u64 *wdnow) > { > - int64_t md = 2 * watchdog->uncertainty_margin; > + int64_t md = watchdog->uncertainty_margin; > unsigned int nretries, max_retries; > int64_t wd_delay, wd_seq_delay; > u64 wd_end, wd_end2; > @@ -285,7 +285,7 @@ static enum wd_read_status cs_watchdog_r > * watchdog test. > */ > wd_seq_delay = cycles_to_nsec_safe(watchdog, wd_end, wd_end2); > - if (wd_seq_delay > md) > + if (wd_seq_delay > 2 * md) > goto skip_test; > } > I believe the 2nd hunk isn't needed.     T1 = read(HPET);     T2 = read(TSC);     T3 = read(HPET);     T4 = read(HPET);     wd_delay = T3 - T1 <= md +  cs->uncertainty_margin     wd_seq_delay = T4 - T3 > 2*md wd_delay should be > wd_seq_delay. Here they are comparing about the same threshold assuming that cs has the same uncertainty margin as the watchdog. The thresholds comparing wd_delay and wd_seq_delay before commit 4ac1dd3245b9 were WATCHDOG_MAX_SKEW and WATCHDOG_MAX_SKEW/2. So I would suggest keeping the (wd_seq_delay > md) check. Cheers, Longman