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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8E668CCFA15 for ; Thu, 26 Sep 2024 05:52:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B24C6B0098; Thu, 26 Sep 2024 01:52:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 03B0F6B0099; Thu, 26 Sep 2024 01:52:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF80C6B009A; Thu, 26 Sep 2024 01:52:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BF46C6B0098 for ; Thu, 26 Sep 2024 01:52:00 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 39F0441133 for ; Thu, 26 Sep 2024 05:52:00 +0000 (UTC) X-FDA: 82605818400.04.6C8D451 Received: from pegase2.c-s.fr (pegase2.c-s.fr [93.17.235.10]) by imf16.hostedemail.com (Postfix) with ESMTP id 0BEBC180008 for ; Thu, 26 Sep 2024 05:51:56 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of christophe.leroy@csgroup.eu designates 93.17.235.10 as permitted sender) smtp.mailfrom=christophe.leroy@csgroup.eu; dmarc=pass (policy=quarantine) header.from=csgroup.eu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727329796; h=from:from:sender: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=ms/HAZ4RZWu3XyF1cBi5Js6GpQZcKBISZvSerwv3ZZQ=; b=Sr8Wxequo3ZuZ2emFf0rAUpUenpYfde7wYHmkLioHQUgB6/856UFizwbjTNrLlc0R5ryZA ep1UEvVW2mx+iY7yZy9x7VyEYguO+0LS+s1JEc73CR60EgVqDCcvXah0Fcb7yXvH2TNPsB WHDeyM7ZCO7TdkVdDjUpy0LZBgbee0A= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727329796; a=rsa-sha256; cv=none; b=Cikja2RzOxfM7yZhMSodvsvBCvUfyOqP88/TuePQqPLayg6tm7ljh0r6I15pv6XvjhQolj gP8CLmc1q+e9UWEPT6ScO7S3QHdZ8jRq1ex11yIRal8dIL3NmedTUjDNZP8KPCOmArGG1h Per5ZspKJcxUkJGKNq1K3ItphVf6G90= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of christophe.leroy@csgroup.eu designates 93.17.235.10 as permitted sender) smtp.mailfrom=christophe.leroy@csgroup.eu; dmarc=pass (policy=quarantine) header.from=csgroup.eu Received: from localhost (mailhub3.si.c-s.fr [172.26.127.67]) by localhost (Postfix) with ESMTP id 4XDjQy68Zfz9sSK; Thu, 26 Sep 2024 07:51:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from pegase2.c-s.fr ([172.26.127.65]) by localhost (pegase2.c-s.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIapQb6SH8TJ; Thu, 26 Sep 2024 07:51:54 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase2.c-s.fr (Postfix) with ESMTP id 4XDjQy50hbz9sRy; Thu, 26 Sep 2024 07:51:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 92DE98B76E; Thu, 26 Sep 2024 07:51:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id aQV3KcvF_OW9; Thu, 26 Sep 2024 07:51:54 +0200 (CEST) Received: from [172.25.230.108] (unknown [172.25.230.108]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 3E52B8B763; Thu, 26 Sep 2024 07:51:54 +0200 (CEST) Message-ID: Date: Thu, 26 Sep 2024 07:51:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/8] x86: vdso: Introduce asm/vdso/mman.h To: Arnd Bergmann , Vincenzo Frascino , linux-kernel@vger.kernel.org, Linux-Arch , linux-mm@kvack.org Cc: Andy Lutomirski , Thomas Gleixner , "Jason A . Donenfeld" , Michael Ellerman , Nicholas Piggin , Naveen N Rao , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Theodore Ts'o , Andrew Morton , Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers References: <20240923141943.133551-1-vincenzo.frascino@arm.com> <20240923141943.133551-2-vincenzo.frascino@arm.com> <626baa55-ca84-49ba-9131-c1657e0c0454@csgroup.eu> Content-Language: fr-FR From: Christophe Leroy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 0BEBC180008 X-Stat-Signature: rbkchhwr5t7cmqqjjch6bzc75n1ggfan X-HE-Tag: 1727329916-465535 X-HE-Meta: U2FsdGVkX1+B1NNO0U/xysoGy6ue0Lr7R1y1TMzBBoz0jwfjRkDbcnQ+HfN4QqlDRGjKsxCR30Ovvfcq3gJwDv6oCtMAhPbzXohJMldwkYoflVXsTWtNLj92z2ky+gEWPinag3thvNjNNPevSia0+FfRYhqW9pdmkoMUhDqiRWBmm4zMoYCVyoU7T4WLACkKBwL5Ky7HYTLFfv3JOOWoz3T474drG8Y+GjukGw1hl41O9cRFNxsWYcxfemlQWhZcC3bo14zKgTcnDewIPoKnlNCtS4tTOAJ89rIFuR6reITOxvVlnpXTK8lNU6ZWCYxtN1UXG0rW7W8Bw2itKngy8Wjd4EQfYvKF/OBWOgJysXOQ/ikL5/umPZoKyo+5X7tKwGB4IntHvNTbPjvqOXC9sMp1247FfT2EOvr+hayPjrstLIG1XFXN6VzYq0729C/5eHtps8v1jSgtLdqSNibwRP4+zC/u5ACI7KV5xFJ/JL824g9/GLYSxGKrV1n55MS1mhibHuZ4DH6NDENFIbXNG+jewOs73iCDFobAFBwEcShRYhrJNzYTewITDPE1Otd6AhIxEzC55dQeOcLa6VZIsRnTuCY2IAdHcNvvJtmVcdUTkjlkK66ynKGtS8TMVFhwLj49y/zUadiWbOal4ys/kgxxY45e64fOMnBdAHkYoSTvUXIpUlFpPjIQL9+Xg0047bB6gplXtrJERhZDoXlsItZcZYP6Oa3oWNvCGM9GKiE7g1eaaZMcAJQue86m8SY9hAdFfLneEIRIaPZrs6963f3k/RcK0NnYFeidTzTSafL5TXMaLVVjWvQWuROvN8PweEiPCdXJBxjskjNHU9XVjQneTI4fFtpYN5pGNt3HxR+z+adQ14yom5rUs0JEIUYq9YsQaG2ITRgsmqtOYuKnb7pgljZT+k/ukIpdnu5QQMyonhNY7XAEqVzyrJS0gG+M1z3HVYwmd2QpWQZuTG9 2KuZk53u Cu/M6lVKqlzlX3oNzmcwoNq11e9VkXYvqwIRauzlrzoB50p/JScR3Du/6UdThRVwvccS/8k0I3JIUeZPh/QPWjrGarrCnDsMHvcfXqtblmJ5OTDjHJ224GxT9EDIvoLiNzb6rRnbNFtaN6Ow= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Le 25/09/2024 à 23:23, Arnd Bergmann a écrit : > On Wed, Sep 25, 2024, at 06:51, Christophe Leroy wrote: >> Le 23/09/2024 à 16:19, Vincenzo Frascino a écrit : >>> @@ -0,0 +1,15 @@ >>> + >>> +/* SPDX-License-Identifier: GPL-2.0 */ >>> +#ifndef __ASM_VDSO_MMAN_H >>> +#define __ASM_VDSO_MMAN_H >>> + >>> +#ifndef __ASSEMBLY__ >>> + >>> +#include >>> + >>> +#define VDSO_MMAP_PROT PROT_READ | PROT_WRITE >>> +#define VDSO_MMAP_FLAGS MAP_DROPPABLE | MAP_ANONYMOUS >> >> I still can't see the point with that change. >> >> Today 4 architectures implement getrandom and none of them require that >> indirection. Please leave prot and flags as they are in the code. >> >> Then this file is totally pointless, VDSO code can include >> uapi/linux/mman.h directly. >> >> VDSO is userland code, it should be safe to include any UAPI file there. > > I think we are hitting an unfortunate corner case in the build > system here, based on the way we handle the uapi/ file namespace > in the kernel: > > include/uapi/linux/mman.h includes three headers: asm/mman.h, > asm-generic/hugetlb_encode.h and linux/types.h. Two of these > exist in both include/uapi/ and include/, so while building > kernel code we end up picking up the non-uapi version which > on some architectures includes many other headers. Right, and that's the reason why arm64 and powerpc guarded the content of asm/mman.h which an #ifndef BUILD_VDSO. Note that arm64 also has a similar workaround in asm/rwonce.h, brought by commit e35123d83ee3 ("arm64: lto: Strengthen READ_ONCE() to acquire when CONFIG_LTO=y") without explaination on why VDSO builds are excluded. > > I agree that moving the contents out of uapi/ into vdso/ namespace > is not a solution here because that removes the contents from > the installed user headers, but we still need to do something > to solve the issue. Should header inclusion be reworked so that only UAPI and VDSO pathes are looked for when including headers in VDSO builds ? > > The easiest workaround I see for this particular file is to > move the contents of arch/{arm,arm64,parisc,powerpc,sparc,x86}/\ > include/asm/mman.h into a different file to ensure that the > only existing file is the uapi/ one. Unfortunately this does > not help to avoid it regressing again in the future. Could we add a check in checkpatch.pl to ensure UAPI headers do not include headers that exist both in UAPI and non-UAPI space in the future ? Christophe