From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 273B3C4338F for ; Mon, 23 Aug 2021 14:56:17 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DB9C6610D1 for ; Mon, 23 Aug 2021 14:56:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org DB9C6610D1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tKhvErpnfP3Vnxi30JWinQLxKV8UomQjCgB7UuzBwng=; b=KqMxqGU0eDDgkQ RtgI9oIQNy3LuOdqwGWj5OrI7Nn1h8vLP8PHV3CipR3qb84icoNkDUBEtO2sx1lRregotqhZQBM6o E/A4O2rvQ4qiHIYkTbjym1X/AKoaPKASaxie8ajyvUK2z0FUJNsTL5Fth+z76gVMuaf74Tnz+9xGD dXhgPdh1yaAVxGxHSVOuYcIVco+uTFo3tFImJiWXriFwet+rSas3q7rLLNvQjr9i/W7e9j9G2SquI yjG1dZdhVNkrapZNmX+7w+aZNciVzG8my/SWwAVyX+pcWIxEvkTOWxkeRplUZKLQUDzw1l7uZvbhp 9lqzTd45uTJwtkIX8OKQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIBLN-00HJrr-GO; Mon, 23 Aug 2021 14:54:33 +0000 Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mIBLH-00HJp7-2T for linux-arm-kernel@lists.infradead.org; Mon, 23 Aug 2021 14:54:30 +0000 Received: by mail-pj1-x1034.google.com with SMTP id u13-20020a17090abb0db0290177e1d9b3f7so18859405pjr.1 for ; Mon, 23 Aug 2021 07:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=obYIRXgSO0GwMLAUweSJ4HRzBn9VIUKmHS4nKha0Yl8=; b=bbk4GWgPPVzX1+EljNQUw3WHDke4VhXX2zo97ZY03BtE/zkP0CaBqFvFUOeYKzSIW/ vQ9ix5lmk1Y0xmm1P/eoFo+W4Ry2krg9+Zapl5yEOz9bex/fOD+m4RGcb+9s+xlvEM90 UcHhbCXBSA18pCEpoOO5K7/DONrpzmZM5ISRpR04WMhZkpYjzrgmnddot6zKIW9xtNgB 9U/5sT41az4VB2on6ufMHwVTr4MUxU5iF53QXJNhvRvfiptl5KmNgM50gGKzGESeM1Qs laQbCGGLbdQfoKCZsoxmtaG5j4NQCbl0q8MH+fMC8OlPGD18g+311U/PlVs1FD7hSkRk 7GLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=obYIRXgSO0GwMLAUweSJ4HRzBn9VIUKmHS4nKha0Yl8=; b=UY4rmiPrTTPTSz4OZKfGF3Etx9Swf++WNS3eBlzdatCwnnhve6NXO8mI4dhyf5ifcu h7dyK16OU+gP44tGbn+ZomLuH1MS8FIC1DFUHrTrsFS6kFn78ppBqw5tuJYIqefVJy9x BIO573USEj7kB6m4HalShbq23mgowREFb/xl+twB+Hu2SJyqieurq1cNT6S9Rxl3ypQg wDAVA5LIIwCMO3Bp6p4TEbDFjMkNENhCOhI18+3on+6DT+G3VlgNQZFmBqruvU/cVttA qaWduKeWOsY0CFwe2V8/8IPvw2J7v4BfdvWQlAxSJc3Ft1OX15FldUuP3bSitZhRvb6x 4c3A== X-Gm-Message-State: AOAM53226ufQd/cwa1GTiHmT8DzpyVaTFZhbwOhuf3AlTye3lv96kmF2 lkzNr/ZGHlGGDG/hO/6JUm+zFg== X-Google-Smtp-Source: ABdhPJz2e1DUUo1+QF/L15glM7FbjSy1ZU1B0V9RzZITuE0z8r6iPe0A5tl8hUYutzDTDoxWz1v00A== X-Received: by 2002:a17:902:b612:b029:12c:e9e5:b1bf with SMTP id b18-20020a170902b612b029012ce9e5b1bfmr29278818pls.54.1629730465884; Mon, 23 Aug 2021 07:54:25 -0700 (PDT) Received: from leoy-ThinkPad-X240s ([202.155.204.36]) by smtp.gmail.com with ESMTPSA id pc11sm19519859pjb.17.2021.08.23.07.54.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Aug 2021 07:54:25 -0700 (PDT) Date: Mon, 23 Aug 2021 22:54:17 +0800 From: Leo Yan To: "Russell King (Oracle)" Cc: James Clark , Arnaldo Carvalho de Melo , Mike Leach , Will Deacon , Peter Zijlstra , Adrian Hunter , Andi Kleen , Mark Rutland , Catalin Marinas , linux-perf-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Li Huafei , Jin Yao , Riccardo Mancini , Ingo Molnar , Namhyung Kim , Suzuki K Poulose , Mathieu Poirier , Alexander Shishkin , Jiri Olsa , John Garry , coresight@lists.linaro.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 3/3] perf auxtrace arm: Support compat_auxtrace_mmap__{read_head|write_tail} Message-ID: <20210823145417.GA169379@leoy-ThinkPad-X240s> References: <20210809112727.596876-1-leo.yan@linaro.org> <20210809112727.596876-4-leo.yan@linaro.org> <6ce4057a-57cf-501d-6449-2069cd00ba57@arm.com> <20210823133043.GF100516@leoy-ThinkPad-X240s> <20210823133918.GP22278@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210823133918.GP22278@shell.armlinux.org.uk> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210823_075427_232373_7D4B243F X-CRM114-Status: GOOD ( 37.89 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Russell, On Mon, Aug 23, 2021 at 02:39:18PM +0100, Russell King (Oracle) wrote: > On Mon, Aug 23, 2021 at 09:30:43PM +0800, Leo Yan wrote: > > On Mon, Aug 23, 2021 at 01:23:42PM +0100, James Clark wrote: [...] > > > For x86, it's possible to include tools/include/asm/atomic.h, but that doesn't > > > include arch/arm/include/asm/atomic.h and there are some other #ifdefs that might > > > make it not so easy for Arm. Just wondering if you considered trying to include the > > > existing one? Or decided that it was easier to duplicate it? > > > > Good finding! > > > > With you reminding, I recognized that the atomic operations for > > arm/arm64 should be improved for user space program. So far, perf tool > > simply uses the compiler's atomic implementations (from > > asm-generic/atomic-gcc.h) for arm/arm64; but for a more reliable > > implementation, I think we should improve the user space program with > > architecture's atomic instructions. > > No we should not. Sometimes, what's in the kernel is for the kernel's > use only, and not for userspace's use. That may be because what works > in kernel space does not work in userspace. > > For example, the ARMv6+ atomic operations can be executed in userspace > _provided_ they are only used on memory which has an exclusive monitor. > They can't be used on anything that is not "normal memory". Okay, IIUC, the requirement for "normal memory" and exclusive monitor should also apply on aarch64 for ldrex/strex, Load-Acquire and Store-Release instructions, etc. Otherwise, it's heavily dependent on the exclusive monitors outside the cache coherency domain (but this is out of the scopes for CPU). perf tool is very likely to map memory with "normal memory" but we cannot say it's always true. So I agree there have risk for exporting the aarch32/aarch64 atomic headers to user space. > Prior to > ARMv6, the atomic operations rely on disabling interrupts. That > facility is simply not available to userspace, so these must not be > made available to userspace. > > The same applies to bitops. > > We've been here before in the past, when the kernel headers were not > separated from the user ABI headers, and people would write programs > that included e.g. bitops.h on x86 because they had optimised bitops > code. This made the userspace programs very non-portable - without > re-implementing userspace versions of this stuff in every userspace > program that did this stuff. > > So no, having experienced the effects of this kind of thing in the > past, the kernel should _not_ export architecture specific code in > header files to userspace. > > Also, it should be pointed out that by doing so, you create a licensing > issue. If the code is GPLv2, and you build your program such that it > incorporates GPLv2 code, then if the userspace program is not GPLv2 > compliant, you have a licensing problem, and in effect the program > can be distributed. > > Please do not go down this route. Thanks a lot for the suggestion and quick response. Leo _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel