Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1900888ybv; Fri, 14 Feb 2020 07:58:16 -0800 (PST) X-Google-Smtp-Source: APXvYqyO62JzLA5rm+IyhZoQHd/kkP3tPKt7zwxpE9d+AqZWB/6FlGaHOAXFelcYZVCe3GsyQWMU X-Received: by 2002:a54:450d:: with SMTP id l13mr2355451oil.117.1581695896299; Fri, 14 Feb 2020 07:58:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581695896; cv=none; d=google.com; s=arc-20160816; b=SGTy3lbuNAHB8qTTZUIlbgs1O6Avo/Bnl/mVduOopH9vBtNin+TtyXjCFJN1IIjUGA G0Z3Yno7qJmqmgnybrUSyx6t6luZ3C5ObdD8tEoWkfm5+/y6vAbFcWKO6GQczCqEhAUl FNT7f5yCGnOodUyrOKf/ox2yzGv9ClFlCH0tQZqQhJAHwDm4NZEjv3EbQG01NNenitFd jWdBVs7LP6bOqIkJ05PnVZwqg0DhJEuTHXn202Bjn2AiqgVUUId11avJXq0+AixmR7vs p0JlRY90v4QUuvOKknQi4Q7wwSSlJLyrvuGXWRu8TKMCtERQAuLFk7J5ygbewylmtZVO 9viQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=9NNt98dn/4w67K+BKnYtX1dRpZEpF+AVPR0ZD6vbzxs=; b=dJYg1zh1uThyXvXHM8I0TOwrBrhmdi1y5lrp8ZpSg/mT+zeh0T0ZAR2IQjxM8z1Tlp XAk5DfH/8HRtDr4mhnElI3rtqObMd28m4rcgk7/pTyPpV2iheTlF7txPSIvheTEoy8w4 Ecj79EJT//v4PS0oMXNSyaNO/9MOWCvPvHYKCoFWzpr7S7/7w/lhFH/Bk2zDKk6In2zy mH7jFywOH7w4zyeQ/NHz+pGUNXQVR9uHhrknV2xKwTlMRICPjiwufMLdp29Dl7DBnhJ9 A0TnZCvQYuTd38eKmtm36GUTlKby+C5k995bCKhA/Y7zpUT4WbRqiVP9a4WIB3vFdDjv kduA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a92si3018967otc.294.2020.02.14.07.58.04; Fri, 14 Feb 2020 07:58:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388438AbgBNP6C (ORCPT + 99 others); Fri, 14 Feb 2020 10:58:02 -0500 Received: from foss.arm.com ([217.140.110.172]:35872 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388237AbgBNP5r (ORCPT ); Fri, 14 Feb 2020 10:57:47 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5E40D328; Fri, 14 Feb 2020 07:57:46 -0800 (PST) Received: from localhost (e108754-lin.cambridge.arm.com [10.1.198.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F3AAF3F68E; Fri, 14 Feb 2020 07:57:45 -0800 (PST) Date: Fri, 14 Feb 2020 15:57:44 +0000 From: Ionela Voinescu To: Thomas Gleixner Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com, maz@kernel.org, suzuki.poulose@arm.com, sudeep.holla@arm.com, lukasz.luba@arm.com, valentin.schneider@arm.com, rjw@rjwysocki.net, peterz@infradead.org, mingo@redhat.com, vincent.guittot@linaro.org, viresh.kumar@linaro.org, linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org Subject: Re: [PATCH v3 7/7] clocksource/drivers/arm_arch_timer: validate arch_timer_rate Message-ID: <20200214155744.GA8784@arm.com> References: <20200211184542.29585-1-ionela.voinescu@arm.com> <20200211184542.29585-8-ionela.voinescu@arm.com> <87mu9mgg41.fsf@nanos.tec.linutronix.de> <20200214154525.GA21875@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200214154525.GA21875@arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 14 Feb 2020 at 15:45:25 (+0000), Ionela Voinescu wrote: > Hi Thomas, > > On Friday 14 Feb 2020 at 01:35:58 (+0100), Thomas Gleixner wrote: > > Ionela Voinescu writes: > > > > > From: Valentin Schneider > > > > > > Using an arch timer with a frequency of less than 1MHz can result in an > > > incorrect functionality of the system which assumes a reasonable rate. > > > > > > One example is the use of activity monitors for frequency invariance > > > which uses the rate of the arch timer as the known rate of the constant > > > cycle counter in computing its ratio compared to the maximum frequency > > > of a CPU. For arch timer frequencies less than 1MHz this ratio could > > > end up being 0 which is an invalid value for its use. > > > > > > Therefore, warn if the arch timer rate is below 1MHz which contravenes > > > the recommended architecture interval of 1 to 50MHz. > > > > > > Signed-off-by: Ionela Voinescu > > > > So this patch is from Valentin. Where is his Signed-off-by? > > > > Yes, sorry about this. This was based on a diff that Valentin provided > in v2. I'll change the author as agreed at: > https://lore.kernel.org/lkml/20200212103249.GA19041@arm.com/ > > > > > > > +static int validate_timer_rate(void) > > > +{ > > > + if (!arch_timer_rate) > > > + return -EINVAL; > > > + > > > + /* Arch timer frequency < 1MHz can cause trouble */ > > > + WARN_ON(arch_timer_rate < 1000000); > > > > This does not make sense to me. If the rate is out of bounds then why > > warn an just continue instead of making it fail? > > > > Because it's not a hard restriction, it's just atypical for the rate to > be below 1Mhz. The spec only mentions a typical range of 1 to 50MHz and > the warning is only here to flag a potentially problematic rate, below > what is assumed typical in the spec. > > In [1], where I'm actually relying on arch_timer_rate being higher than > than 1/SCHED_CAPACITY_SCALEĀ² of the maximum frequency, I am making it > fail, as, for that scenario, it is a hard restriction. > > > + * We use a factor of 2 * SCHED_CAPACITY_SHIFT -> SCHED_CAPACITY_SCALEĀ² > + * in order to ensure a good resolution for arch_max_freq_scale for > + * very low arch timer frequencies (up to the KHz range which should be > + * unlikely). > + */ > + ratio = (u64)arch_timer_get_rate() << (2 * SCHED_CAPACITY_SHIFT); > + ratio = div64_u64(ratio, max_freq_hz); > + if (!ratio) { > + pr_err("System timer frequency too low.\n"); > + return -EINVAL; > + } > + > > [1] https://lore.kernel.org/lkml/89339501-5ee4-e871-3076-c8b02c6fbf6e@arm.com/ I've mistakenly referenced a bad link ^ It was supposed to be: [1] https://lore.kernel.org/lkml/20200211184542.29585-7-ionela.voinescu@arm.com/ Thanks, Ionela.