linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Ghiti <alex@ghiti.fr>
To: Lee Ken <nek.in.cn@gmail.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>, moi <alex@ghiti.fr>,
	Anup Patel <anup@brainfault.org>,
	Atish Patra <atish.patra@wdc.com>,
	Kenneth Lee <liguozhu@hisilicon.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Vitaly Wool <vitaly.wool@konsulko.com>,
	Guo Ren <guoren@linux.alibaba.com>,
	Jisheng Zhang <jszhang@kernel.org>,
	Nick Kossifidis <mick@ics.forth.gr>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	"linux-kernel@vger.kernel.org List"
	<linux-kernel@vger.kernel.org>,
	"guohanjun@huawei.com" <guohanjun@huawei.com>,
	"wangzhou1@hisilicon.com" <wangzhou1@hisilicon.com>
Subject: Re: [PATCH] riscv: fix the global name pfn_base confliction error
Date: Wed, 28 Jul 2021 11:08:03 +0200	[thread overview]
Message-ID: <4da4adaf-9bd8-6463-9230-5a3a73f323ba@ghiti.fr> (raw)
In-Reply-To: <CA+CqrBQPou5QuYfHUYzbe7j2AUPpmBQs1HQJgjJo5QtF51LmXw@mail.gmail.com>



Le 28/07/2021 à 09:33, Lee Ken a écrit :
> On Wed, Jul 28, 2021 at 3:19 PM Alex Ghiti <alex@ghiti.fr> wrote:
>>
>> Hi Kenneth,
>>
>> Le 28/07/2021 à 08:43, Kenneth Lee a écrit :
>>> From: Kenneth Lee <liguozhu@hisilicon.com>
>>>
>>> RISCV use a global variable pfn_base for page/pfn translation. But this
>>> is a common name and will be used elsewhere. In those case,
>>> the page-pfn macro which refer this name will refer to the local/input
>>> variable of those function (such as in vfio_pin_pages_remote). This make
>>> everything wrong.
>>>
>>> This patch change the name from pfn_base to riscv_global_pfn_base to fix
>>> this problem
>>
>> What about removing this variable entirely and using
>> PFN_DOWN(kernel_map.phys_addr) directly in ARCH_PFN_OFFSET definition?
>> That would remove code from mm/init.c, which is nice :)
>>
>> Thanks,
>>
>> Alex
>>
>>>
>>> Signed-off-by: Kenneth Lee <liguozhu@hisilicon.com>
>>> ---
>>>    arch/riscv/include/asm/page.h | 4 ++--
>>>    arch/riscv/mm/init.c          | 6 +++---
>>>    2 files changed, 5 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
>>> index cca8764aed83..8711e415f37c 100644
>>> --- a/arch/riscv/include/asm/page.h
>>> +++ b/arch/riscv/include/asm/page.h
>>> @@ -79,8 +79,8 @@ typedef struct page *pgtable_t;
>>>    #endif
>>>
>>>    #ifdef CONFIG_MMU
>>> -extern unsigned long pfn_base;
>>> -#define ARCH_PFN_OFFSET              (pfn_base)
>>> +extern unsigned long riscv_global_pfn_base;
>>> +#define ARCH_PFN_OFFSET              (riscv_global_pfn_base)
>>>    #else
>>>    #define ARCH_PFN_OFFSET             (PAGE_OFFSET >> PAGE_SHIFT)
>>>    #endif /* CONFIG_MMU */
>>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
>>> index a14bf3910eec..2ce4e9a46ca0 100644
>>> --- a/arch/riscv/mm/init.c
>>> +++ b/arch/riscv/mm/init.c
>>> @@ -228,8 +228,8 @@ static struct pt_alloc_ops _pt_ops __initdata;
>>>    #define pt_ops _pt_ops
>>>    #endif
>>>
>>> -unsigned long pfn_base __ro_after_init;
>>> -EXPORT_SYMBOL(pfn_base);
>>> +unsigned long riscv_global_pfn_base __ro_after_init;
>>> +EXPORT_SYMBOL(riscv_global_pfn_base);
>>>
>>>    pgd_t swapper_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
>>>    pgd_t trampoline_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
>>> @@ -572,7 +572,7 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
>>>        kernel_map.va_kernel_pa_offset = kernel_map.virt_addr - kernel_map.phys_addr;
>>>    #endif
>>>
>>> -     pfn_base = PFN_DOWN(kernel_map.phys_addr);
>>> +     riscv_global_pfn_base = PFN_DOWN(kernel_map.phys_addr);
>>>
>>>        /*
>>>         * Enforce boot alignment requirements of RV32 and
>>>
> 
> Yes. It is a choice. But I think it is the choice of the maintainer of
> the module. He should have a full consideration on how to expose the
> interface. I'm now just working for VFIO enablement in RISCV. It is
> not wise to be trapped into this;)
> 

I think there is a misunderstanding, I suggested to do the following to 
get rid of pfn_base entirely:

diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
index adf5b4671684..8afb3db61eb0 100644
--- a/arch/riscv/include/asm/page.h
+++ b/arch/riscv/include/asm/page.h
@@ -79,8 +79,7 @@ typedef struct page *pgtable_t;
  #endif

  #ifdef CONFIG_MMU
-extern unsigned long pfn_base;
-#define ARCH_PFN_OFFSET                (pfn_base)
+#define ARCH_PFN_OFFSET                (PFN_DOWN(kernel_map.phys_addr))
  #else
  #define ARCH_PFN_OFFSET                (PAGE_OFFSET >> PAGE_SHIFT)
  #endif /* CONFIG_MMU */
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index c9a6362d8c7f..c51f0da03a62 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -211,9 +211,6 @@ static void __init setup_bootmem(void)
  #ifdef CONFIG_MMU
  static struct pt_alloc_ops pt_ops __initdata;

