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 8CB99ECE564 for ; Tue, 10 Sep 2024 12:28:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 045668D0060; Tue, 10 Sep 2024 08:28:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F36898D0056; Tue, 10 Sep 2024 08:28:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DFDE08D0060; Tue, 10 Sep 2024 08:28:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C23988D0056 for ; Tue, 10 Sep 2024 08:28:58 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6D32F80195 for ; Tue, 10 Sep 2024 12:28:58 +0000 (UTC) X-FDA: 82548757956.10.418413D Received: from pegase2.c-s.fr (pegase2.c-s.fr [93.17.235.10]) by imf28.hostedemail.com (Postfix) with ESMTP id 26BA3C0020 for ; Tue, 10 Sep 2024 12:28:55 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.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=1725971233; 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=8VxsrLT/QU3eeCMvq72eHzanrq1kr07NfmDvdcwgpVU=; b=AK7hXxySPSo3ZntFl2ZzDap6WbPxLTshuzHRWRCHxPRJ2/GuWjS65BIH/hS3U7fmgGpdMK fCw7c78vpMIjFMfzYpjKh7eGPbD0tTDA76ZY6jgWXjdwFGqerJOfBhH3663vKnbzPJxEkn CmB2CYc7BN5MuGTnKmv6XiBujkdv6/g= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725971233; a=rsa-sha256; cv=none; b=4a4ku8iUswLL0aG7b6NPZpfu5Y/rokaIDPvVqj58HupQrMaffbUCuzNNsDbXlZHiEy9lWs uHCZIYCnolfkNW+MVhRteu/E++aOsHTPpMrmc1JKgZmEW0JFg7Zmybu+VcE/EIp78nTIFf VQNeQYewps2j0wdq0ANnAGXFoq8YpjI= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.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 4X330Q0FPrz9sPd; Tue, 10 Sep 2024 14:28: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 g4B1QPtPZwoU; Tue, 10 Sep 2024 14:28:53 +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 4X330P6NX8z9rvV; Tue, 10 Sep 2024 14:28:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id C726F8B770; Tue, 10 Sep 2024 14:28:53 +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 r9qBl1ofIMM4; Tue, 10 Sep 2024 14:28:53 +0200 (CEST) Received: from [192.168.232.177] (unknown [192.168.232.177]) by messagerie.si.c-s.fr (Postfix) with ESMTP id EBF1B8B766; Tue, 10 Sep 2024 14:28:52 +0200 (CEST) Message-ID: <2234a5e1-5926-4b2d-a8f2-c780bf374a27@csgroup.eu> Date: Tue, 10 Sep 2024 14:28:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/9] x86: vdso: Introduce asm/vdso/page.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: <20240903151437.1002990-1-vincenzo.frascino@arm.com> <20240903151437.1002990-4-vincenzo.frascino@arm.com> <11527a80-7453-4624-b406-e88c5692b015@app.fastmail.com> <8868ef2c-6bfb-4ab7-ac5e-640e05658ee1@app.fastmail.com> Content-Language: fr-FR From: Christophe Leroy In-Reply-To: <8868ef2c-6bfb-4ab7-ac5e-640e05658ee1@app.fastmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: y38y9qwwrz3gcjdzjj468yad1u1mgpbo X-Rspamd-Queue-Id: 26BA3C0020 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1725971335-56000 X-HE-Meta: U2FsdGVkX1/NzAieM+j2zpJhGDX8fSlNRnOGqV/uEup6TU3aejVI2gMreKiuwgx5gzYxisamlZiXgBjrOu2SnDX3rStg5tugezTNcf79HrdAIm6xDgH+X6mIq1XFhbrcBE8109cX42BuI1OADKKDQrKL7IGjeeE3r0jrjvYAvGfWsWTg3IQq9M7kufWjJjlt8VD2q5KbL0dWCrtziYdAQP+pl4vbUQuziyYv5Yi7pfW/ZMWrOHYYKZcQIo6Jt21rH4MrqFgN3Rgohtz8LC34wbGoIzICepidrpdVOQgqQ1cnoS6sS/hvuHY+2w1C0x96KuPPosD4iB4gI6nxcC1+/OTKlvKH2ZhWjaq+s1Asv0eY9Iq2yveiNifvPUUwmv9sw5ShTVMSkAx00eo7gjD7YZp9fnIM2vAb2cPu18UvluIvwK6PzD0PCOAGoHfSzB8Y16jnMg7Q8zsBQc7K6qrsMrcGMBFjo2lLZoorQqTwXtxd29LI6hHn5W/n/tXjayTMXbjeVo77Y/9h6MO/+5TxwpKWIjPPd1WVGKZ213KoS+9D/xYqxdUbB/Q0fgMMlwcHRKjmDGqS2ieTEWJaeFKCn/Xq+2Y7wSp0kVzp8NeqwNtpdxWUS/qxoelACRYT+T3+vdFKqznhW9NkUHdsFmacA66QDJtsC+qBmsnhJIhDwsUDaA8hD+Bekz66P6H0mdBdzxdwNawuCNGHNuDSiuf+ZjnpKSQwiMOFq0NJUJZypR8ggQB2icga2PgwACeenhDTIskW59Tf4PZzbYPaKKZ0eOgiKk1K7FccaO5FVuPh9C23SUSqWg0fbWng/g71BMDgdbfp20/2Y6kbLj4cfHU06s32O/Sw40QZlS9jLyJO/rh4N52/T7Y4p+tqQo0OUQioleEzWTfiCGX/DWlgJQT2Vxcl6qKRYARIg5wrRLCyEDDaM5VqGuvmVNFjYKCsTXQCKXiP7vBjgez2Lkh/+Ib +Rpu7xy7 GuWwAnoPNW02vrZ8VVgbFCedT127J08I2wNsj3Ju9KgnMT/tC2rm5xk+vvWebK6V/YXst4q/nGGNkEdH/SWDl41W0OuHgyYPH25QbMCFZAplMLPN3H3zuCnmSftAkFZbgp7BWAOIF/IS7pb8= 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 08/09/2024 à 22:48, Arnd Bergmann a écrit : > On Fri, Sep 6, 2024, at 18:40, Christophe Leroy wrote: >> Le 06/09/2024 à 21:19, Arnd Bergmann a écrit : >>> On Fri, Sep 6, 2024, at 11:20, Vincenzo Frascino wrote: > >>>> Looking at the definition of PAGE_SIZE and PAGE_MASK for each architecture they >>>> all depend on CONFIG_PAGE_SHIFT but they are slightly different, e.g.: >>>> >>>> x86: >>>> #define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT) >>>> >>>> powerpc: >>>> #define PAGE_SIZE (ASM_CONST(1) << PAGE_SHIFT) >>>> >>>> hence I left to the architecture the responsibility of redefining the constants >>>> for the VSDO. >>> >>> ASM_CONST() is a powerpc-specific macro that is defined the >>> same way as _AC(). We could probably just replace all ASM_CONST() >>> as a cleanup, but for this purpose, just remove the custom PAGE_SIZE >>> and PAGE_SHIFT macros. This can be a single patch fro all >>> architectures. >>> >> >> I'm not worried about _AC versus ASM_CONST, but I am by the 1UL versus 1. >> >> >> This can be a problem on 32 bits platforms with 64 bits phys_addr_t > > But that would already be a bug if anything used this, however > none of them do. The only instance of an open-coded > > #define PAGE_SIZE (1 << PAGE_SHIFT) > > is from openrisc, but that is only used inside of __ASSEMBLY__, for > the same effect as _AC(). Maybe I was not clear enough. The problem is not with PAGE_SHIFT but with PAGE_MASK, and that's what I show with my exemple. If take the definition from ARM64 (which is the same as several other artchitectures): #define PAGE_SIZE (_AC(1, UL) << PAGE_SHIFT) #define PAGE_MASK (~(PAGE_SIZE-1)) PAGE_SHIFT is 12 PAGE_SIZE is then 4096 UL PAGE_MASK is then 0xfffff000 UL So if I take the probe() in drivers/uio/uio_pci_generic.c, it has: uiomem->addr = r->start & PAGE_MASK; uiomem->addr is a phys_addr_t r->start is a ressource_size_t hence a phys_addr_t And phys_addr_t is defined as: #ifdef CONFIG_PHYS_ADDR_T_64BIT typedef u64 phys_addr_t; #else typedef u32 phys_addr_t; #endif On a 32 bits platform, UL is unsigned 32 bits, so the r->start & PAGE_MASK will and r->start with 0x00000000fffff000 That is wrong. That's the reason why powerpc does not define PAGE_MASK like ARM64 but defines PAGE_MASK as: (~((1 << PAGE_SHIFT) - 1)) When using 1 instead of 1UL, PAGE_MASK is still 0xfffff000 but it is a signed constant, so when it is anded with an u64, it gets signed-extended to 0xfffffffffffff000 which gives the expected result. That's what I wanted to illustrate with the exemple in my previous message. The function f() was using the signed PAGE_MASK while function g() was using the unsigned PAGE_MASK: 00000000 : 0: 54 84 00 26 clrrwi r4,r4,12 4: 4e 80 00 20 blr 00000008 : 8: 54 84 00 26 clrrwi r4,r4,12 c: 38 60 00 00 li r3,0 10: 4e 80 00 20 blr Function f() returns the given u64 value with the 12 lowest bits cleared Function g() returns the given u64 value with the 12 lowest bits cleared and the 32 highest bits cleared as well, which is unexpected. Christophe