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 5F354C433F5 for ; Mon, 31 Jan 2022 13:59:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D9AB06B009A; Mon, 31 Jan 2022 08:59:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D4A1A6B009B; Mon, 31 Jan 2022 08:59:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C11F26B009C; Mon, 31 Jan 2022 08:59:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay040.a.hostedemail.com [64.99.140.40]) by kanga.kvack.org (Postfix) with ESMTP id ADE2E6B009A for ; Mon, 31 Jan 2022 08:59:23 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6F8C4219B8 for ; Mon, 31 Jan 2022 13:59:23 +0000 (UTC) X-FDA: 79090739406.01.622A9AB Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.75]) by imf15.hostedemail.com (Postfix) with ESMTP id 6617BA0002 for ; Mon, 31 Jan 2022 13:59:22 +0000 (UTC) Received: from mail-wm1-f53.google.com ([209.85.128.53]) by mrelayeu.kundenserver.de (mreue106 [213.165.67.113]) with ESMTPSA (Nemesis) id 1MlO9r-1mXBZN3ZDJ-00liOa for ; Mon, 31 Jan 2022 14:59:20 +0100 Received: by mail-wm1-f53.google.com with SMTP id m26so4009745wms.0 for ; Mon, 31 Jan 2022 05:59:20 -0800 (PST) X-Gm-Message-State: AOAM532+0hpH+XR+qZOwaCxELpGnv+J8DqxLCay1Nd46uFTimyVBSkmx ZaWrrH0Vv63jhWeL+OUN9Gmje5V9fnRobediWAk= X-Google-Smtp-Source: ABdhPJyCdfYqPFNmYBHdVNyIMNd7iA0YCInVn3QxpZaorB/N7/GMT0WnkA19JE/0Eu40a4rdlyjUc+dSWxOMpZgcSE8= X-Received: by 2002:a05:600c:2309:: with SMTP id 9mr27424396wmo.82.1643635850350; Mon, 31 Jan 2022 05:30:50 -0800 (PST) MIME-Version: 1.0 References: <2d9aa000afe81b45157617664134b871207c2067.1643206612.git.karolinadrobnik@gmail.com> <48499a57afb3d27df26b39aa4255b4ba583c1148.camel@gmail.com> In-Reply-To: From: Arnd Bergmann Date: Mon, 31 Jan 2022 14:30:32 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 07/16] tools/include: Add io.h stub To: Matthew Wilcox Cc: Mike Rapoport , Karolina Drobnik , Linux-MM , Andrew Morton , Mike Rapoport , Linux Kernel Mailing List , Arnd Bergmann , Ingo Molnar Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:gNVhL8v20h0x6iBl3BShWCyrVSTEoWQJNthCd3r2frNbKUDg0Xg BStCFGczLDgliv8H+xlP9/MIACXQVaG9kAnosVuNFNKN75JUozQHphKFnPcy0FnRVYvxGJX iK7ZZ9yLQEPY0Oswf7U91FTkt5wgYzPz/wF0zS9oLiPpkhJatdyGgcmVQVeGwAkixT+vH25 NFneYJnCpFgaoTcysLKrQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:f2DpdJcvbAM=:qs1yr8xOij2pUswisfMxev YdD1+8LJpWEOGdCdEg2W66lOHlZaPwI0utipGF2DZMeCcGNqY+IEJUD+0PL+ANCkgoq2asdJc Oe0ubk8MoalVR38LKXqxywa/HBwpNuDDm07pV8F7O+D5ZdTpodFTGBukmp5dM3R8acCsyDMq/ UxqND/yerxLEpLUO1ywpLeKbw0nn+35Wh+hOy7ge53TV1OrYQVPAa6XxnAik2UX3+qyEf03Vw b1wYq7+BcTeVDrL1sBqX670pKiinQgNMtFMX2/jb9PttSpOVwEeVNI88R59b80fXnEF4RQTgA iJUt96vS9PJ6FZ1jJsdo3ZQir2s6St36xZcQ417AoBwDfsOHRDU0JxjHLWl3owMpHk25L8Q6L TCFmN+mX6VLyJ8oXBHuloEgVN9S9FxUYsMfKHa2L0zwsLWoILkplGhAVZy/G2ou5fhedkIjST V3iHQPvE/xRLVHOfbQRkB7g/NHqevbKLcKp+jN7e1Wfc58xSCYKjrcuHhKPnihM4ojZymjO9c HwBW+t2DkfWHPzaHjmAwOAZ4k0RUlAAq/9H7Y30nWcVVVfn5EZLnnDGH9FDZmBLRzCGN2L4Hf QJ6husm11cODk+A9Nd09HFpS+iFzTDuWAMBZY+1dzyuPVEnHtxHjrWwQQe+fRPXKLJR00jt64 rbbGrPH0Y/kYgvYOsIB5bcTrzpYCy4fUHiXcinOGw8GINeeQOr67utLJLC81nZiqFJsZhrhfQ soFki1Mv6A2gHtPN8dzZ8E2XrU/RigYeihDUNWqOc2QtYv8Cn2AQJLScwp7j5l3h/CWA9+KF1 xPSwy2VK4wFds+xPL/lUErGD6IJPYnPMsa3Zl1VVoc8hyqgiPQ= X-Rspamd-Queue-Id: 6617BA0002 X-Rspam-User: nil Authentication-Results: imf15.hostedemail.com; dkim=none; spf=none (imf15.hostedemail.com: domain of arnd@arndb.de has no SPF policy when checking 217.72.192.75) smtp.mailfrom=arnd@arndb.de; dmarc=none X-Stat-Signature: t5pythk3zju9efe6eq47mdkpzq759hf6 X-Rspamd-Server: rspam08 X-HE-Tag: 1643637562-609137 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: On Sun, Jan 30, 2022 at 6:53 PM Matthew Wilcox wrote: > Thanks for doing the sweep, Mike. > > I think I found a deeper problem which is masked due to our maze of > header files: > > include/asm-generic/io.h:#ifndef virt_to_phys > include/asm-generic/io.h:#define virt_to_phys virt_to_phys > > so there's an assumption that defines virt_to_phys(). > You can see that in a number of architectures, eg: > > arch/alpha/include/asm/io.h:static inline unsigned long virt_to_phys(volatile void *address) > arch/ia64/include/asm/io.h:#define virt_to_phys virt_to_phys > arch/mips/include/asm/io.h:#define virt_to_phys virt_to_phys > arch/nios2/include/asm/io.h:#define virt_to_phys(vaddr) \ > arch/parisc/include/asm/io.h:#define virt_to_phys(a) ((unsigned long)__pa(a)) > arch/powerpc/include/asm/io.h:#define virt_to_phys virt_to_phys > arch/sh/include/asm/io.h:#define virt_to_phys(address) ((unsigned long)(address)) > arch/x86/include/asm/io.h:#define virt_to_phys virt_to_phys > > That's clearly not the right place to define it. Two architectures > put it in asm/memory.h: > > arch/arm/include/asm/memory.h:#define virt_to_phys virt_to_phys > arch/arm64/include/asm/memory.h:#define virt_to_phys virt_to_phys > > then: > > arch/m68k/include/asm/virtconvert.h:#define virt_to_phys virt_to_phys > arch/sparc/include/asm/page_32.h:#define virt_to_phys __pa > arch/sparc/include/asm/page_64.h:#define virt_to_phys __pa > > This needs to be properly sorted out, but I don't want to tell Karolina > that's now her job as a prerequisite for merging this patchset; that > would be unfair. > > Cc'ing Arnd. This is the kind of awful mess that he loves fixing ;-) Adding Ingo as well. I'm in the middle of getting his fast-headers tree to work well on a couple of other architectures, and the memory.h/page.h/io.h mess is one of the tricky bits in there, both in his series and in my follow-ups. What makes this bit even worse is that the architectures also not just inconsistent about where they put __va/__pa and virt_to_phys/phys_to_virt, they are also inconsistent about which of the two pairs is based on the other, so any way you touch it means you will break something, and changing it now will likely require a tricky rebase of Ingo's patches. Ingo, do you happen to have patches already that could be isolated from your series to address this? Maybe we can add the linux/mm_page_address.h header first and require that each architecture puts these macros into asm/page_address.h. We need to isolate these anyway, because the page addresses are used in a lot of places that don't need to include any of the remaining headers (page.h, mm.h, memory.h, io.h) that pull in hundreds more. Arnd