-unsigned long pfn_base __ro_after_init;
-EXPORT_SYMBOL(pfn_base);
-
  pgd_t swapper_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
  pgd_t trampoline_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
  extern pte_t fixmap_pte[PTRS_PER_PTE];// __page_aligned_bss;
@@ -608,8 +605,6 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
         kernel_map.va_pa_offset = PAGE_OFFSET - kernel_map.phys_addr;
         kernel_map.va_kernel_pa_offset = kernel_map.virt_addr - 
kernel_map.phys_addr;

-       pfn_base = PFN_DOWN(kernel_map.phys_addr);
-
         /* Sanity check alignment and size */
         BUG_ON((PAGE_OFFSET % PGDIR_SIZE) != 0);
         BUG_ON((kernel_map.phys_addr % PMD_SIZE) != 0);

  parent reply	other threads:[~2021-07-28  9:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-28  6:43 [PATCH] riscv: fix the global name pfn_base confliction error Kenneth Lee
2021-07-28  6:55 ` Mike Rapoport
2021-07-28  7:08   ` Lee Ken
2021-07-28  7:13 ` Hanjun Guo
2021-07-28  7:22   ` Hanjun Guo
2021-07-28  7:19 ` Alex Ghiti
     [not found]   ` <CA+CqrBQPou5QuYfHUYzbe7j2AUPpmBQs1HQJgjJo5QtF51LmXw@mail.gmail.com>
2021-07-28  9:08     ` Alex Ghiti [this message]
2021-07-28 12:52   ` Mike Rapoport

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4da4adaf-9bd8-6463-9230-5a3a73f323ba@ghiti.fr \
    --to=alex@ghiti.fr \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=atish.patra@wdc.com \
    --cc=guohanjun@huawei.com \
    --cc=guoren@linux.alibaba.com \
    --cc=jszhang@kernel.org \
    --cc=liguozhu@hisilicon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mick@ics.forth.gr \
    --cc=nek.in.cn@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=vitaly.wool@konsulko.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=wangzhou1@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).