Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1977822pxb; Fri, 5 Mar 2021 04:37:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJwFtTumHBcbgDYep/La8RJ7GL7g1Rofxm4//+cOFJ1llIyKb8ejayyJw2qltHi+dxQVTjOU X-Received: by 2002:aa7:da04:: with SMTP id r4mr1262141eds.343.1614947841785; Fri, 05 Mar 2021 04:37:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614947841; cv=none; d=google.com; s=arc-20160816; b=eSJXOWKXfEmvZtgQpjfDWWOQxI7tvtX0CQ8J/55bZWhEJPgx45NrP8snCRUJoAXhnq F+vWnV+iYGmUUNWx0FGU7DyHdhbyK1gatKulxdDajwRhXS/ZsvlFiMCXg9qsXMJzsYHG YT1MV6qFYESd36Qik30EAQcsdHmzDIQqo25GJC1YjwSmkPL3OoxeCtOYadvLWfByQOxc yEo4gnychIhSESP7jp0g7uz0kwq7wuP+HX3vhQbTTH+SBjv/2OpunD/lA3DjxcYYDcLz TuefV0R2j/+MXtcp77DY1f2eLlssp8gMIFkG/ab2m4EP4egxHMTtwFzx3uDj0oK4iBOM IwGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=7lb/8QwciEWeSbSocxEsgh76OjAvYOFeGjtTmlHZ6B8=; b=lgn6vGJg1CXCoDeuO6wdjy0OKKBQNVlZ9T9PhOa1A6BS4HAaCCWjmBgMMLHB69q8yB QP9Ad/vZjlwC7eFiBznQYo3Av0/KtD+lRfS+PKFn1CkRzA/sFDig67G9Fgztb6uM3ZSO f+ofsVsF2LFY8EzrdQFk25vcvSHZuJR5vj7ULHqW8hS+yr4W1g/LKPAH+EHOU/gbVdhd HvOddCEoktAKUbAXjI2QoqGWYoNSHEhdyOV3WfeUdnJwaLQWsIsacdg2nQhi7OzBrBkv inNbhCnFzii6RXKLjm/t947YkiViTy23jDbtEWgWlupWm5I4HiY4m0qNLnfFONjHYlEN KBIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=sWUNXC38; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z18si1214739ejx.409.2021.03.05.04.36.59; Fri, 05 Mar 2021 04:37:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=sWUNXC38; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232461AbhCEMgC (ORCPT + 99 others); Fri, 5 Mar 2021 07:36:02 -0500 Received: from mail.kernel.org ([198.145.29.99]:47560 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231681AbhCEMfb (ORCPT ); Fri, 5 Mar 2021 07:35:31 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 805E16501D; Fri, 5 Mar 2021 12:35:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1614947731; bh=R2Hk4Rmtt0eWvMIFSFgPzxniXaHejw+vT07E/5xAx4c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sWUNXC38dgUZTqWcAdKYiOID8nUj1C/jG58DzsmXBtKVP75ZiKZAh6q5O08GjZTjX cHT5V0pMwcjYGqn4TBZdWDs21rozrbhYU+BEib1/zEiDGhHrRkRTV43SRLqLJfau8Q D0dKQFoPkDi+latvhXx9r3pFUvhB8lVgPdvQq6dE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Juri Lelli , "Luis Claudio R. Goncalves" , Daniel Bristot de Oliveira , "Peter Zijlstra (Intel)" , Ingo Molnar , Sasha Levin Subject: [PATCH 5.4 56/72] sched/features: Fix hrtick reprogramming Date: Fri, 5 Mar 2021 13:21:58 +0100 Message-Id: <20210305120900.082486268@linuxfoundation.org> X-Mailer: git-send-email 2.30.1 In-Reply-To: <20210305120857.341630346@linuxfoundation.org> References: <20210305120857.341630346@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Juri Lelli [ Upstream commit 156ec6f42b8d300dbbf382738ff35c8bad8f4c3a ] Hung tasks and RCU stall cases were reported on systems which were not 100% busy. Investigation of such unexpected cases (no sign of potential starvation caused by tasks hogging the system) pointed out that the periodic sched tick timer wasn't serviced anymore after a certain point and that caused all machinery that depends on it (timers, RCU, etc.) to stop working as well. This issues was however only reproducible if HRTICK was enabled. Looking at core dumps it was found that the rbtree of the hrtimer base used also for the hrtick was corrupted (i.e. next as seen from the base root and actual leftmost obtained by traversing the tree are different). Same base is also used for periodic tick hrtimer, which might get "lost" if the rbtree gets corrupted. Much alike what described in commit 1f71addd34f4c ("tick/sched: Do not mess with an enqueued hrtimer") there is a race window between hrtimer_set_expires() in hrtick_start and hrtimer_start_expires() in __hrtick_restart() in which the former might be operating on an already queued hrtick hrtimer, which might lead to corruption of the base. Use hrtick_start() (which removes the timer before enqueuing it back) to ensure hrtick hrtimer reprogramming is entirely guarded by the base lock, so that no race conditions can occur. Signed-off-by: Juri Lelli Signed-off-by: Luis Claudio R. Goncalves Signed-off-by: Daniel Bristot de Oliveira Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lkml.kernel.org/r/20210208073554.14629-2-juri.lelli@redhat.com Signed-off-by: Sasha Levin --- kernel/sched/core.c | 8 +++----- kernel/sched/sched.h | 1 + 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 7841e738e38f..2ce61018e33b 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -254,8 +254,9 @@ static enum hrtimer_restart hrtick(struct hrtimer *timer) static void __hrtick_restart(struct rq *rq) { struct hrtimer *timer = &rq->hrtick_timer; + ktime_t time = rq->hrtick_time; - hrtimer_start_expires(timer, HRTIMER_MODE_ABS_PINNED_HARD); + hrtimer_start(timer, time, HRTIMER_MODE_ABS_PINNED_HARD); } /* @@ -280,7 +281,6 @@ static void __hrtick_start(void *arg) void hrtick_start(struct rq *rq, u64 delay) { struct hrtimer *timer = &rq->hrtick_timer; - ktime_t time; s64 delta; /* @@ -288,9 +288,7 @@ void hrtick_start(struct rq *rq, u64 delay) * doesn't make sense and can cause timer DoS. */ delta = max_t(s64, delay, 10000LL); - time = ktime_add_ns(timer->base->get_time(), delta); - - hrtimer_set_expires(timer, time); + rq->hrtick_time = ktime_add_ns(timer->base->get_time(), delta); if (rq == this_rq()) { __hrtick_restart(rq); diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index e10fb9bf2988..4e490e3db2f8 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -973,6 +973,7 @@ struct rq { call_single_data_t hrtick_csd; #endif struct hrtimer hrtick_timer; + ktime_t hrtick_time; #endif #ifdef CONFIG_SCHEDSTATS -- 2.30.1