linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
Tomorrow's linux-next merge of the akpm-current tree will get a
conflict in:
Documentation/admin-guide/kernel-parameters.txt
between commit:
f6e5aedf470b ("riscv: Add support for memtest")
from the risc-v tree and commit:
6b8f5ba8661b ("mm,memory_hotplug: add kernel boot option to enable
memmap_on_memory")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc Documentation/admin-guide/kernel-parameters.txt
index b816481dfaef,04b4e76be65b..
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@@ -2800,23 -2802,7 +2808,23 @@@
seconds. Use this parameter to check at some
other rate. 0 disables periodic checking.
+ memory_hotplug.memmap_on_memory
+ [KNL,X86,ARM] Boolean flag to enable this feature.
+ Format: {on | off (default)}
+ When enabled, memory to build the pages tables for the
+ memmap array describing the hot-added range will be
taken
+ from the range itself, so the memmap page tables will be
+ self-hosted.
+ Since only single memory device ranges are supported at
+ the moment, this option is disabled by default because
+ it might have an impact on workloads that needs large
+ contiguous memory chunks.
+ The state of the flag can be read in
+ /sys/module/memory_hotplug/parameters/memmap_on_memory.
+ Note that even when enabled, there are a few cases where
+ the feature is not effective.
+
- memtest=[KNL,X86,ARM,PPC] Enable memtest
+ memtest=[KNL,X86,ARM,PPC,RISCV] Enable memtest
Format:
default : 0
Specifies the number of memtest passes to be
pgp24YcASmleU.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
On Thu, 17 Dec 2020 01:40:51 PST (-0800), andy.shevche...@gmail.com wrote:
On Thu, Dec 17, 2020 at 3:28 AM Stephen Rothwell wrote:
Hi all,
On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> lib/Makefile
>
> between commit:
>
> 527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
>
> from the risc-v tree and commits:
>
> 8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit
tests")
> 17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for
KUnit tests")
> 23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit
tests")
> 1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
AFAIU Linus rejected the above patches. I hope kselftest/kunit tree
can pick them up.
> diff --cc lib/Makefile
> index bcedd691ef63,dc623561ef9d..
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
>
> # KUnit tests
> obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
> - obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> - obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> - obj-$(CONFIG_BITS_TEST) += test_bits.o
> + obj-$(CONFIG_BITS_TEST) += bits_kunit.o
> + obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
> + obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
> + obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
> +
> +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
This is now a conflict between the risc-v tree and Linus' tree.
Yeah, and it's slightly different. Perhaps RISC-V tree can handle this
by moving Makefile entry somewhere else in the file.
I was planning on just posting the merge conflict along with the PR, which I
was going to do this morning (though in practice that means this afternoon...
;)). I'd been considering fixing this stuff as I was likely going to have to
rewrite history to sort out our boot bug, but as it's only manifesting on
old-ish QEMU versions I've decided that it's not really worth making it a
blocker.
If you think that's an issue then I'm happy to rewrite my history, but I do
generally try to stay away from that and for this sort of thing I've yet to
have any complaints. I probably will put it up near the other GENERIC_LIB
stuff in my conflict resolution, though.
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi Andy, On Thu, 17 Dec 2020 11:40:51 +0200 Andy Shevchenko wrote: > > Yeah, and it's slightly different. Perhaps RISC-V tree can handle this > by moving Makefile entry somewhere else in the file. Or just let Linus take care of it ... -- Cheers, Stephen Rothwell pgprUxnfVtQtO.pgp Description: OpenPGP digital signature
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
On Thu, Dec 17, 2020 at 3:28 AM Stephen Rothwell wrote:
>
> Hi all,
>
> On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the akpm-current tree got a conflict in:
> >
> > lib/Makefile
> >
> > between commit:
> >
> > 527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
> >
> > from the risc-v tree and commits:
> >
> > 8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit
> > tests")
> > 17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention
> > for KUnit tests")
> > 23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit
> > tests")
> > 1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
AFAIU Linus rejected the above patches. I hope kselftest/kunit tree
can pick them up.
> > diff --cc lib/Makefile
> > index bcedd691ef63,dc623561ef9d..
> > --- a/lib/Makefile
> > +++ b/lib/Makefile
> > @@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
> >
> > # KUnit tests
> > obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
> > - obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> > - obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> > - obj-$(CONFIG_BITS_TEST) += test_bits.o
> > + obj-$(CONFIG_BITS_TEST) += bits_kunit.o
> > + obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
> > + obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
> > + obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
> > +
> > +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
>
> This is now a conflict between the risc-v tree and Linus' tree.
Yeah, and it's slightly different. Perhaps RISC-V tree can handle this
by moving Makefile entry somewhere else in the file.
--
With Best Regards,
Andy Shevchenko
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
On 2020/12/17 9:26, Stephen Rothwell wrote:
Hi all,
On Fri, 27 Nov 2020 18:34:41 +1100 Stephen Rothwell
wrote:
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/riscv/Kconfig
between commit:
5cb0080f1bfd ("riscv: Enable ARCH_STACKWALK")
from the risc-v tree and commit:
46b9b00649f6 ("arch, mm: restore dependency of __kernel_map_pages() on
DEBUG_PAGEALLOC")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc arch/riscv/Kconfig
index 8a2a0523a9a3,9283c6f9ae2a..
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@@ -14,7 -14,7 +14,8 @@@ config RISC
def_bool y
select ARCH_CLOCKSOURCE_INIT
select ARCH_SUPPORTS_ATOMIC_RMW
+ select ARCH_STACKWALK
+ select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_DEBUG_VM_PGTABLE
select ARCH_HAS_DEBUG_VIRTUAL if MMU
This is now a conflict between the risc-v tree and Linus' tree.
Could it be fixed in alphabetical order when merging riscv tree?
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
On Fri, 27 Nov 2020 18:34:41 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> arch/riscv/Kconfig
>
> between commit:
>
> 5cb0080f1bfd ("riscv: Enable ARCH_STACKWALK")
>
> from the risc-v tree and commit:
>
> 46b9b00649f6 ("arch, mm: restore dependency of __kernel_map_pages() on
> DEBUG_PAGEALLOC")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
>
> diff --cc arch/riscv/Kconfig
> index 8a2a0523a9a3,9283c6f9ae2a..
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@@ -14,7 -14,7 +14,8 @@@ config RISC
> def_bool y
> select ARCH_CLOCKSOURCE_INIT
> select ARCH_SUPPORTS_ATOMIC_RMW
> +select ARCH_STACKWALK
> + select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU
> select ARCH_HAS_BINFMT_FLAT
> select ARCH_HAS_DEBUG_VM_PGTABLE
> select ARCH_HAS_DEBUG_VIRTUAL if MMU
This is now a conflict between the risc-v tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpeEYGAzWMTz.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
On Mon, 14 Dec 2020 20:21:07 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> lib/Makefile
>
> between commit:
>
> 527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
>
> from the risc-v tree and commits:
>
> 8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit
> tests")
> 17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for
> KUnit tests")
> 23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit
> tests")
> 1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
>
> diff --cc lib/Makefile
> index bcedd691ef63,dc623561ef9d..
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
>
> # KUnit tests
> obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
> - obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> - obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> - obj-$(CONFIG_BITS_TEST) += test_bits.o
> + obj-$(CONFIG_BITS_TEST) += bits_kunit.o
> + obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
> + obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
> + obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
> +
> +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
This is now a conflict between the risc-v tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgp997akoF_XO.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
On Mon, 14 Dec 2020 09:37:47 PST (-0800), andriy.shevche...@linux.intel.com
wrote:
On Mon, Dec 14, 2020 at 08:21:07PM +1100, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
lib/Makefile
between commit:
527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
from the risc-v tree and commits:
8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit
tests")
17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for KUnit
tests")
23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit
tests")
1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
Looks good enough (*) to me, thanks!
*) I think we might group that new line with an existing one(s) of the same
level (GENERIC_LIB) but it doesn't really matter.
I went back and forth on that one: it's got the same Kconfig name, but it's not
a libgcc function. Maybe we shouldn't have had the "_LIB" in there? I don't
remember if that was meant to stand for libgcc or lib/...
I'm happy to just re-spin my patch to avoid the conflict. It's near/at the top
of my tree, so it's not a big deal, but I'm also just OK merging second and
pointing out the conflict. Unless you care one way or the other I'll just do
whatever ends up being easier for me :)
--
Cheers,
Stephen Rothwell
diff --cc lib/Makefile
index bcedd691ef63,dc623561ef9d..
--- a/lib/Makefile
+++ b/lib/Makefile
@@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
# KUnit tests
obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
- obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
- obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
- obj-$(CONFIG_BITS_TEST) += test_bits.o
+ obj-$(CONFIG_BITS_TEST) += bits_kunit.o
+ obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
+ obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
+ obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
+
+obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
On Mon, Dec 14, 2020 at 08:21:07PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm-current tree got a conflict in:
>
> lib/Makefile
>
> between commit:
>
> 527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
>
> from the risc-v tree and commits:
>
> 8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit
> tests")
> 17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for
> KUnit tests")
> 23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit
> tests")
> 1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
>
> from the akpm-current tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Looks good enough (*) to me, thanks!
*) I think we might group that new line with an existing one(s) of the same
level (GENERIC_LIB) but it doesn't really matter.
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc lib/Makefile
> index bcedd691ef63,dc623561ef9d..
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
>
> # KUnit tests
> obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
> - obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
> - obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
> - obj-$(CONFIG_BITS_TEST) += test_bits.o
> + obj-$(CONFIG_BITS_TEST) += bits_kunit.o
> + obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
> + obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
> + obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
> +
> +obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
--
With Best Regards,
Andy Shevchenko
linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
lib/Makefile
between commit:
527701eda5f1 ("lib: Add a generic version of devmem_is_allowed()")
from the risc-v tree and commits:
8250e121c672 ("lib/list_kunit: follow new file name convention for KUnit
tests")
17bf776cf09a ("lib/linear_ranges_kunit: follow new file name convention for
KUnit tests")
23fa4e39ee62 ("lib/bits_kunit: follow new file name convention for KUnit
tests")
1987f84faec6 ("lib/cmdline_kunit: add a new test suite for cmdline API")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc lib/Makefile
index bcedd691ef63,dc623561ef9d..
--- a/lib/Makefile
+++ b/lib/Makefile
@@@ -350,8 -350,7 +350,9 @@@ obj-$(CONFIG_PLDMFW) += pldmfw
# KUnit tests
obj-$(CONFIG_BITFIELD_KUNIT) += bitfield_kunit.o
- obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
- obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
- obj-$(CONFIG_BITS_TEST) += test_bits.o
+ obj-$(CONFIG_BITS_TEST) += bits_kunit.o
+ obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
+ obj-$(CONFIG_LINEAR_RANGES_TEST) += linear_ranges_kunit.o
+ obj-$(CONFIG_LIST_KUNIT_TEST) += list_kunit.o
+
+obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
pgpAGuimyqnvg.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/riscv/Kconfig
between commit:
5cb0080f1bfd ("riscv: Enable ARCH_STACKWALK")
from the risc-v tree and commit:
46b9b00649f6 ("arch, mm: restore dependency of __kernel_map_pages() on
DEBUG_PAGEALLOC")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/riscv/Kconfig
index 8a2a0523a9a3,9283c6f9ae2a..
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@@ -14,7 -14,7 +14,8 @@@ config RISC
def_bool y
select ARCH_CLOCKSOURCE_INIT
select ARCH_SUPPORTS_ATOMIC_RMW
+ select ARCH_STACKWALK
+ select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_DEBUG_VM_PGTABLE
select ARCH_HAS_DEBUG_VIRTUAL if MMU
pgpVXOo6tKqMS.pgp
Description: OpenPGP digital signature
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
On Tue, 2020-10-06 at 21:48 -0700, Atish Patra wrote:
> On Tue, 2020-10-06 at 21:32 -0700, Palmer Dabbelt wrote:
> > On Tue, 06 Oct 2020 03:39:06 PDT (-0700), Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the akpm-current tree got a conflict
> > > in:
> > >
> > > arch/riscv/mm/init.c
> > >
> > > between commit:
> > >
> > > c29c38fa2a8b ("RISC-V: Remove any memblock representing
> > > unusable
> > > memory area")
> > >
> > > from the risc-v tree and commits:
> > >
> > > 3520eeb79142 ("arch, drivers: replace for_each_membock() with
> > > for_each_mem_range()")
> > >
> > > from the akpm-current tree.
> > >
> > > I fixed it up (see below) and can carry the fix as necessary.
> > > This
> > > is now fixed as far as linux-next is concerned, but any non
> > > trivial
> > > conflicts should be mentioned to your upstream maintainer when
> > > your
> > > tree
> > > is submitted for merging. You may also want to consider
> > > cooperating
> > > with the maintainer of the conflicting tree to minimise any
> > > particularly
> > > complex conflicts.
> > >
> > > It also looks like there is a bug in that risc-v tree patch:
> > > mem_start
> > > is used uninitialised in setup_bootmem().
> > > --
> > > Cheers,
> > > Stephen Rothwell
> > >
> > > diff --cc arch/riscv/mm/init.c
> > > index 812a48c91a95,bc72bb6b5fe0..
> > > --- a/arch/riscv/mm/init.c
> > > +++ b/arch/riscv/mm/init.c
> > > @@@ -152,20 -141,25 +152,20 @@@ disable
> > > }
> > > #endif /* CONFIG_BLK_DEV_INITRD */
> > >
> > > -static phys_addr_t dtb_early_pa __initdata;
> > > -
> > > void __init setup_bootmem(void)
> > > {
> > > - struct memblock_region *reg;
> > > - phys_addr_t mem_start, end = 0;
> > > -phys_addr_t mem_size = 0;
> > > -phys_addr_t total_mem = 0;
> > > + phys_addr_t mem_start, start, end = 0;
> > > phys_addr_t vmlinux_end = __pa_symbol(&_end);
> > > phys_addr_t vmlinux_start = __pa_symbol(&_start);
> > > + u64 i;
> > >
> > > /* Find the memory region containing the kernel */
> > > - for_each_memblock(memory, reg) {
> > > - end = reg->base + reg->size;
> > > + for_each_mem_range(i, , ) {
> > > + phys_addr_t size = end - start;
> > > -if (!total_mem)
> > > +if (!mem_start)
> > > - mem_start = reg->base;
> > > - if (reg->base <= vmlinux_start && vmlinux_end
> > > <= end)
> > > - BUG_ON(reg->size == 0);
> > > + mem_start = start;
> > > + if (start <= vmlinux_start && vmlinux_end <=
> > > end)
> > > + BUG_ON(size == 0);
> > > -total_mem = total_mem + size;
> > > }
> > >
> > > /*
> > > @@@ -542,18 -455,11 +533,18 @@@ static void __init
> > > setup_vm_final(void
> > > {
> > > uintptr_t va, map_size;
> > > phys_addr_t pa, start, end;
> > > - struct memblock_region *reg;
> > > + u64 i;
> > >
> > > -/* Set mmu_enabled flag */
> > > -mmu_enabled = true;
> > > -
> > > +/**
> > > + * MMU is enabled at this point. But page table setup
> > > is not
> > > complete yet.
> > > + * fixmap page table alloc functions should be used at
> > > this
> > > point
> > > + */
> > > +pt_ops.alloc_pte = alloc_pte_fixmap;
> > > +pt_ops.get_pte_virt = get_pte_virt_fixmap;
> > > +#ifndef __PAGETABLE_PMD_FOLDED
> > > +pt_ops.alloc_pmd = alloc_pmd_fixmap;
> > > +pt_ops.get_pmd_virt = get_pmd_virt_fixmap;
> > > +#endif
> > > /* Setup swapper PGD for fixmap */
> > > create_pgd_mapping(swapper_pg_dir, FIXADDR_START,
> > > __pa_symbol(fixmap_pgd_next),
> >
> > Thanks for pointing this out. Given that this is the tip of my
> > for-
> > next I'm
> > just going to drop it, we'll sort out the bug and the conflict.
>
> Thanks. I will rebase on top of next after fixing the bug and resend.
>
Done. I have rebased the memblock patch(c29c38fa2a8b) and sent it to
the mailing list.
Some of the other conflicts are due to the patches in UEFI series. As
the series is going through multiple shared tree, I am not sure what is
the best course of action.
I also noticed that linux-next/master has an older version of UEFI
patches while for-next in riscv tree has the latest version.
Please let me know if I need to resend the UEFI series.
--
Regards,
Atish
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
On Tue, 2020-10-06 at 21:32 -0700, Palmer Dabbelt wrote:
> On Tue, 06 Oct 2020 03:39:06 PDT (-0700), Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the akpm-current tree got a conflict
> > in:
> >
> > arch/riscv/mm/init.c
> >
> > between commit:
> >
> > c29c38fa2a8b ("RISC-V: Remove any memblock representing unusable
> > memory area")
> >
> > from the risc-v tree and commits:
> >
> > 3520eeb79142 ("arch, drivers: replace for_each_membock() with
> > for_each_mem_range()")
> >
> > from the akpm-current tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your
> > tree
> > is submitted for merging. You may also want to consider
> > cooperating
> > with the maintainer of the conflicting tree to minimise any
> > particularly
> > complex conflicts.
> >
> > It also looks like there is a bug in that risc-v tree patch:
> > mem_start
> > is used uninitialised in setup_bootmem().
> > --
> > Cheers,
> > Stephen Rothwell
> >
> > diff --cc arch/riscv/mm/init.c
> > index 812a48c91a95,bc72bb6b5fe0..
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@@ -152,20 -141,25 +152,20 @@@ disable
> > }
> > #endif /* CONFIG_BLK_DEV_INITRD */
> >
> > -static phys_addr_t dtb_early_pa __initdata;
> > -
> > void __init setup_bootmem(void)
> > {
> > - struct memblock_region *reg;
> > - phys_addr_t mem_start, end = 0;
> > - phys_addr_t mem_size = 0;
> > - phys_addr_t total_mem = 0;
> > + phys_addr_t mem_start, start, end = 0;
> > phys_addr_t vmlinux_end = __pa_symbol(&_end);
> > phys_addr_t vmlinux_start = __pa_symbol(&_start);
> > + u64 i;
> >
> > /* Find the memory region containing the kernel */
> > - for_each_memblock(memory, reg) {
> > - end = reg->base + reg->size;
> > + for_each_mem_range(i, , ) {
> > + phys_addr_t size = end - start;
> > - if (!total_mem)
> > + if (!mem_start)
> > - mem_start = reg->base;
> > - if (reg->base <= vmlinux_start && vmlinux_end <= end)
> > - BUG_ON(reg->size == 0);
> > + mem_start = start;
> > + if (start <= vmlinux_start && vmlinux_end <= end)
> > + BUG_ON(size == 0);
> > - total_mem = total_mem + size;
> > }
> >
> > /*
> > @@@ -542,18 -455,11 +533,18 @@@ static void __init
> > setup_vm_final(void
> > {
> > uintptr_t va, map_size;
> > phys_addr_t pa, start, end;
> > - struct memblock_region *reg;
> > + u64 i;
> >
> > - /* Set mmu_enabled flag */
> > - mmu_enabled = true;
> > -
> > + /**
> > + * MMU is enabled at this point. But page table setup is not
> > complete yet.
> > + * fixmap page table alloc functions should be used at this
> > point
> > + */
> > + pt_ops.alloc_pte = alloc_pte_fixmap;
> > + pt_ops.get_pte_virt = get_pte_virt_fixmap;
> > +#ifndef __PAGETABLE_PMD_FOLDED
> > + pt_ops.alloc_pmd = alloc_pmd_fixmap;
> > + pt_ops.get_pmd_virt = get_pmd_virt_fixmap;
> > +#endif
> > /* Setup swapper PGD for fixmap */
> > create_pgd_mapping(swapper_pg_dir, FIXADDR_START,
> >__pa_symbol(fixmap_pgd_next),
>
> Thanks for pointing this out. Given that this is the tip of my for-
> next I'm
> just going to drop it, we'll sort out the bug and the conflict.
Thanks. I will rebase on top of next after fixing the bug and resend.
--
Regards,
Atish
Re: linux-next: manual merge of the akpm-current tree with the risc-v tree
On Tue, 06 Oct 2020 03:39:06 PDT (-0700), Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/riscv/mm/init.c
between commit:
c29c38fa2a8b ("RISC-V: Remove any memblock representing unusable memory area")
from the risc-v tree and commits:
3520eeb79142 ("arch, drivers: replace for_each_membock() with
for_each_mem_range()")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
It also looks like there is a bug in that risc-v tree patch: mem_start
is used uninitialised in setup_bootmem().
--
Cheers,
Stephen Rothwell
diff --cc arch/riscv/mm/init.c
index 812a48c91a95,bc72bb6b5fe0..
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@@ -152,20 -141,25 +152,20 @@@ disable
}
#endif /* CONFIG_BLK_DEV_INITRD */
-static phys_addr_t dtb_early_pa __initdata;
-
void __init setup_bootmem(void)
{
- struct memblock_region *reg;
- phys_addr_t mem_start, end = 0;
- phys_addr_t mem_size = 0;
- phys_addr_t total_mem = 0;
+ phys_addr_t mem_start, start, end = 0;
phys_addr_t vmlinux_end = __pa_symbol(&_end);
phys_addr_t vmlinux_start = __pa_symbol(&_start);
+ u64 i;
/* Find the memory region containing the kernel */
- for_each_memblock(memory, reg) {
- end = reg->base + reg->size;
+ for_each_mem_range(i, , ) {
+ phys_addr_t size = end - start;
- if (!total_mem)
+ if (!mem_start)
- mem_start = reg->base;
- if (reg->base <= vmlinux_start && vmlinux_end <= end)
- BUG_ON(reg->size == 0);
+ mem_start = start;
+ if (start <= vmlinux_start && vmlinux_end <= end)
+ BUG_ON(size == 0);
- total_mem = total_mem + size;
}
/*
@@@ -542,18 -455,11 +533,18 @@@ static void __init setup_vm_final(void
{
uintptr_t va, map_size;
phys_addr_t pa, start, end;
- struct memblock_region *reg;
+ u64 i;
- /* Set mmu_enabled flag */
- mmu_enabled = true;
-
+ /**
+ * MMU is enabled at this point. But page table setup is not complete
yet.
+ * fixmap page table alloc functions should be used at this point
+ */
+ pt_ops.alloc_pte = alloc_pte_fixmap;
+ pt_ops.get_pte_virt = get_pte_virt_fixmap;
+#ifndef __PAGETABLE_PMD_FOLDED
+ pt_ops.alloc_pmd = alloc_pmd_fixmap;
+ pt_ops.get_pmd_virt = get_pmd_virt_fixmap;
+#endif
/* Setup swapper PGD for fixmap */
create_pgd_mapping(swapper_pg_dir, FIXADDR_START,
__pa_symbol(fixmap_pgd_next),
Thanks for pointing this out. Given that this is the tip of my for-next I'm
just going to drop it, we'll sort out the bug and the conflict.
linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/riscv/mm/init.c
between commit:
c29c38fa2a8b ("RISC-V: Remove any memblock representing unusable memory area")
from the risc-v tree and commits:
3520eeb79142 ("arch, drivers: replace for_each_membock() with
for_each_mem_range()")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
It also looks like there is a bug in that risc-v tree patch: mem_start
is used uninitialised in setup_bootmem().
--
Cheers,
Stephen Rothwell
diff --cc arch/riscv/mm/init.c
index 812a48c91a95,bc72bb6b5fe0..
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@@ -152,20 -141,25 +152,20 @@@ disable
}
#endif /* CONFIG_BLK_DEV_INITRD */
-static phys_addr_t dtb_early_pa __initdata;
-
void __init setup_bootmem(void)
{
- struct memblock_region *reg;
- phys_addr_t mem_start, end = 0;
- phys_addr_t mem_size = 0;
- phys_addr_t total_mem = 0;
+ phys_addr_t mem_start, start, end = 0;
phys_addr_t vmlinux_end = __pa_symbol(&_end);
phys_addr_t vmlinux_start = __pa_symbol(&_start);
+ u64 i;
/* Find the memory region containing the kernel */
- for_each_memblock(memory, reg) {
- end = reg->base + reg->size;
+ for_each_mem_range(i, , ) {
+ phys_addr_t size = end - start;
- if (!total_mem)
+ if (!mem_start)
- mem_start = reg->base;
- if (reg->base <= vmlinux_start && vmlinux_end <= end)
- BUG_ON(reg->size == 0);
+ mem_start = start;
+ if (start <= vmlinux_start && vmlinux_end <= end)
+ BUG_ON(size == 0);
- total_mem = total_mem + size;
}
/*
@@@ -542,18 -455,11 +533,18 @@@ static void __init setup_vm_final(void
{
uintptr_t va, map_size;
phys_addr_t pa, start, end;
- struct memblock_region *reg;
+ u64 i;
- /* Set mmu_enabled flag */
- mmu_enabled = true;
-
+ /**
+ * MMU is enabled at this point. But page table setup is not complete
yet.
+ * fixmap page table alloc functions should be used at this point
+ */
+ pt_ops.alloc_pte = alloc_pte_fixmap;
+ pt_ops.get_pte_virt = get_pte_virt_fixmap;
+#ifndef __PAGETABLE_PMD_FOLDED
+ pt_ops.alloc_pmd = alloc_pmd_fixmap;
+ pt_ops.get_pmd_virt = get_pmd_virt_fixmap;
+#endif
/* Setup swapper PGD for fixmap */
create_pgd_mapping(swapper_pg_dir, FIXADDR_START,
__pa_symbol(fixmap_pgd_next),
pgp4wf71ez97z.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
lib/Makefile
between commit:
1a479f783857 ("lib: Add a generic version of devmem_is_allowed()")
from the risc-v tree and commit:
d0bb028dd7f4 ("lib/test_bits.c: add tests of GENMASK")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc lib/Makefile
index 7bdda9ea53ab,591d10906354..
--- a/lib/Makefile
+++ b/lib/Makefile
@@@ -342,5 -317,4 +341,6 @@@ obj-$(CONFIG_OBJAGG) += objagg.
# KUnit tests
obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
+ obj-$(CONFIG_BITS_TEST) += test_bits.o
+
+obj-$(CONFIG_GENERIC_LIB_DEVMEM_IS_ALLOWED) += devmem_is_allowed.o
pgp6sKuyycNPB.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/riscv/Kconfig
between commits:
d3c263cda1a5 ("riscv: Add KGDB support")
ce66581cb6e9 ("riscv: Use the XML target descriptions to report 3 system
registers")
from the risc-v tree and commit:
bbb6dc9ac443 ("riscv: support DEBUG_WX")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/riscv/Kconfig
index 39f7a70cbd72,8576cc027b76..
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@@ -68,8 -67,7 +67,9 @@@ config RISC
select ARCH_HAS_GCOV_PROFILE_ALL
select HAVE_COPY_THREAD_TLS
select HAVE_ARCH_KASAN if MMU && 64BIT
+ select HAVE_ARCH_KGDB
+ select HAVE_ARCH_KGDB_QXFER_PKT
+ select ARCH_HAS_DEBUG_WX
config ARCH_MMAP_RND_BITS_MIN
default 18 if 64BIT
pgpXTU0py2QnQ.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the akpm-current tree with the risc-v tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
arch/riscv/Kconfig
between commit:
d95f1a542c3d ("RISC-V: Implement sparsemem")
from the risc-v tree and commit:
f6a9089b8915 ("riscv: make mmap allocation top-down by default")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc arch/riscv/Kconfig
index 572599cbf750,87dc5370becb..
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@@ -56,7 -54,18 +56,19 @@@ config RISC
select EDAC_SUPPORT
select ARCH_HAS_GIGANTIC_PAGE
select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
+ select SPARSEMEM_STATIC if 32BIT
+ select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
+ select HAVE_ARCH_MMAP_RND_BITS
+
+ config ARCH_MMAP_RND_BITS_MIN
+ default 18 if 64BIT
+ default 8
+
+ # max bits determined by the following formula:
+ # VA_BITS - PAGE_SHIFT - 3
+ config ARCH_MMAP_RND_BITS_MAX
+ default 24 if 64BIT # SV39 based
+ default 17
config MMU
def_bool y
pgpig4OM6djT0.pgp
Description: OpenPGP digital signature
