| Message ID | 20210627135117.28641-1-bmeng.cn@gmail.com |
|---|---|
| State | Accepted |
| Commit | d0e4dae74470fb709fc0ab61862c317938f4cc4d |
| Headers | show |
| Series | riscv: Fix 32-bit RISC-V boot failure | expand |
Hi， sorry for the mistake，the bug is fixed by https://lore.kernel.org/linux-riscv/20210602085517.127481-2-wangkefeng.wang@huawei.com/ On 2021/6/27 21:51, Bin Meng wrote: > Commit dd2d082b5760 ("riscv: Cleanup setup_bootmem()") adjusted > the calling sequence in setup_bootmem(), which invalidates the fix > commit de043da0b9e7 ("RISC-V: Fix usage of memblock_enforce_memory_limit") > did for 32-bit RISC-V unfortunately. > > So now 32-bit RISC-V does not boot again when testing booting kernel > on QEMU 'virt' with '-m 2G', which was exactly what the original > commit de043da0b9e7 ("RISC-V: Fix usage of memblock_enforce_memory_limit") > tried to fix. > > Fixes: dd2d082b5760 ("riscv: Cleanup setup_bootmem()") > Cc: stable@vger.kernel.org # v5.12+ > Signed-off-by: Bin Meng <bmeng.cn@gmail.com> > --- > > arch/riscv/mm/init.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index 4c4c92ce0bb8..9b23b95c50cf 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -123,7 +123,7 @@ void __init setup_bootmem(void) > { > phys_addr_t vmlinux_end = __pa_symbol(&_end); > phys_addr_t vmlinux_start = __pa_symbol(&_start); > - phys_addr_t dram_end = memblock_end_of_DRAM(); > + phys_addr_t dram_end; > phys_addr_t max_mapped_addr = __pa(~(ulong)0); > > #ifdef CONFIG_XIP_KERNEL > @@ -146,6 +146,8 @@ void __init setup_bootmem(void) > #endif > memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start); > > + dram_end = memblock_end_of_DRAM(); > + > /* > * memblock allocator is not aware of the fact that last 4K bytes of > * the addressable memory can not be mapped because of IS_ERR_VALUE
On 2021/6/28 9:15, Bin Meng wrote: > On Mon, Jun 28, 2021 at 8:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: >> Hi， sorry for the mistake，the bug is fixed by >> >> https://lore.kernel.org/linux-riscv/20210602085517.127481-2-wangkefeng.wang@huawei.com/ > What are we on the patch you mentioned? > > I don't see it applied in the linux/master. > > Also there should be a "Fixes" tag and stable@vger.kernel.org cc'ed > because 32-bit is broken since v5.12. https://kernel.googlesource.com/pub/scm/linux/kernel/git/riscv/linux/+/c9811e379b211c67ba29fb09d6f644dd44cfcff2 it's on Palmer' riscv-next. Hi Palmer, should I resend or could you help me to add the fixes tag? > > Regards, > Bin > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Mon, Jun 28, 2021 at 11:21 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Mon, Jun 28, 2021 at 10:28 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > > > > > > On 2021/6/28 9:15, Bin Meng wrote: > > > On Mon, Jun 28, 2021 at 8:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > > >> Hi， sorry for the mistake，the bug is fixed by > > >> > > >> https://lore.kernel.org/linux-riscv/20210602085517.127481-2-wangkefeng.wang@huawei.com/ > > > What are we on the patch you mentioned? > > > > > > I don't see it applied in the linux/master. > > > > > > Also there should be a "Fixes" tag and stable@vger.kernel.org cc'ed > > > because 32-bit is broken since v5.12. > > > > https://kernel.googlesource.com/pub/scm/linux/kernel/git/riscv/linux/+/c9811e379b211c67ba29fb09d6f644dd44cfcff2 > > > > it's on Palmer' riscv-next. > > Not sure riscv-next is for which release? This is a regression and > should be on 5.13. > > > > > Hi Palmer, should I resend or could you help me to add the fixes tag? Your patch mixed 2 things (fix plus one feature) together, so it is not proper to back port your patch. Here is my 2 cents: 1. Drop your patch from riscv-next 2. Apply my patch as it is a simple fix to previous commit. This allows stable kernel to cherry-pick the fix to v5.12 and v5.13. 3. Rebase your patch against mine, and resend v2 Let me know if this makes sense. Regards, Bin
On 2021/6/30 19:58, Bin Meng wrote: > On Mon, Jun 28, 2021 at 11:21 AM Bin Meng <bmeng.cn@gmail.com> wrote: >> On Mon, Jun 28, 2021 at 10:28 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: >>> >>> On 2021/6/28 9:15, Bin Meng wrote: >>>> On Mon, Jun 28, 2021 at 8:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: >>>>> Hi， sorry for the mistake，the bug is fixed by >>>>> >>>>> https://lore.kernel.org/linux-riscv/20210602085517.127481-2-wangkefeng.wang@huawei.com/ >>>> What are we on the patch you mentioned? >>>> >>>> I don't see it applied in the linux/master. >>>> >>>> Also there should be a "Fixes" tag and stable@vger.kernel.org cc'ed >>>> because 32-bit is broken since v5.12. >>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/riscv/linux/+/c9811e379b211c67ba29fb09d6f644dd44cfcff2 >>> >>> it's on Palmer' riscv-next. >> Not sure riscv-next is for which release? This is a regression and >> should be on 5.13. >> >>> Hi Palmer, should I resend or could you help me to add the fixes tag? > Your patch mixed 2 things (fix plus one feature) together, so it is > not proper to back port your patch. "mem=" will change the range of memblock, so the fix part must be included. > > Here is my 2 cents: > > 1. Drop your patch from riscv-next > 2. Apply my patch as it is a simple fix to previous commit. This > allows stable kernel to cherry-pick the fix to v5.12 and v5.13. > 3. Rebase your patch against mine, and resend v2 > > Let me know if this makes sense. It is not a big problem for me, but I have no right abourt riscv-next, let's wait Palmer's advise. > > Regards, > Bin > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Thu, Jul 1, 2021 at 10:08 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > > > On 2021/6/30 19:58, Bin Meng wrote: > > On Mon, Jun 28, 2021 at 11:21 AM Bin Meng <bmeng.cn@gmail.com> wrote: > >> On Mon, Jun 28, 2021 at 10:28 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > >>> > >>> On 2021/6/28 9:15, Bin Meng wrote: > >>>> On Mon, Jun 28, 2021 at 8:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > >>>>> Hi， sorry for the mistake，the bug is fixed by > >>>>> > >>>>> https://lore.kernel.org/linux-riscv/20210602085517.127481-2-wangkefeng.wang@huawei.com/ > >>>> What are we on the patch you mentioned? > >>>> > >>>> I don't see it applied in the linux/master. > >>>> > >>>> Also there should be a "Fixes" tag and stable@vger.kernel.org cc'ed > >>>> because 32-bit is broken since v5.12. > >>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/riscv/linux/+/c9811e379b211c67ba29fb09d6f644dd44cfcff2 > >>> > >>> it's on Palmer' riscv-next. > >> Not sure riscv-next is for which release? This is a regression and > >> should be on 5.13. > >> > >>> Hi Palmer, should I resend or could you help me to add the fixes tag? > > Your patch mixed 2 things (fix plus one feature) together, so it is > > not proper to back port your patch. > > "mem=" will change the range of memblock, so the fix part must be included. > Yes, so you can rebase the "mem=" changes on top of my patch. The practice is that we should not mix 2 things in one patch. I can imagine that you wanted to add "mem=" to RISC-V and suddenly found the existing logic was broken, so you sent one patch to do both. > > > > > Here is my 2 cents: > > > > 1. Drop your patch from riscv-next > > 2. Apply my patch as it is a simple fix to previous commit. This > > allows stable kernel to cherry-pick the fix to v5.12 and v5.13. > > 3. Rebase your patch against mine, and resend v2 > > > > Let me know if this makes sense. > > It is not a big problem for me, but I have no right abourt riscv-next, > > let's wait Palmer's advise. > Sure. Palmer, let me know your thoughts. Regards, Bin
Hi Palmer, On Thu, Jul 1, 2021 at 10:20 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Thu, Jul 1, 2021 at 10:08 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > > > > > > On 2021/6/30 19:58, Bin Meng wrote: > > > On Mon, Jun 28, 2021 at 11:21 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > >> On Mon, Jun 28, 2021 at 10:28 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > > >>> > > >>> On 2021/6/28 9:15, Bin Meng wrote: > > >>>> On Mon, Jun 28, 2021 at 8:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > > >>>>> Hi， sorry for the mistake，the bug is fixed by > > >>>>> > > >>>>> https://lore.kernel.org/linux-riscv/20210602085517.127481-2-wangkefeng.wang@huawei.com/ > > >>>> What are we on the patch you mentioned? > > >>>> > > >>>> I don't see it applied in the linux/master. > > >>>> > > >>>> Also there should be a "Fixes" tag and stable@vger.kernel.org cc'ed > > >>>> because 32-bit is broken since v5.12. > > >>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/riscv/linux/+/c9811e379b211c67ba29fb09d6f644dd44cfcff2 > > >>> > > >>> it's on Palmer' riscv-next. > > >> Not sure riscv-next is for which release? This is a regression and > > >> should be on 5.13. > > >> > > >>> Hi Palmer, should I resend or could you help me to add the fixes tag? > > > Your patch mixed 2 things (fix plus one feature) together, so it is > > > not proper to back port your patch. > > > > "mem=" will change the range of memblock, so the fix part must be included. > > > > Yes, so you can rebase the "mem=" changes on top of my patch. > > The practice is that we should not mix 2 things in one patch. I can > imagine that you wanted to add "mem=" to RISC-V and suddenly found the > existing logic was broken, so you sent one patch to do both. > > > > > > > > > Here is my 2 cents: > > > > > > 1. Drop your patch from riscv-next > > > 2. Apply my patch as it is a simple fix to previous commit. This > > > allows stable kernel to cherry-pick the fix to v5.12 and v5.13. > > > 3. Rebase your patch against mine, and resend v2 > > > > > > Let me know if this makes sense. > > > > It is not a big problem for me, but I have no right abourt riscv-next, > > > > let's wait Palmer's advise. > > > > Sure. Palmer, let me know your thoughts. Ping? Regards, Bin
On Thu, Jul 8, 2021 at 9:29 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Palmer, > > On Thu, Jul 1, 2021 at 10:20 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > On Thu, Jul 1, 2021 at 10:08 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > > > > > > > > > On 2021/6/30 19:58, Bin Meng wrote: > > > > On Mon, Jun 28, 2021 at 11:21 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > >> On Mon, Jun 28, 2021 at 10:28 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > > > >>> > > > >>> On 2021/6/28 9:15, Bin Meng wrote: > > > >>>> On Mon, Jun 28, 2021 at 8:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > > > >>>>> Hi， sorry for the mistake，the bug is fixed by > > > >>>>> > > > >>>>> https://lore.kernel.org/linux-riscv/20210602085517.127481-2-wangkefeng.wang@huawei.com/ > > > >>>> What are we on the patch you mentioned? > > > >>>> > > > >>>> I don't see it applied in the linux/master. > > > >>>> > > > >>>> Also there should be a "Fixes" tag and stable@vger.kernel.org cc'ed > > > >>>> because 32-bit is broken since v5.12. > > > >>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/riscv/linux/+/c9811e379b211c67ba29fb09d6f644dd44cfcff2 > > > >>> > > > >>> it's on Palmer' riscv-next. > > > >> Not sure riscv-next is for which release? This is a regression and > > > >> should be on 5.13. > > > >> > > > >>> Hi Palmer, should I resend or could you help me to add the fixes tag? > > > > Your patch mixed 2 things (fix plus one feature) together, so it is > > > > not proper to back port your patch. > > > > > > "mem=" will change the range of memblock, so the fix part must be included. > > > > > > > Yes, so you can rebase the "mem=" changes on top of my patch. > > > > The practice is that we should not mix 2 things in one patch. I can > > imagine that you wanted to add "mem=" to RISC-V and suddenly found the > > existing logic was broken, so you sent one patch to do both. > > > > > > > > > > > > > Here is my 2 cents: > > > > > > > > 1. Drop your patch from riscv-next > > > > 2. Apply my patch as it is a simple fix to previous commit. This > > > > allows stable kernel to cherry-pick the fix to v5.12 and v5.13. > > > > 3. Rebase your patch against mine, and resend v2 > > > > > > > > Let me know if this makes sense. > > > > > > It is not a big problem for me, but I have no right abourt riscv-next, > > > > > > let's wait Palmer's advise. > > > > > > > Sure. Palmer, let me know your thoughts. > > Ping? Ping?
On Thu, 15 Jul 2021 19:14:20 PDT (-0700), bmeng.cn@gmail.com wrote: > On Thu, Jul 8, 2021 at 9:29 PM Bin Meng <bmeng.cn@gmail.com> wrote: >> >> Hi Palmer, >> >> On Thu, Jul 1, 2021 at 10:20 AM Bin Meng <bmeng.cn@gmail.com> wrote: >> > >> > On Thu, Jul 1, 2021 at 10:08 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: >> > > >> > > >> > > On 2021/6/30 19:58, Bin Meng wrote: >> > > > On Mon, Jun 28, 2021 at 11:21 AM Bin Meng <bmeng.cn@gmail.com> wrote: >> > > >> On Mon, Jun 28, 2021 at 10:28 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: >> > > >>> >> > > >>> On 2021/6/28 9:15, Bin Meng wrote: >> > > >>>> On Mon, Jun 28, 2021 at 8:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: >> > > >>>>> Hi， sorry for the mistake，the bug is fixed by >> > > >>>>> >> > > >>>>> https://lore.kernel.org/linux-riscv/20210602085517.127481-2-wangkefeng.wang@huawei.com/ >> > > >>>> What are we on the patch you mentioned? >> > > >>>> >> > > >>>> I don't see it applied in the linux/master. >> > > >>>> >> > > >>>> Also there should be a "Fixes" tag and stable@vger.kernel.org cc'ed >> > > >>>> because 32-bit is broken since v5.12. >> > > >>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/riscv/linux/+/c9811e379b211c67ba29fb09d6f644dd44cfcff2 >> > > >>> >> > > >>> it's on Palmer' riscv-next. >> > > >> Not sure riscv-next is for which release? This is a regression and >> > > >> should be on 5.13. >> > > >> >> > > >>> Hi Palmer, should I resend or could you help me to add the fixes tag? >> > > > Your patch mixed 2 things (fix plus one feature) together, so it is >> > > > not proper to back port your patch. >> > > >> > > "mem=" will change the range of memblock, so the fix part must be included. >> > > >> > >> > Yes, so you can rebase the "mem=" changes on top of my patch. >> > >> > The practice is that we should not mix 2 things in one patch. I can >> > imagine that you wanted to add "mem=" to RISC-V and suddenly found the >> > existing logic was broken, so you sent one patch to do both. >> > >> > > >> > > > >> > > > Here is my 2 cents: >> > > > >> > > > 1. Drop your patch from riscv-next >> > > > 2. Apply my patch as it is a simple fix to previous commit. This >> > > > allows stable kernel to cherry-pick the fix to v5.12 and v5.13. >> > > > 3. Rebase your patch against mine, and resend v2 >> > > > >> > > > Let me know if this makes sense. >> > > >> > > It is not a big problem for me, but I have no right abourt riscv-next, >> > > >> > > let's wait Palmer's advise. >> > > >> > >> > Sure. Palmer, let me know your thoughts. >> >> Ping? > > Ping? Sorry, I missed this one. It looks like the patch that adds mem= and fixes the bug has already been merged, so I'm not really quite sure what the right thing to do is here: we don't really want the mem= code on stable, but we do want the fix. I went ahead and did commit 444818b599189fd8b6c814da542ff8cfc9fe67d4 (HEAD -> fixes, palmer/fixes) gpg: Signature made Wed 21 Jul 2021 10:21:05 PM PDT gpg: using RSA key 2B3C3747446843B24A943A7A2E1319F35FBB1889 gpg: issuer "palmer@dabbelt.com" gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [ultimate] gpg: aka "Palmer Dabbelt <palmerdabbelt@google.com>" [ultimate] Merge: e73f0f0ee754 d0e4dae74470 Author: Palmer Dabbelt <palmerdabbelt@google.com> Date: Wed Jul 21 22:18:58 2021 -0700 Merge remote-tracking branch 'riscv/riscv-fix-32bit' into fixes This contains a single fix for 32-bit boot. It happens this was already fixed by c9811e379b21 ("riscv: Add mem kernel parameter support"), but the bug existed before that feature addition so I've applied the patch earlier and then merged it in (which results in a conflict, which is fixed via not changing the resulting tree). * riscv/riscv-fix-32bit: riscv: Fix 32-bit RISC-V boot failure as that"s the best I could come up with -- then the fix will land on master, which should cause it to get pulled onto stable. Greg: is there a better way to make something like this get to stable?
On Thu, Jul 22, 2021 at 1:53 PM Palmer Dabbelt <palmerdabbelt@google.com> wrote: > > On Thu, 15 Jul 2021 19:14:20 PDT (-0700), bmeng.cn@gmail.com wrote: > > On Thu, Jul 8, 2021 at 9:29 PM Bin Meng <bmeng.cn@gmail.com> wrote: > >> > >> Hi Palmer, > >> > >> On Thu, Jul 1, 2021 at 10:20 AM Bin Meng <bmeng.cn@gmail.com> wrote: > >> > > >> > On Thu, Jul 1, 2021 at 10:08 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > >> > > > >> > > > >> > > On 2021/6/30 19:58, Bin Meng wrote: > >> > > > On Mon, Jun 28, 2021 at 11:21 AM Bin Meng <bmeng.cn@gmail.com> wrote: > >> > > >> On Mon, Jun 28, 2021 at 10:28 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > >> > > >>> > >> > > >>> On 2021/6/28 9:15, Bin Meng wrote: > >> > > >>>> On Mon, Jun 28, 2021 at 8:53 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > >> > > >>>>> Hi， sorry for the mistake，the bug is fixed by > >> > > >>>>> > >> > > >>>>> https://lore.kernel.org/linux-riscv/20210602085517.127481-2-wangkefeng.wang@huawei.com/ > >> > > >>>> What are we on the patch you mentioned? > >> > > >>>> > >> > > >>>> I don't see it applied in the linux/master. > >> > > >>>> > >> > > >>>> Also there should be a "Fixes" tag and stable@vger.kernel.org cc'ed > >> > > >>>> because 32-bit is broken since v5.12. > >> > > >>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/riscv/linux/+/c9811e379b211c67ba29fb09d6f644dd44cfcff2 > >> > > >>> > >> > > >>> it's on Palmer' riscv-next. > >> > > >> Not sure riscv-next is for which release? This is a regression and > >> > > >> should be on 5.13. > >> > > >> > >> > > >>> Hi Palmer, should I resend or could you help me to add the fixes tag? > >> > > > Your patch mixed 2 things (fix plus one feature) together, so it is > >> > > > not proper to back port your patch. > >> > > > >> > > "mem=" will change the range of memblock, so the fix part must be included. > >> > > > >> > > >> > Yes, so you can rebase the "mem=" changes on top of my patch. > >> > > >> > The practice is that we should not mix 2 things in one patch. I can > >> > imagine that you wanted to add "mem=" to RISC-V and suddenly found the > >> > existing logic was broken, so you sent one patch to do both. > >> > > >> > > > >> > > > > >> > > > Here is my 2 cents: > >> > > > > >> > > > 1. Drop your patch from riscv-next > >> > > > 2. Apply my patch as it is a simple fix to previous commit. This > >> > > > allows stable kernel to cherry-pick the fix to v5.12 and v5.13. > >> > > > 3. Rebase your patch against mine, and resend v2 > >> > > > > >> > > > Let me know if this makes sense. > >> > > > >> > > It is not a big problem for me, but I have no right abourt riscv-next, > >> > > > >> > > let's wait Palmer's advise. > >> > > > >> > > >> > Sure. Palmer, let me know your thoughts. > >> > >> Ping? > > > > Ping? > > Sorry, I missed this one. It looks like the patch that adds mem= and > fixes the bug has already been merged, so I'm not really quite sure what > the right thing to do is here: we don't really want the mem= code on > stable, but we do want the fix. I went ahead and did > > commit 444818b599189fd8b6c814da542ff8cfc9fe67d4 (HEAD -> fixes, palmer/fixes) > gpg: Signature made Wed 21 Jul 2021 10:21:05 PM PDT > gpg: using RSA key 2B3C3747446843B24A943A7A2E1319F35FBB1889 > gpg: issuer "palmer@dabbelt.com" > gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [ultimate] > gpg: aka "Palmer Dabbelt <palmerdabbelt@google.com>" [ultimate] > Merge: e73f0f0ee754 d0e4dae74470 > Author: Palmer Dabbelt <palmerdabbelt@google.com> > Date: Wed Jul 21 22:18:58 2021 -0700 > > Merge remote-tracking branch 'riscv/riscv-fix-32bit' into fixes > > This contains a single fix for 32-bit boot. It happens this was already > fixed by c9811e379b21 ("riscv: Add mem kernel parameter support"), but > the bug existed before that feature addition so I've applied the patch > earlier and then merged it in (which results in a conflict, which is > fixed via not changing the resulting tree). > > * riscv/riscv-fix-32bit: > riscv: Fix 32-bit RISC-V boot failure > > as that"s the best I could come up with -- then the fix will land on > master, which should cause it to get pulled onto stable. > > Greg: is there a better way to make something like this get to stable? We can: 1. git revert c9811e379b21 ("riscv: Add mem kernel parameter support") 2. git am <this patch>, cc stable 3. Kefeng resent a new patch that adds the mem kernel parameter support, on top of mine Regards, Bin
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 4c4c92ce0bb8..9b23b95c50cf 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -123,7 +123,7 @@ void __init setup_bootmem(void) { phys_addr_t vmlinux_end = __pa_symbol(&_end); phys_addr_t vmlinux_start = __pa_symbol(&_start); - phys_addr_t dram_end = memblock_end_of_DRAM(); + phys_addr_t dram_end; phys_addr_t max_mapped_addr = __pa(~(ulong)0); #ifdef CONFIG_XIP_KERNEL @@ -146,6 +146,8 @@ void __init setup_bootmem(void) #endif memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start); + dram_end = memblock_end_of_DRAM(); + /* * memblock allocator is not aware of the fact that last 4K bytes of * the addressable memory can not be mapped because of IS_ERR_VALUE
Commit dd2d082b5760 ("riscv: Cleanup setup_bootmem()") adjusted the calling sequence in setup_bootmem(), which invalidates the fix commit de043da0b9e7 ("RISC-V: Fix usage of memblock_enforce_memory_limit") did for 32-bit RISC-V unfortunately. So now 32-bit RISC-V does not boot again when testing booting kernel on QEMU 'virt' with '-m 2G', which was exactly what the original commit de043da0b9e7 ("RISC-V: Fix usage of memblock_enforce_memory_limit") tried to fix. Fixes: dd2d082b5760 ("riscv: Cleanup setup_bootmem()") Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Bin Meng <bmeng.cn@gmail.com> --- arch/riscv/mm/init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)