Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1726339pxa; Sun, 23 Aug 2020 14:03:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwWfGK8ujxjDW+HIU7ORXN2fX+xPXaMJZBJ3nr/F+8zhxVqWZTFZSHLgRbJccHb+xig1rJN X-Received: by 2002:a17:906:8286:: with SMTP id h6mr2691029ejx.341.1598216626741; Sun, 23 Aug 2020 14:03:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598216626; cv=none; d=google.com; s=arc-20160816; b=XYrEi7iQW1wEIVkhRb5Z2hCIDYz0HLVP110NPz8aWaLvL8AL7KY1ZfBL0JeWegPLLd KREdRkubQjSt0A8ya+WowpyIsUYHewInWcpAHTudyDef6CHoCcr2gZwDAVdutrE2dJL+ cZvwEMWeLKHjqSqtdoNoRUXNNarJqdN6mhhWdadrxSporTYvz6BbgrcV19oNas8pOZf+ vZAwHphkCrGQSNMFGCg+bUhqxnvrixnKJ2n58FExkmYzWta8IvP3YNNTN8mHraGeaNx5 UCqraxnmT3Iex6sREKwjYkseGKBZi7R9T5XAb8hT470Y+WS0kD+SsDWgailZBPvo5DMs XUGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=+lxS0trhnKgLBNkFJHc4XppCLnkEx0hog1t/TJbvaRA=; b=L9oJpEb6THEolq30VqeiEWec6ImVUCdAD7MGA4wgBbk9vomh3uM2YghOpK3arOzTmI yJUF3gb+MXlLZKyzJbX16ZChiSj5HdNeMPPcII3UmvOZ7o0GFDWe6HuT4gn7vCD8wxrS YsG274AGGo/5H1dg58vVUSWb3Mkh/J8TQnAb3O3Tvwwlsg1gxSzKCn5AtRicqS44jwgW x3otAbuOqTWIjaIpQ1aU23EvNgnEWH2mr8jUYfLjK0iFdJP9n9vC4X83vh1D/GmbiAjB oAuXw5AIqOlCAIZC0LFh4pTgPshWXNuTID3w/K6om7jtcoTGntdKD165dX3XGvfAYLCY Vm4A== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cc19si4996958edb.488.2020.08.23.14.02.46; Sun, 23 Aug 2020 14:03:46 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726788AbgHWUym (ORCPT + 99 others); Sun, 23 Aug 2020 16:54:42 -0400 Received: from mail.ispras.ru ([83.149.199.84]:51698 "EHLO mail.ispras.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725995AbgHWUyl (ORCPT ); Sun, 23 Aug 2020 16:54:41 -0400 Received: from monopod.intra.ispras.ru (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id 8315940A206F; Sun, 23 Aug 2020 20:54:38 +0000 (UTC) Date: Sun, 23 Aug 2020 23:54:38 +0300 (MSK) From: Alexander Monakov To: Len Brown cc: Liwei Song , Linux PM list , Linux Kernel Mailing List Subject: Re: [PATCH] tools/power turbostat: call pread64 in kernel directly In-Reply-To: Message-ID: References: <20200717060849.12469-1-liwei.song@windriver.com> <52f16995-6d2d-fa7d-ed5e-682db3461d03@windriver.com> User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I am not the original submitter, but I have answers and a proper patch :) On Fri, 21 Aug 2020, Len Brown wrote: > Re: offset size > > The offsets on this file are the MSR offsets. > What MSR are you trying to access at offset 0xc0010299? This MSR is particular is part of AMD RAPL (energy measurements) interface. > Re: pread vs pread64 > > If I take on faith that you have some kind of 32-bit execution > environment that makes pread into pread32 instead of pread64, and that > truncates an off_t to 32-bits from 64-bits, and it actually makes > sense to request a read at this large offset... The problem here stems from the backward compatibility in Glibc: off_t is 32-bit on 32-bit x86, unless compiled with -D_FILE_OFFSET_BITS=64. This macro should be used for all new code. Distros should enable it for all builds, but when one builds turbostat 'by hand', they hit the issue. > would we really have to invoke syscall() directly -- couldn't we > invoke pread64() directly? (eg. below) No, the proper fix is to pass -D_FILE_OFFSET_BITS=64 to the compiler. Here's the patch: ---8<--- From: Alexander Monakov Date: Sun, 23 Aug 2020 23:27:02 +0300 Subject: [PATCH] turbostat: build with _FILE_OFFSET_BITS=64 For compatibility reasons, Glibc off_t is a 32-bit type on 32-bit x86 unless _FILE_OFFSET_BITS=64 is defined. Add this define, as otherwise reading MSRs with index 0x80000000 and above attempts a pread with a negative offset, which fails. Signed-off-by: Alexander Monakov --- tools/power/x86/turbostat/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/power/x86/turbostat/Makefile b/tools/power/x86/turbostat/Makefile index 2b6551269e43..40ae44402eec 100644 --- a/tools/power/x86/turbostat/Makefile +++ b/tools/power/x86/turbostat/Makefile @@ -12,6 +12,7 @@ turbostat : turbostat.c override CFLAGS += -O2 -Wall -I../../../include override CFLAGS += -DMSRHEADER='"../../../../arch/x86/include/asm/msr-index.h"' override CFLAGS += -DINTEL_FAMILY_HEADER='"../../../../arch/x86/include/asm/intel-family.h"' +override CFLAGS += -D_FILE_OFFSET_BITS=64 override CFLAGS += -D_FORTIFY_SOURCE=2 %: %.c -- 2.26.2