* Re: [PATCH v2, 1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable
From: Wang Wenhu @ 2020-04-16 4:11 UTC (permalink / raw)
To: oss, Wang Wenhu, gregkh; +Cc: kernel, linuxppc-dev, linux-kernel
In-Reply-To: <36961f9d8c533d8b576043a2c6fc4859accfd9f1.camel@buserror.net>
From: Scott Wood <oss@buserror.net>
>> + bool "32-bit kernel"
>
>Why make that user selectable ?
>
>Either a kernel is 64-bit or it is 32-bit. So having PPC64 user
>selectable is all we need.
>
>And what is the link between this change and the description in the log ?
>
>> default y if !PPC64
>> select KASAN_VMALLOC if KASAN && MODULES
>>
>> @@ -15,6 +15,7 @@ config PPC_BOOK3S_32
>> bool
>>
>> menu "Processor support"
>> +
>
>Why adding this space ?
>
>> choice
>> prompt "Processor Type"
>> depends on PPC32
>> @@ -211,9 +212,9 @@ config PPC_BOOK3E
>> depends on PPC_BOOK3E_64
>>
>> config E500
>> + bool "e500 Support"
>> select FSL_EMB_PERFMON
>> select PPC_FSL_BOOK3E
>> - bool
>
>Why make this user-selectable ? This is already selected by the
>processors requiring it, ie 8500, e5500 and e6500.
>
>Is there any other case where we need E500 ?
>
>And again, what's the link between this change and the description in
>the log ?
>
>
>>
>> config PPC_E500MC
>> bool "e500mc Support"
>>
>
>Christophe
Hi, Scott, Christophe!
I find that I did not get the point well of the defferences between
configurability and selectability(maybe words I created) of Kconfig items.
You are right that FSL_85XX_CACHE_SRAM should only be selected by a caller
but never enable it seperately.
Same answer for the comments from Christophe. I will drop this patch in v3.
Thanks,
Wenhu
^ permalink raw reply
* Re: CVE-2020-11669: Linux kernel 4.10 to 5.1: powerpc: guest can cause DoS on POWER9 KVM hosts
From: Paul Mackerras @ 2020-04-16 4:02 UTC (permalink / raw)
To: Michal Suchánek; +Cc: oss-security, linuxppc-dev, Andrew Donnellan
In-Reply-To: <20200415140329.GC25468@kitsune.suse.cz>
On Wed, Apr 15, 2020 at 04:03:29PM +0200, Michal Suchánek wrote:
> On Wed, Apr 15, 2020 at 10:52:53PM +1000, Andrew Donnellan wrote:
> > The Linux kernel for powerpc from v4.10 to v5.1 has a bug where the
> > Authority Mask Register (AMR), Authority Mask Override Register (AMOR) and
> > User Authority Mask Override Register (UAMOR) are not correctly saved and
> > restored when the CPU is going into/coming out of idle state.
> >
> > On POWER9 CPUs, this means that a CPU may return from idle with the AMR
> > value of another thread on the same core.
> >
> > This allows a trivial Denial of Service attack against KVM hosts, by booting
> > a guest kernel which makes use of the AMR, such as a v5.2 or later kernel
> > with Kernel Userspace Access Prevention (KUAP) enabled.
> >
> > The guest kernel will set the AMR to prevent userspace access, then the
> > thread will go idle. At a later point, the hardware thread that the guest
> > was using may come out of idle and start executing in the host, without
> > restoring the host AMR value. The host kernel can get caught in a page fault
> > loop, as the AMR is unexpectedly causing memory accesses to fail in the
> > host, and the host is eventually rendered unusable.
>
> Hello,
>
> shouldn't the kernel restore the host registers when leaving the guest?
It does. That's not the bug.
> I recall some code exists for handling the *AM*R when leaving guest. Can
> the KVM guest enter idle without exiting to host?
No, we currently never execute the "stop" instruction in guest context.
The bug occurs when a thread that is in the host goes idle and
executes the stop instruction to go to a power-saving state, while
another thread is executing inside a guest. Hardware loses the first
thread's AMR while it is stopped, and as it happens, it is possible
for the first thread to wake up with the contents of its AMR equal to
the other thread's AMR. This can happen even if the first thread has
never executed in the guest.
The kernel needs to save and restore AMR (among other registers)
across the stop instruction because of this hardware behaviour.
We missed the AMR initially, which is what led to this vulnerability.
Paul.
^ permalink raw reply
* [PATCH] KVM: PPC: Handle non-present PTEs in kvmppc_book3s_hv_page_fault()
From: David Gibson @ 2020-04-16 3:53 UTC (permalink / raw)
To: paulus, mpe; +Cc: groug, kvm-ppc, linux-kernel, clg, linuxppc-dev, David Gibson
Since cd758a9b57ee "KVM: PPC: Book3S HV: Use __gfn_to_pfn_memslot in HPT
page fault handler", it's been possible in fairly rare circumstances to
load a non-present PTE in kvmppc_book3s_hv_page_fault() when running a
guest on a POWER8 host.
Because that case wasn't checked for, we could misinterpret the non-present
PTE as being a cache-inhibited PTE. That could mismatch with the
corresponding hash PTE, which would cause the function to fail with -EFAULT
a little further down. That would propagate up to the KVM_RUN ioctl()
generally causing the KVM userspace (usually qemu) to fall over.
This addresses the problem by catching that case and returning to the guest
instead.
Fixes: cd758a9b57ee "KVM: PPC: Book3S HV: Use __gfn_to_pfn_memslot in HPT page fault handler"
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1820402
Suggested-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
arch/powerpc/kvm/book3s_64_mmu_hv.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 6404df613ea3..394fca8e630a 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -616,6 +616,11 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, struct kvm_vcpu *vcpu,
}
pte = *ptep;
local_irq_enable();
+ if (!pte_present(pte)) {
+ if (page)
+ put_page(page);
+ return RESUME_GUEST;
+ }
hpa = pte_pfn(pte) << PAGE_SHIFT;
pte_size = PAGE_SIZE;
if (shift)
--
2.25.2
^ permalink raw reply related
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Nicholas Piggin @ 2020-04-16 3:41 UTC (permalink / raw)
To: Rich Felker; +Cc: libc-dev, libc-alpha, linuxppc-dev, musl
In-Reply-To: <20200416030304.GQ11469@brightrain.aerifal.cx>
Excerpts from Rich Felker's message of April 16, 2020 1:03 pm:
> On Thu, Apr 16, 2020 at 12:53:31PM +1000, Nicholas Piggin wrote:
>> > Not to mention the dcache line to access
>> > __hwcap or whatever, and the icache lines to setup access TOC-relative
>> > access to it. (Of course you could put a copy of its value in TLS at a
>> > fixed offset, which would somewhat mitigate both.)
>> >
>> >> And finally, the HWCAP test can eventually go away in future. A vdso
>> >> call can not.
>> >
>> > We support nearly arbitrarily old kernels (with limited functionality)
>> > and hardware (with full functionality) and don't intend for that to
>> > change, ever. But indeed glibc might want too eventually drop the
>> > check.
>>
>> Ah, cool. Any build-time flexibility there?
>>
>> We may or may not be getting a new ABI that will use instructions not
>> supported by old processors.
>>
>> https://sourceware.org/legacy-ml/binutils/2019-05/msg00331.html
>>
>> Current ABI continues to work of course and be the default for some
>> time, but building for new one would give some opportunity to drop
>> such support for old procs, at least for glibc.
>
> What does "new ABI" entail to you? In the terminology I use with musl,
> "new ABI" and "new ISA level" are different things. You can compile
> (explicit -march or compiler default) binaries that won't run on older
> cpus due to use of new insns etc., but we consider it the same ABI if
> you can link code for an older/baseline ISA level with the
> newer-ISA-level object files, i.e. if the interface surface for
> linkage remains compatible. We also try to avoid gratuitous
> proliferation of different ABIs unless there's a strong underlying
> need (like addition of softfloat ABIs for archs that usually have FPU,
> or vice versa).
Yeah it will be a new ABI type that also requires a new ISA level.
As far as I know (and I'm not on the toolchain side) there will be
some call compatibility between the two, so it may be fine to
continue with existing ABI for libc. But it just something that
comes to mind as a build-time cutover where we might be able to
assume particular features.
> In principle the same could be done for kernels except it's a bigger
> silent gotcha (possible ENOSYS in places where it shouldn't be able to
> happen rather than a trapping SIGILL or similar) and there's rarely
> any serious performance or size benefit to dropping support for older
> kernels.
Right, I don't think it'd be a huge problem whatever way we go,
compared with the cost of the system call.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] papr/scm: Add bad memory ranges to nvdimm bad ranges
From: Vaibhav Jain @ 2020-04-16 3:41 UTC (permalink / raw)
To: Santosh Sivaraj, linuxppc-dev
Cc: Oliver, Ganesh Goudar, Mahesh Salgaonkar, Aneesh Kumar K.V
In-Reply-To: <20200401074741.1562361-1-santosh@fossix.org>
Hi Santosh,
Some review comments below.
Santosh Sivaraj <santosh@fossix.org> writes:
> Subscribe to the MCE notification and add the physical address which
> generated a memory error to nvdimm bad range.
>
> Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
> ---
>
> This patch depends on "powerpc/mce: Add MCE notification chain" [1].
>
> Unlike the previous series[2], the patch adds badblock registration only for
> pseries scm driver. Handling badblocks for baremetal (powernv) PMEM will be done
> later and if possible get the badblock handling as a common code.
>
> [1] https://lore.kernel.org/linuxppc-dev/20200330071219.12284-1-ganeshgr@linux.ibm.com/
> [2] https://lore.kernel.org/linuxppc-dev/20190820023030.18232-1-santosh@fossix.org/
>
> arch/powerpc/platforms/pseries/papr_scm.c | 96 ++++++++++++++++++++++-
> 1 file changed, 95 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index 0b4467e378e5..5012cbf4606e 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -12,6 +12,8 @@
> #include <linux/libnvdimm.h>
> #include <linux/platform_device.h>
> #include <linux/delay.h>
> +#include <linux/nd.h>
> +#include <asm/mce.h>
>
> #include <asm/plpar_wrappers.h>
>
> @@ -39,8 +41,12 @@ struct papr_scm_priv {
> struct resource res;
> struct nd_region *region;
> struct nd_interleave_set nd_set;
> + struct list_head region_list;
> };
>
> +LIST_HEAD(papr_nd_regions);
> +DEFINE_MUTEX(papr_ndr_lock);
> +
> static int drc_pmem_bind(struct papr_scm_priv *p)
> {
> unsigned long ret[PLPAR_HCALL_BUFSIZE];
> @@ -372,6 +378,10 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> dev_info(dev, "Region registered with target node %d and online node %d",
> target_nid, online_nid);
>
> + mutex_lock(&papr_ndr_lock);
> + list_add_tail(&p->region_list, &papr_nd_regions);
> + mutex_unlock(&papr_ndr_lock);
> +
> return 0;
>
> err: nvdimm_bus_unregister(p->bus);
> @@ -379,6 +389,68 @@ err: nvdimm_bus_unregister(p->bus);
> return -ENXIO;
> }
>
> +void papr_scm_add_badblock(struct nd_region *region, struct nvdimm_bus *bus,
> + u64 phys_addr)
> +{
> + u64 aligned_addr = ALIGN_DOWN(phys_addr, L1_CACHE_BYTES);
> +
> + if (nvdimm_bus_add_badrange(bus, aligned_addr, L1_CACHE_BYTES)) {
> + pr_err("Bad block registration for 0x%llx failed\n", phys_addr);
> + return;
> + }
> +
> + pr_debug("Add memory range (0x%llx - 0x%llx) as bad range\n",
> + aligned_addr, aligned_addr + L1_CACHE_BYTES);
> +
> + nvdimm_region_notify(region, NVDIMM_REVALIDATE_POISON);
> +}
> +
> +static int handle_mce_ue(struct notifier_block *nb, unsigned long val,
> + void *data)
> +{
> + struct machine_check_event *evt = data;
> + struct papr_scm_priv *p;
> + u64 phys_addr;
> + bool found = false;
> +
> + if (evt->error_type != MCE_ERROR_TYPE_UE)
> + return NOTIFY_DONE;
> +
> + if (list_empty(&papr_nd_regions))
> + return NOTIFY_DONE;
> +
> + phys_addr = evt->u.ue_error.physical_address +
> + (evt->u.ue_error.effective_address & ~PAGE_MASK);
Though it seems that you are trying to get the actual physical address
from the page aligned evt->u.ue_error.physical_address, it would be nice
if you could put a comment as to why you are doing this seemingly wierd
math with real and effective addresses here.
> +
> + if (!evt->u.ue_error.physical_address_provided ||
> + !is_zone_device_page(pfn_to_page(phys_addr >> PAGE_SHIFT)))
> + return NOTIFY_DONE;
> +
> + /* mce notifier is called from a process context, so mutex is safe */
> + mutex_lock(&papr_ndr_lock);
> + list_for_each_entry(p, &papr_nd_regions, region_list) {
> + struct resource res = p->res;
> +
> + if (phys_addr >= res.start && phys_addr <= res.end) {
> + found = true;
> + break;
> + }
> + }
> +
> + mutex_unlock(&papr_ndr_lock);
> +
> + if (!found)
> + return NOTIFY_DONE;
> +
> + papr_scm_add_badblock(p->region, p->bus, phys_addr);
I see a possible race between papr_scm_add_badblock() and
papr_scm_remove() as a bad block may be reported just remove a region is
disabled. Would recomment calling papr_scm_bad_block() in context of
papr_ndr_lock.
> +
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block mce_ue_nb = {
> + .notifier_call = handle_mce_ue
> +};
> +
> static int papr_scm_probe(struct platform_device *pdev)
> {
> struct device_node *dn = pdev->dev.of_node;
> @@ -476,6 +548,10 @@ static int papr_scm_remove(struct platform_device *pdev)
> {
> struct papr_scm_priv *p = platform_get_drvdata(pdev);
>
> + mutex_lock(&papr_ndr_lock);
> + list_del(&(p->region_list));
> + mutex_unlock(&papr_ndr_lock);
> +
> nvdimm_bus_unregister(p->bus);
> drc_pmem_unbind(p);
> kfree(p->bus_desc.provider_name);
> @@ -498,7 +574,25 @@ static struct platform_driver papr_scm_driver = {
> },
> };
>
> -module_platform_driver(papr_scm_driver);
> +static int __init papr_scm_init(void)
> +{
> + int ret;
> +
> + ret = platform_driver_register(&papr_scm_driver);
> + if (!ret)
> + mce_register_notifier(&mce_ue_nb);
> +
> + return ret;
> +}
> +module_init(papr_scm_init);
> +
> +static void __exit papr_scm_exit(void)
> +{
> + mce_unregister_notifier(&mce_ue_nb);
> + platform_driver_unregister(&papr_scm_driver);
> +}
> +module_exit(papr_scm_exit);
> +
> MODULE_DEVICE_TABLE(of, papr_scm_match);
> MODULE_LICENSE("GPL");
> MODULE_AUTHOR("IBM Corporation");
> --
> 2.25.1
>
--
Vaibhav Jain <vaibhav@linux.ibm.com>
Linux Technology Center, IBM India Pvt. Ltd.
^ permalink raw reply
* Re: [Bug 206203] kmemleak reports various leaks in drivers/of/unittest.c
From: Frank Rowand @ 2020-04-16 3:27 UTC (permalink / raw)
To: Michael Ellerman, Rob Herring; +Cc: devicetree, linuxppc-dev
In-Reply-To: <8383090b-f8d1-f346-5ff3-7234a9d44092@gmail.com>
On 4/8/20 10:22 AM, Frank Rowand wrote:
> Hi Michael,
>
> On 4/7/20 10:13 PM, Michael Ellerman wrote:
>> bugzilla-daemon@bugzilla.kernel.org writes:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=206203
>>>
>>> Erhard F. (erhard_f@mailbox.org) changed:
>>>
>>> What |Removed |Added
>>> ----------------------------------------------------------------------------
>>> Attachment #286801|0 |1
>>> is obsolete| |
>>>
>>> --- Comment #10 from Erhard F. (erhard_f@mailbox.org) ---
>>> Created attachment 288189
>>> --> https://bugzilla.kernel.org/attachment.cgi?id=288189&action=edit
>>> kmemleak output (kernel 5.6.2, Talos II)
>>
>> These are all in or triggered by the of unittest code AFAICS.
>> Content of the log reproduced below.
>>
>> Frank/Rob, are these memory leaks expected?
>
> Thanks for the report. I'll look at each one.
Only one of the leaks was expected. I have patches to fix the
unexpected leaks and to remove the expected leak so that the
kmemleak report of it will not have to be checked again.
I expect to send the patch series tomorrow (Thursday).
-Frank
>
> -Frank
>
>
>>
>> cheers
>>
>>
>> unreferenced object 0xc0000007eb89ca58 (size 192):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.747s)
>> hex dump (first 32 bytes):
>> c0 00 00 00 00 d9 21 38 00 00 00 00 00 00 00 00 ......!8........
>> c0 00 00 07 ec 97 80 08 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<0000000007b50c76>] .__of_node_dup+0x38/0x1c0
>> [<00000000e2115f4f>] .of_unittest_changeset+0x13c/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec978008 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.747s)
>> hex dump (first 8 bytes):
>> 6e 31 00 6b 6b 6b 6b a5 n1.kkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000a074532f>] .__of_node_dup+0x50/0x1c0
>> [<00000000e2115f4f>] .of_unittest_changeset+0x13c/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb89e318 (size 192):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.747s)
>> hex dump (first 32 bytes):
>> c0 00 00 00 00 d9 21 38 00 00 00 00 00 00 00 00 ......!8........
>> c0 00 00 07 ec 97 ab 08 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<0000000007b50c76>] .__of_node_dup+0x38/0x1c0
>> [<00000000881dc9c4>] .of_unittest_changeset+0x194/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec97ab08 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.747s)
>> hex dump (first 8 bytes):
>> 6e 32 00 6b 6b 6b 6b a5 n2.kkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000a074532f>] .__of_node_dup+0x50/0x1c0
>> [<00000000881dc9c4>] .of_unittest_changeset+0x194/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb89e528 (size 192):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.747s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 ec 97 bd d8 00 00 00 00 00 00 00 00 ................
>> c0 00 00 07 ec 97 b3 18 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<0000000007b50c76>] .__of_node_dup+0x38/0x1c0
>> [<00000000af6923cb>] .of_unittest_changeset+0x1ec/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec97b318 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.747s)
>> hex dump (first 8 bytes):
>> 6e 32 31 00 6b 6b 6b a5 n21.kkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000a074532f>] .__of_node_dup+0x50/0x1c0
>> [<00000000af6923cb>] .of_unittest_changeset+0x1ec/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c1fb00 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.757s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 ec 97 90 28 00 00 00 03 00 00 00 00 .......(........
>> c0 00 00 07 ec 97 8e d0 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<000000003079b8f2>] .of_unittest_changeset+0x310/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec979028 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.757s)
>> hex dump (first 8 bytes):
>> 6e 61 6d 65 00 6b 6b a5 name.kk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<000000003079b8f2>] .of_unittest_changeset+0x310/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec978ed0 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.757s)
>> hex dump (first 8 bytes):
>> 6e 31 00 6b 6b 6b 6b a5 n1.kkkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<000000003079b8f2>] .of_unittest_changeset+0x310/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c1bc80 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.757s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 ec 97 b4 70 00 00 00 03 00 00 00 00 .......p........
>> c0 00 00 07 ec 97 b1 c0 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<000000000f97f174>] .of_unittest_changeset+0x368/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec97b470 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.757s)
>> hex dump (first 8 bytes):
>> 6e 61 6d 65 00 6b 6b a5 name.kk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<000000000f97f174>] .of_unittest_changeset+0x368/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec97b1c0 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.757s)
>> hex dump (first 8 bytes):
>> 6e 32 00 6b 6b 6b 6b a5 n2.kkkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<000000000f97f174>] .of_unittest_changeset+0x368/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c1d800 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.764s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 ec 97 88 18 00 00 00 03 00 00 00 00 ................
>> c0 00 00 07 ec 97 bd d8 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<00000000c71a088a>] .of_unittest_changeset+0x3c0/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec978818 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.764s)
>> hex dump (first 8 bytes):
>> 6e 61 6d 65 00 6b 6b a5 name.kk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<00000000c71a088a>] .of_unittest_changeset+0x3c0/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec97bdd8 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.764s)
>> hex dump (first 8 bytes):
>> 6e 32 31 6b 6b 6b 6b a5 n21kkkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<00000000c71a088a>] .of_unittest_changeset+0x3c0/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec979d98 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.764s)
>> hex dump (first 8 bytes):
>> 6e 31 00 6b 6b 6b 6b a5 n1.kkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<0000000001df4c62>] .kvasprintf_const+0xa8/0xf0
>> [<00000000b7ba15a5>] .kobject_set_name_vargs+0x34/0xf0
>> [<0000000076cbbcf2>] .kobject_add+0x50/0xe0
>> [<000000002d7a6157>] .__of_attach_node_sysfs+0xa8/0x160
>> [<000000004ed552f3>] .__of_changeset_entry_apply+0x32c/0x390
>> [<0000000062a8a683>] .__of_changeset_apply_entries+0x48/0x110
>> [<00000000530ec4ee>] .of_changeset_apply+0x54/0xc0
>> [<0000000039fa95c3>] .of_unittest_changeset+0x8a4/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec9796e0 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.764s)
>> hex dump (first 8 bytes):
>> 6e 32 00 6b 6b 6b 6b a5 n2.kkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<0000000001df4c62>] .kvasprintf_const+0xa8/0xf0
>> [<00000000b7ba15a5>] .kobject_set_name_vargs+0x34/0xf0
>> [<0000000076cbbcf2>] .kobject_add+0x50/0xe0
>> [<000000002d7a6157>] .__of_attach_node_sysfs+0xa8/0x160
>> [<000000004ed552f3>] .__of_changeset_entry_apply+0x32c/0x390
>> [<0000000062a8a683>] .__of_changeset_apply_entries+0x48/0x110
>> [<00000000530ec4ee>] .of_changeset_apply+0x54/0xc0
>> [<0000000039fa95c3>] .of_unittest_changeset+0x8a4/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec979ef0 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878935 (age 824.764s)
>> hex dump (first 8 bytes):
>> 6e 32 31 00 6b 6b 6b a5 n21.kkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<0000000001df4c62>] .kvasprintf_const+0xa8/0xf0
>> [<00000000b7ba15a5>] .kobject_set_name_vargs+0x34/0xf0
>> [<0000000076cbbcf2>] .kobject_add+0x50/0xe0
>> [<000000002d7a6157>] .__of_attach_node_sysfs+0xa8/0x160
>> [<000000004ed552f3>] .__of_changeset_entry_apply+0x32c/0x390
>> [<0000000062a8a683>] .__of_changeset_apply_entries+0x48/0x110
>> [<00000000530ec4ee>] .of_changeset_apply+0x54/0xc0
>> [<0000000039fa95c3>] .of_unittest_changeset+0x8a4/0xa20
>> [<00000000925a8013>] .of_unittest+0x1ba0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f2e98800 (size 2048):
>> comm "swapper/0", pid 1, jiffies 4294878936 (age 824.760s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 ec 92 dc 40 ff ff ff ff 00 00 00 00 .......@........
>> c0 00 00 07 ec 92 dc 40 c0 00 20 07 f2 e9 88 18 .......@.. .....
>> backtrace:
>> [<00000000d07b7b2c>] .platform_device_alloc+0x34/0x100
>> [<00000000d9abb21d>] .of_device_alloc+0x44/0x390
>> [<0000000002d381f5>] .of_platform_device_create_pdata+0x78/0x1a0
>> [<00000000c7a45eba>] .of_platform_bus_create+0x214/0x2f0
>> [<00000000c6ba35e7>] .of_platform_bus_create+0x268/0x2f0
>> [<0000000076525030>] .of_platform_populate+0x78/0x140
>> [<00000000d3aeed04>] .of_unittest_platform_populate+0x328/0x50c
>> [<000000003978eb44>] .of_unittest+0x24a8/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec92dc40 (size 64):
>> comm "swapper/0", pid 1, jiffies 4294878936 (age 824.760s)
>> hex dump (first 32 bytes):
>> 74 65 73 74 63 61 73 65 2d 64 61 74 61 3a 70 6c testcase-data:pl
>> 61 74 66 6f 72 6d 2d 74 65 73 74 73 3a 74 65 73 atform-tests:tes
>> backtrace:
>> [<00000000154ad5cf>] .kvasprintf+0x60/0xd0
>> [<00000000b7ba15a5>] .kobject_set_name_vargs+0x34/0xf0
>> [<00000000cce6fd03>] .dev_set_name+0x2c/0x40
>> [<000000007d4be46f>] .of_device_alloc+0x2b0/0x390
>> [<0000000002d381f5>] .of_platform_device_create_pdata+0x78/0x1a0
>> [<00000000c7a45eba>] .of_platform_bus_create+0x214/0x2f0
>> [<00000000c6ba35e7>] .of_platform_bus_create+0x268/0x2f0
>> [<0000000076525030>] .of_platform_populate+0x78/0x140
>> [<00000000d3aeed04>] .of_unittest_platform_populate+0x328/0x50c
>> [<000000003978eb44>] .of_unittest+0x24a8/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb8aa100 (size 256):
>> comm "swapper/0", pid 1, jiffies 4294878936 (age 824.760s)
>> hex dump (first 32 bytes):
>> 00 00 00 00 de ad 4e ad ff ff ff ff 00 00 00 00 ......N.........
>> ff ff ff ff ff ff ff ff c0 00 00 00 02 30 31 a8 .............01.
>> backtrace:
>> [<000000008039b6cb>] .device_add+0x578/0x980
>> [<0000000012aa326f>] .of_device_add+0x58/0x70
>> [<00000000d6a8e21f>] .of_platform_device_create_pdata+0xc4/0x1a0
>> [<00000000c7a45eba>] .of_platform_bus_create+0x214/0x2f0
>> [<00000000c6ba35e7>] .of_platform_bus_create+0x268/0x2f0
>> [<0000000076525030>] .of_platform_populate+0x78/0x140
>> [<00000000d3aeed04>] .of_unittest_platform_populate+0x328/0x50c
>> [<000000003978eb44>] .of_unittest+0x24a8/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f2e9a000 (size 2048):
>> comm "swapper/0", pid 1, jiffies 4294878936 (age 824.764s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f2 e7 a2 40 ff ff ff ff 00 00 00 00 .. ....@........
>> c0 00 20 07 f2 e7 a2 40 c0 00 20 07 f2 e9 a0 18 .. ....@.. .....
>> backtrace:
>> [<00000000d07b7b2c>] .platform_device_alloc+0x34/0x100
>> [<00000000d9abb21d>] .of_device_alloc+0x44/0x390
>> [<0000000002d381f5>] .of_platform_device_create_pdata+0x78/0x1a0
>> [<00000000c7a45eba>] .of_platform_bus_create+0x214/0x2f0
>> [<00000000c6ba35e7>] .of_platform_bus_create+0x268/0x2f0
>> [<0000000076525030>] .of_platform_populate+0x78/0x140
>> [<00000000d3aeed04>] .of_unittest_platform_populate+0x328/0x50c
>> [<000000003978eb44>] .of_unittest+0x24a8/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f2e7a240 (size 64):
>> comm "swapper/0", pid 1, jiffies 4294878936 (age 824.764s)
>> hex dump (first 32 bytes):
>> 74 65 73 74 63 61 73 65 2d 64 61 74 61 3a 70 6c testcase-data:pl
>> 61 74 66 6f 72 6d 2d 74 65 73 74 73 3a 74 65 73 atform-tests:tes
>> backtrace:
>> [<00000000154ad5cf>] .kvasprintf+0x60/0xd0
>> [<00000000b7ba15a5>] .kobject_set_name_vargs+0x34/0xf0
>> [<00000000cce6fd03>] .dev_set_name+0x2c/0x40
>> [<000000007d4be46f>] .of_device_alloc+0x2b0/0x390
>> [<0000000002d381f5>] .of_platform_device_create_pdata+0x78/0x1a0
>> [<00000000c7a45eba>] .of_platform_bus_create+0x214/0x2f0
>> [<00000000c6ba35e7>] .of_platform_bus_create+0x268/0x2f0
>> [<0000000076525030>] .of_platform_populate+0x78/0x140
>> [<00000000d3aeed04>] .of_unittest_platform_populate+0x328/0x50c
>> [<000000003978eb44>] .of_unittest+0x24a8/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb8ac100 (size 256):
>> comm "swapper/0", pid 1, jiffies 4294878936 (age 824.764s)
>> hex dump (first 32 bytes):
>> 00 00 00 00 de ad 4e ad ff ff ff ff 00 00 00 00 ......N.........
>> ff ff ff ff ff ff ff ff c0 00 00 00 02 30 31 a8 .............01.
>> backtrace:
>> [<000000008039b6cb>] .device_add+0x578/0x980
>> [<0000000012aa326f>] .of_device_add+0x58/0x70
>> [<00000000d6a8e21f>] .of_platform_device_create_pdata+0xc4/0x1a0
>> [<00000000c7a45eba>] .of_platform_bus_create+0x214/0x2f0
>> [<00000000c6ba35e7>] .of_platform_bus_create+0x268/0x2f0
>> [<0000000076525030>] .of_platform_populate+0x78/0x140
>> [<00000000d3aeed04>] .of_unittest_platform_populate+0x328/0x50c
>> [<000000003978eb44>] .of_unittest+0x24a8/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb89f7b8 (size 192):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.760s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 f1 ea 17 b0 00 00 00 00 00 00 00 00 ................
>> c0 00 20 07 f2 e8 47 40 00 00 00 00 00 00 00 00 .. ...G@........
>> backtrace:
>> [<0000000007b50c76>] .__of_node_dup+0x38/0x1c0
>> [<000000006f73e286>] .build_changeset_next_level+0x280/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f2e84740 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.764s)
>> hex dump (first 16 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 34 00 a5 test-unittest4..
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000a074532f>] .__of_node_dup+0x50/0x1c0
>> [<000000006f73e286>] .build_changeset_next_level+0x280/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c1c680 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.764s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f2 e8 70 f0 00 00 00 09 00 00 00 00 .. ...p.........
>> c0 00 20 07 f4 2e b6 b0 c0 00 00 07 f1 c1 df 80 .. .............
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f2e870f0 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.764s)
>> hex dump (first 16 bytes):
>> 63 6f 6d 70 61 74 69 62 6c 65 00 6b 6b 6b 6b a5 compatible.kkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f42eb6b0 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.764s)
>> hex dump (first 16 bytes):
>> 75 6e 69 74 74 65 73 74 00 6b 6b 6b 6b 6b 6b a5 unittest.kkkkkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c1df80 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.767s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 ec 7f ec 60 00 00 00 05 00 00 00 00 .......`........
>> c0 00 00 07 ec 7f f4 70 c0 00 00 07 f1 c1 e2 00 .......p........
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec7fec60 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.767s)
>> hex dump (first 8 bytes):
>> 73 74 61 74 75 73 00 a5 status..
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec7ff470 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.767s)
>> hex dump (first 8 bytes):
>> 6f 6b 61 79 00 6b 6b a5 okay.kk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c1e200 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.767s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 ec 7f dc 40 00 00 00 04 00 00 00 00 .......@........
>> c0 00 00 07 ec 7f cc 20 c0 00 00 07 f1 c1 97 00 ....... ........
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec7fdc40 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.767s)
>> hex dump (first 8 bytes):
>> 72 65 67 00 6b 6b 6b a5 reg.kkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec7fcc20 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.767s)
>> hex dump (first 8 bytes):
>> 00 00 00 04 6b 6b 6b a5 ....kkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c19700 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.770s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 ec 7f c5 68 00 00 00 0f 00 00 00 00 .......h........
>> c0 00 20 07 f4 2e bb 00 00 00 00 00 00 00 00 00 .. .............
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec7fc568 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.770s)
>> hex dump (first 8 bytes):
>> 6e 61 6d 65 00 6b 6b a5 name.kk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f42ebb00 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.770s)
>> hex dump (first 16 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 34 00 a5 test-unittest4..
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f42e8fe0 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878937 (age 824.770s)
>> hex dump (first 16 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 34 00 a5 test-unittest4..
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<0000000001df4c62>] .kvasprintf_const+0xa8/0xf0
>> [<00000000b7ba15a5>] .kobject_set_name_vargs+0x34/0xf0
>> [<0000000076cbbcf2>] .kobject_add+0x50/0xe0
>> [<000000002d7a6157>] .__of_attach_node_sysfs+0xa8/0x160
>> [<000000004ed552f3>] .__of_changeset_entry_apply+0x32c/0x390
>> [<0000000062a8a683>] .__of_changeset_apply_entries+0x48/0x110
>> [<0000000067290146>] .of_overlay_fdt_apply+0xb00/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<00000000d856304a>] .of_unittest+0x2758/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb89e108 (size 192):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.767s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 eb a1 c8 a0 00 00 00 00 00 00 00 00 ................
>> c0 00 20 07 f4 2e 8b 90 00 00 00 00 00 00 00 00 .. .............
>> backtrace:
>> [<0000000007b50c76>] .__of_node_dup+0x38/0x1c0
>> [<000000006f73e286>] .build_changeset_next_level+0x280/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f42e8b90 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.767s)
>> hex dump (first 16 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 31 30 00 test-unittest10.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000a074532f>] .__of_node_dup+0x50/0x1c0
>> [<000000006f73e286>] .build_changeset_next_level+0x280/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c18f80 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.767s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f4 2e 8a 20 00 00 00 09 00 00 00 00 .. .... ........
>> c0 00 20 07 f4 2e a5 70 c0 00 00 07 f1 c1 8a 80 .. ....p........
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f42e8a20 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.770s)
>> hex dump (first 16 bytes):
>> 63 6f 6d 70 61 74 69 62 6c 65 00 6b 6b 6b 6b a5 compatible.kkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f42ea570 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.770s)
>> hex dump (first 16 bytes):
>> 75 6e 69 74 74 65 73 74 00 6b 6b 6b 6b 6b 6b a5 unittest.kkkkkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c18a80 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.770s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f5 57 61 a0 00 00 00 05 00 00 00 00 .. ..Wa.........
>> c0 00 20 07 f5 57 4e d0 c0 00 00 07 f1 c1 94 80 .. ..WN.........
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f55761a0 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.774s)
>> hex dump (first 8 bytes):
>> 73 74 61 74 75 73 00 a5 status..
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f5574ed0 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.774s)
>> hex dump (first 8 bytes):
>> 6f 6b 61 79 00 6b 6b a5 okay.kk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c19480 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.774s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f5 57 50 28 00 00 00 04 00 00 00 00 .. ..WP(........
>> c0 00 20 07 f5 57 71 c0 c0 00 00 07 f1 c1 c1 80 .. ..Wq.........
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f5575028 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.774s)
>> hex dump (first 8 bytes):
>> 72 65 67 00 6b 6b 6b a5 reg.kkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f55771c0 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.774s)
>> hex dump (first 8 bytes):
>> 00 00 00 0a 6b 6b 6b a5 ....kkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c1c180 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.774s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f4 2e 99 f0 00 00 00 04 00 00 00 00 .. .............
>> c0 00 20 07 f5 57 74 70 c0 00 00 07 f1 c1 ab 00 .. ..Wtp........
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f5577470 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.777s)
>> hex dump (first 8 bytes):
>> 00 00 00 01 6b 6b 6b a5 ....kkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c1ab00 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.777s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f4 2e 88 b0 00 00 00 04 00 00 00 00 .. .............
>> c0 00 20 07 f5 57 7d d8 c0 00 00 07 f1 c1 8d 00 .. ..W}.........
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f42e88b0 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.777s)
>> hex dump (first 16 bytes):
>> 23 73 69 7a 65 2d 63 65 6c 6c 73 00 6b 6b 6b a5 #size-cells.kkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f5577dd8 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.780s)
>> hex dump (first 8 bytes):
>> 00 00 00 00 6b 6b 6b a5 ....kkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c18d00 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.780s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f5 57 48 18 00 00 00 10 00 00 00 00 .. ..WH.........
>> c0 00 20 07 f4 2e ac a0 00 00 00 00 00 00 00 00 .. .............
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f5574818 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.780s)
>> hex dump (first 8 bytes):
>> 6e 61 6d 65 00 6b 6b a5 name.kk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f42eaca0 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.780s)
>> hex dump (first 16 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 31 30 00 test-unittest10.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb89d8c8 (size 192):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.780s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 eb a1 cb 50 00 00 00 00 00 00 00 00 .......P........
>> c0 00 00 07 ea dd 8d 20 00 00 00 00 00 00 00 00 ....... ........
>> backtrace:
>> [<0000000007b50c76>] .__of_node_dup+0x38/0x1c0
>> [<000000006f73e286>] .build_changeset_next_level+0x280/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eadd8d20 (size 32):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.780s)
>> hex dump (first 32 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 31 30 31 test-unittest101
>> 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 .kkkkkkkkkkkkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000a074532f>] .__of_node_dup+0x50/0x1c0
>> [<000000006f73e286>] .build_changeset_next_level+0x280/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c1a880 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.784s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f4 2e af 80 00 00 00 09 00 00 00 00 .. .............
>> c0 00 20 07 f4 2e 81 80 c0 00 00 07 f1 c1 92 00 .. .............
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f42eaf80 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.784s)
>> hex dump (first 16 bytes):
>> 63 6f 6d 70 61 74 69 62 6c 65 00 6b 6b 6b 6b a5 compatible.kkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f42e8180 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.784s)
>> hex dump (first 16 bytes):
>> 75 6e 69 74 74 65 73 74 00 6b 6b 6b 6b 6b 6b a5 unittest.kkkkkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c19200 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.784s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f5 57 75 c8 00 00 00 05 00 00 00 00 .. ..Wu.........
>> c0 00 20 07 f5 57 7c 80 c0 00 00 07 f1 c1 d3 00 .. ..W|.........
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f55775c8 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.784s)
>> hex dump (first 8 bytes):
>> 73 74 61 74 75 73 00 a5 status..
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f5577c80 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.784s)
>> hex dump (first 8 bytes):
>> 6f 6b 61 79 00 6b 6b a5 okay.kk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f1c1d300 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.787s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f5 57 77 20 00 00 00 04 00 00 00 00 .. ..Ww ........
>> c0 00 20 07 f5 57 5d 98 c0 00 00 07 f2 25 0f 80 .. ..W]......%..
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f5577720 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.787s)
>> hex dump (first 8 bytes):
>> 72 65 67 00 6b 6b 6b a5 reg.kkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f5575d98 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.787s)
>> hex dump (first 8 bytes):
>> 00 00 00 01 6b 6b 6b a5 ....kkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007f2250f80 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.790s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f5 57 68 58 00 00 00 11 00 00 00 00 .. ..WhX........
>> c0 00 00 07 ea dd a2 40 00 00 00 00 00 00 00 00 .......@........
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f5576858 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.790s)
>> hex dump (first 8 bytes):
>> 6e 61 6d 65 00 6b 6b a5 name.kk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eadda240 (size 32):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.790s)
>> hex dump (first 32 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 31 30 31 test-unittest101
>> 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 .kkkkkkkkkkkkkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007ece6bc70 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.790s)
>> hex dump (first 16 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 31 30 00 test-unittest10.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<0000000001df4c62>] .kvasprintf_const+0xa8/0xf0
>> [<00000000b7ba15a5>] .kobject_set_name_vargs+0x34/0xf0
>> [<0000000076cbbcf2>] .kobject_add+0x50/0xe0
>> [<000000002d7a6157>] .__of_attach_node_sysfs+0xa8/0x160
>> [<000000004ed552f3>] .__of_changeset_entry_apply+0x32c/0x390
>> [<0000000062a8a683>] .__of_changeset_apply_entries+0x48/0x110
>> [<0000000067290146>] .of_overlay_fdt_apply+0xb00/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eadd9540 (size 32):
>> comm "swapper/0", pid 1, jiffies 4294878938 (age 824.790s)
>> hex dump (first 32 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 31 30 31 test-unittest101
>> 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 .kkkkkkkkkkkkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<0000000001df4c62>] .kvasprintf_const+0xa8/0xf0
>> [<00000000b7ba15a5>] .kobject_set_name_vargs+0x34/0xf0
>> [<0000000076cbbcf2>] .kobject_add+0x50/0xe0
>> [<000000002d7a6157>] .__of_attach_node_sysfs+0xa8/0x160
>> [<000000004ed552f3>] .__of_changeset_entry_apply+0x32c/0x390
>> [<0000000062a8a683>] .__of_changeset_apply_entries+0x48/0x110
>> [<0000000067290146>] .of_overlay_fdt_apply+0xb00/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<00000000e3d25537>] .of_unittest_apply_overlay_check+0xfc/0x1e4
>> [<000000009b1b95aa>] .of_unittest+0x2da4/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb89e738 (size 192):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.787s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 eb a1 98 a0 00 00 00 00 00 00 00 00 ................
>> c0 00 20 07 ec e6 8e 70 00 00 00 00 00 00 00 00 .. ....p........
>> backtrace:
>> [<0000000007b50c76>] .__of_node_dup+0x38/0x1c0
>> [<000000006f73e286>] .build_changeset_next_level+0x280/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007ece68e70 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.790s)
>> hex dump (first 16 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 31 31 00 test-unittest11.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000a074532f>] .__of_node_dup+0x50/0x1c0
>> [<000000006f73e286>] .build_changeset_next_level+0x280/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec886200 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.790s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 ec e6 a4 00 00 00 00 09 00 00 00 00 .. .............
>> c0 00 20 07 ec e6 99 f0 c0 00 00 07 ec 88 55 80 .. ...........U.
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007ece6a400 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.790s)
>> hex dump (first 16 bytes):
>> 63 6f 6d 70 61 74 69 62 6c 65 00 6b 6b 6b 6b a5 compatible.kkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007ece699f0 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.794s)
>> hex dump (first 16 bytes):
>> 75 6e 69 74 74 65 73 74 00 6b 6b 6b 6b 6b 6b a5 unittest.kkkkkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec885580 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.794s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f8 5d a0 48 00 00 00 05 00 00 00 00 .. ..].H........
>> c0 00 20 07 f8 5d ac 60 c0 00 00 07 ec 88 46 80 .. ..].`......F.
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f85da048 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.794s)
>> hex dump (first 8 bytes):
>> 73 74 61 74 75 73 00 a5 status..
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f85dac60 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.794s)
>> hex dump (first 8 bytes):
>> 6f 6b 61 79 00 6b 6b a5 okay.kk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec884680 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.794s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f8 5d ab 08 00 00 00 04 00 00 00 00 .. ..]..........
>> c0 00 20 07 f8 5d 9a e8 c0 00 00 07 ec 88 6e 80 .. ..]........n.
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f85dab08 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.794s)
>> hex dump (first 8 bytes):
>> 72 65 67 00 6b 6b 6b a5 reg.kkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f85d9ae8 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.797s)
>> hex dump (first 8 bytes):
>> 00 00 00 0b 6b 6b 6b a5 ....kkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec886e80 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.797s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 ec e6 a6 e0 00 00 00 04 00 00 00 00 .. .............
>> c0 00 20 07 f8 5d b3 18 c0 00 00 07 ec 88 44 00 .. ..]........D.
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007ece6a6e0 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.797s)
>> hex dump (first 16 bytes):
>> 23 61 64 64 72 65 73 73 2d 63 65 6c 6c 73 00 a5 #address-cells..
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f85db318 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.797s)
>> hex dump (first 8 bytes):
>> 00 00 00 01 6b 6b 6b a5 ....kkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec884400 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.797s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 ec e6 81 80 00 00 00 04 00 00 00 00 .. .............
>> c0 00 20 07 f8 5d 92 d8 c0 00 00 07 ec 88 3a 00 .. ..]........:.
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007ece68180 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.797s)
>> hex dump (first 16 bytes):
>> 23 73 69 7a 65 2d 63 65 6c 6c 73 00 6b 6b 6b a5 #size-cells.kkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f85d92d8 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.800s)
>> hex dump (first 8 bytes):
>> 00 00 00 00 6b 6b 6b a5 ....kkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec883a00 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.800s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f8 5d 80 08 00 00 00 10 00 00 00 00 .. ..]..........
>> c0 00 20 07 ec e6 b3 d0 00 00 00 00 00 00 00 00 .. .............
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f85d8008 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.800s)
>> hex dump (first 8 bytes):
>> 6e 61 6d 65 00 6b 6b a5 name.kk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007ece6b3d0 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.804s)
>> hex dump (first 16 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 31 31 00 test-unittest11.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb89fde8 (size 192):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.804s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 eb a1 9b 50 00 00 00 00 00 00 00 00 .......P........
>> c0 00 00 07 ea dd 85 00 00 00 00 00 00 00 00 00 ................
>> backtrace:
>> [<0000000007b50c76>] .__of_node_dup+0x38/0x1c0
>> [<000000006f73e286>] .build_changeset_next_level+0x280/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eadd8500 (size 32):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.804s)
>> hex dump (first 32 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 31 31 31 test-unittest111
>> 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 .kkkkkkkkkkkkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000a074532f>] .__of_node_dup+0x50/0x1c0
>> [<000000006f73e286>] .build_changeset_next_level+0x280/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec886c00 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.804s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 ec e6 8a 20 00 00 00 09 00 00 00 00 .. .... ........
>> c0 00 20 07 ec e6 ab 30 c0 00 00 07 ec 88 0a 80 .. ....0........
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007ece68a20 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.804s)
>> hex dump (first 16 bytes):
>> 63 6f 6d 70 61 74 69 62 6c 65 00 6b 6b 6b 6b a5 compatible.kkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007ece6ab30 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.804s)
>> hex dump (first 16 bytes):
>> 75 6e 69 74 74 65 73 74 00 6b 6b 6b 6b 6b 6b a5 unittest.kkkkkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec880a80 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.807s)
>> hex dump (first 32 bytes):
>> c0 00 20 07 f8 5d a5 a8 00 00 00 05 00 00 00 00 .. ..]..........
>> c0 00 00 07 eb 18 c8 18 c0 00 00 07 ec 88 58 00 ..............X.
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f85da5a8 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.807s)
>> hex dump (first 8 bytes):
>> 73 74 61 74 75 73 00 a5 status..
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb18c818 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.807s)
>> hex dump (first 8 bytes):
>> 6f 6b 61 79 00 6b 6b a5 okay.kk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec885800 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.810s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 eb 18 fc 80 00 00 00 04 00 00 00 00 ................
>> c0 00 00 07 eb 18 f4 70 c0 00 00 07 ec 88 41 80 .......p......A.
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb18fc80 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.810s)
>> hex dump (first 8 bytes):
>> 72 65 67 00 6b 6b 6b a5 reg.kkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb18f470 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.810s)
>> hex dump (first 8 bytes):
>> 00 00 00 01 6b 6b 6b a5 ....kkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec884180 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.810s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 eb 18 dd 98 00 00 00 11 00 00 00 00 ................
>> c0 00 00 07 ea dd b4 20 00 00 00 00 00 00 00 00 ....... ........
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb18dd98 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.810s)
>> hex dump (first 8 bytes):
>> 6e 61 6d 65 00 6b 6b a5 name.kk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eaddb420 (size 32):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.810s)
>> hex dump (first 32 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 31 31 31 test-unittest111
>> 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 .kkkkkkkkkkkkkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<0000000038c6aced>] .add_changeset_property.isra.0+0x61c/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<0000000034ba1197>] .build_changeset_next_level+0x334/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007ece6a850 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.814s)
>> hex dump (first 16 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 31 31 00 test-unittest11.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<0000000001df4c62>] .kvasprintf_const+0xa8/0xf0
>> [<00000000b7ba15a5>] .kobject_set_name_vargs+0x34/0xf0
>> [<0000000076cbbcf2>] .kobject_add+0x50/0xe0
>> [<000000002d7a6157>] .__of_attach_node_sysfs+0xa8/0x160
>> [<000000004ed552f3>] .__of_changeset_entry_apply+0x32c/0x390
>> [<0000000062a8a683>] .__of_changeset_apply_entries+0x48/0x110
>> [<0000000067290146>] .of_overlay_fdt_apply+0xb00/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eadda580 (size 32):
>> comm "swapper/0", pid 1, jiffies 4294878939 (age 824.814s)
>> hex dump (first 32 bytes):
>> 74 65 73 74 2d 75 6e 69 74 74 65 73 74 31 31 31 test-unittest111
>> 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 .kkkkkkkkkkkkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<0000000001df4c62>] .kvasprintf_const+0xa8/0xf0
>> [<00000000b7ba15a5>] .kobject_set_name_vargs+0x34/0xf0
>> [<0000000076cbbcf2>] .kobject_add+0x50/0xe0
>> [<000000002d7a6157>] .__of_attach_node_sysfs+0xa8/0x160
>> [<000000004ed552f3>] .__of_changeset_entry_apply+0x32c/0x390
>> [<0000000062a8a683>] .__of_changeset_apply_entries+0x48/0x110
>> [<0000000067290146>] .of_overlay_fdt_apply+0xb00/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<000000003ad7372f>] .of_unittest_apply_overlay.constprop.0+0x54/0xb8
>> [<000000008fda7969>] .of_unittest_apply_revert_overlay_check.constprop.0+0xc4/0x2b4
>> [<00000000ea132166>] .of_unittest+0x2ee0/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec881200 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878943 (age 824.800s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 ec 71 d0 28 00 00 00 0c 00 00 00 00 .....q.(........
>> c0 00 20 07 f2 e8 c5 d0 00 00 00 00 00 00 00 00 .. .............
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<000000004e6be113>] .of_unittest+0x3458/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec71d028 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878943 (age 824.800s)
>> hex dump (first 8 bytes):
>> 6e 61 6d 65 00 6b 6b a5 name.kk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<000000004e6be113>] .of_unittest+0x3458/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007f2e8c5d0 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878943 (age 824.804s)
>> hex dump (first 16 bytes):
>> 5f 5f 73 79 6d 62 6f 6c 73 5f 5f 00 6b 6b 6b a5 __symbols__.kkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<000000004e6be113>] .of_unittest+0x3458/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eaddb280 (size 32):
>> comm "swapper/0", pid 1, jiffies 4294878943 (age 824.804s)
>> hex dump (first 32 bytes):
>> 2f 74 65 73 74 63 61 73 65 2d 64 61 74 61 2d 32 /testcase-data-2
>> 2f 73 75 62 73 74 61 74 69 6f 6e 40 31 30 30 00 /substation@100.
>> backtrace:
>> [<00000000154ad5cf>] .kvasprintf+0x60/0xd0
>> [<00000000c2320ab8>] .kasprintf+0x2c/0x40
>> [<000000005511b2ac>] .add_changeset_property.isra.0+0x170/0xaf0
>> [<0000000060888297>] .of_overlay_fdt_apply+0x5e4/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<00000000daa7ed62>] .of_unittest+0x3404/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eadd9880 (size 32):
>> comm "swapper/0", pid 1, jiffies 4294878943 (age 824.804s)
>> hex dump (first 32 bytes):
>> 2f 74 65 73 74 63 61 73 65 2d 64 61 74 61 2d 32 /testcase-data-2
>> 2f 66 61 69 72 77 61 79 2d 31 00 6b 6b 6b 6b a5 /fairway-1.kkkk.
>> backtrace:
>> [<00000000154ad5cf>] .kvasprintf+0x60/0xd0
>> [<00000000c2320ab8>] .kasprintf+0x2c/0x40
>> [<000000005511b2ac>] .add_changeset_property.isra.0+0x170/0xaf0
>> [<0000000060888297>] .of_overlay_fdt_apply+0x5e4/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<00000000daa7ed62>] .of_unittest+0x3404/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eaddbc40 (size 32):
>> comm "swapper/0", pid 1, jiffies 4294878943 (age 824.804s)
>> hex dump (first 32 bytes):
>> 2f 74 65 73 74 63 61 73 65 2d 64 61 74 61 2d 32 /testcase-data-2
>> 2f 66 61 69 72 77 61 79 2d 31 00 6b 6b 6b 6b a5 /fairway-1.kkkk.
>> backtrace:
>> [<00000000154ad5cf>] .kvasprintf+0x60/0xd0
>> [<00000000c2320ab8>] .kasprintf+0x2c/0x40
>> [<000000005511b2ac>] .add_changeset_property.isra.0+0x170/0xaf0
>> [<0000000060888297>] .of_overlay_fdt_apply+0x5e4/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<00000000daa7ed62>] .of_unittest+0x3404/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eaddbaa0 (size 32):
>> comm "swapper/0", pid 1, jiffies 4294878943 (age 824.804s)
>> hex dump (first 32 bytes):
>> 2f 74 65 73 74 63 61 73 65 2d 64 61 74 61 2d 32 /testcase-data-2
>> 2f 66 61 69 72 77 61 79 2d 31 00 6b 6b 6b 6b a5 /fairway-1.kkkk.
>> backtrace:
>> [<00000000154ad5cf>] .kvasprintf+0x60/0xd0
>> [<00000000c2320ab8>] .kasprintf+0x2c/0x40
>> [<000000005511b2ac>] .add_changeset_property.isra.0+0x170/0xaf0
>> [<0000000060888297>] .of_overlay_fdt_apply+0x5e4/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<00000000daa7ed62>] .of_unittest+0x3404/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec37b000 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878945 (age 824.797s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 eb 7a 42 f0 00 00 00 04 00 00 00 00 .....zB.........
>> c0 00 20 07 ef af e1 a0 00 00 00 00 00 00 00 00 .. .............
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<00000000e6e185ca>] .add_changeset_property.isra.0+0x960/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000043c13a57>] .build_changeset_next_level+0x21c/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<00000000eaf6e6ea>] .of_unittest+0x35b8/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb7a42f0 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878945 (age 824.797s)
>> hex dump (first 16 bytes):
>> 72 70 6d 5f 61 76 61 69 6c 00 6b 6b 6b 6b 6b a5 rpm_avail.kkkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<00000000e6e185ca>] .add_changeset_property.isra.0+0x960/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000043c13a57>] .build_changeset_next_level+0x21c/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<00000000eaf6e6ea>] .of_unittest+0x35b8/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007efafe1a0 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878945 (age 824.797s)
>> hex dump (first 8 bytes):
>> 00 00 00 64 6b 6b 6b a5 ...dkkk.
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<00000000e6e185ca>] .add_changeset_property.isra.0+0x960/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<0000000043c13a57>] .build_changeset_next_level+0x21c/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<00000000eaf6e6ea>] .of_unittest+0x35b8/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007ec37bf00 (size 128):
>> comm "swapper/0", pid 1, jiffies 4294878945 (age 824.797s)
>> hex dump (first 32 bytes):
>> c0 00 00 07 eb 7a 5b 60 00 00 00 08 00 00 00 00 .....z[`........
>> c0 00 20 07 ef af f7 20 00 00 00 00 00 00 00 00 .. .... ........
>> backtrace:
>> [<00000000fd6c039b>] .__of_prop_dup+0x48/0x130
>> [<00000000e6e185ca>] .add_changeset_property.isra.0+0x960/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<00000000eaf6e6ea>] .of_unittest+0x35b8/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0000007eb7a5b60 (size 16):
>> comm "swapper/0", pid 1, jiffies 4294878945 (age 824.800s)
>> hex dump (first 16 bytes):
>> 72 70 6d 5f 61 76 61 69 6c 00 6b 6b 6b 6b 6b a5 rpm_avail.kkkkk.
>> backtrace:
>> [<00000000c939be68>] .kstrdup+0x44/0xb0
>> [<00000000f0610228>] .__of_prop_dup+0x60/0x130
>> [<00000000e6e185ca>] .add_changeset_property.isra.0+0x960/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<00000000eaf6e6ea>] .of_unittest+0x35b8/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>> unreferenced object 0xc0002007efaff720 (size 8):
>> comm "swapper/0", pid 1, jiffies 4294878945 (age 824.800s)
>> hex dump (first 8 bytes):
>> 00 00 00 64 00 00 00 c8 ...d....
>> backtrace:
>> [<00000000a2a61f11>] .kmemdup+0x30/0x70
>> [<00000000fcebe2cd>] .__of_prop_dup+0x7c/0x130
>> [<00000000e6e185ca>] .add_changeset_property.isra.0+0x960/0xaf0
>> [<000000008b0977be>] .build_changeset_next_level+0x74/0x370
>> [<000000009598e32c>] .of_overlay_fdt_apply+0x504/0xf90
>> [<00000000a7d4460c>] .overlay_data_apply+0xa8/0x118
>> [<00000000eaf6e6ea>] .of_unittest+0x35b8/0x3778
>> [<00000000af117d89>] .do_one_initcall+0x7c/0x420
>> [<00000000c99776b4>] .kernel_init_freeable+0x318/0x3d8
>> [<0000000001b957ee>] .kernel_init+0x14/0x168
>> [<000000001fe347b5>] .ret_from_kernel_thread+0x58/0x68
>>
>
>
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-16 3:03 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: libc-dev, libc-alpha, linuxppc-dev, musl
In-Reply-To: <1587004907.ioxh0bxsln.astroid@bobo.none>
On Thu, Apr 16, 2020 at 12:53:31PM +1000, Nicholas Piggin wrote:
> > Not to mention the dcache line to access
> > __hwcap or whatever, and the icache lines to setup access TOC-relative
> > access to it. (Of course you could put a copy of its value in TLS at a
> > fixed offset, which would somewhat mitigate both.)
> >
> >> And finally, the HWCAP test can eventually go away in future. A vdso
> >> call can not.
> >
> > We support nearly arbitrarily old kernels (with limited functionality)
> > and hardware (with full functionality) and don't intend for that to
> > change, ever. But indeed glibc might want too eventually drop the
> > check.
>
> Ah, cool. Any build-time flexibility there?
>
> We may or may not be getting a new ABI that will use instructions not
> supported by old processors.
>
> https://sourceware.org/legacy-ml/binutils/2019-05/msg00331.html
>
> Current ABI continues to work of course and be the default for some
> time, but building for new one would give some opportunity to drop
> such support for old procs, at least for glibc.
What does "new ABI" entail to you? In the terminology I use with musl,
"new ABI" and "new ISA level" are different things. You can compile
(explicit -march or compiler default) binaries that won't run on older
cpus due to use of new insns etc., but we consider it the same ABI if
you can link code for an older/baseline ISA level with the
newer-ISA-level object files, i.e. if the interface surface for
linkage remains compatible. We also try to avoid gratuitous
proliferation of different ABIs unless there's a strong underlying
need (like addition of softfloat ABIs for archs that usually have FPU,
or vice versa).
In principle the same could be done for kernels except it's a bigger
silent gotcha (possible ENOSYS in places where it shouldn't be able to
happen rather than a trapping SIGILL or similar) and there's rarely
any serious performance or size benefit to dropping support for older
kernels.
Rich
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Nicholas Piggin @ 2020-04-16 2:53 UTC (permalink / raw)
To: Rich Felker; +Cc: libc-dev, libc-alpha, linuxppc-dev, musl
In-Reply-To: <20200416023542.GP11469@brightrain.aerifal.cx>
Excerpts from Rich Felker's message of April 16, 2020 12:35 pm:
> On Thu, Apr 16, 2020 at 12:24:16PM +1000, Nicholas Piggin wrote:
>> >> > Likewise, it's not useful to have different error return mechanisms
>> >> > because the caller just has to branch to support both (or the
>> >> > kernel-provided stub just has to emulate one for it; that could work
>> >> > if you really want to change the bad existing convention).
>> >> >
>> >> > Thoughts?
>> >>
>> >> The existing convention has to change somewhat because of the clobbers,
>> >> so I thought we could change the error return at the same time. I'm
>> >> open to not changing it and using CR0[SO], but others liked the idea.
>> >> Pro: it matches sc and vsyscall. Con: it's different from other common
>> >> archs. Performnce-wise it would really be a wash -- cost of conditional
>> >> branch is not the cmp but the mispredict.
>> >
>> > If you do the branch on hwcap at each syscall, then you significantly
>> > increase code size of every syscall point, likely turning a bunch of
>> > trivial functions that didn't need stack frames into ones that do. You
>> > also potentially make them need a TOC pointer. Making them all just do
>> > an indirect call unconditionally (with pointer in TLS like i386?) is a
>> > lot more efficient in code size and at least as good for performance.
>>
>> I disagree. Doing the long vdso indirect call *necessarily* requires
>> touching a new icache line, and even a new TLB entry. Indirect branches
>
> The increase in number of icache lines from the branch at every
> syscall point is far greater than the use of a single extra icache
> line shared by all syscalls.
That's true, I was thinking of a single function that does the test and
calls syscalls, which might be the fair comparison.
> Not to mention the dcache line to access
> __hwcap or whatever, and the icache lines to setup access TOC-relative
> access to it. (Of course you could put a copy of its value in TLS at a
> fixed offset, which would somewhat mitigate both.)
>
>> And finally, the HWCAP test can eventually go away in future. A vdso
>> call can not.
>
> We support nearly arbitrarily old kernels (with limited functionality)
> and hardware (with full functionality) and don't intend for that to
> change, ever. But indeed glibc might want too eventually drop the
> check.
Ah, cool. Any build-time flexibility there?
We may or may not be getting a new ABI that will use instructions not
supported by old processors.
https://sourceware.org/legacy-ml/binutils/2019-05/msg00331.html
Current ABI continues to work of course and be the default for some
time, but building for new one would give some opportunity to drop
such support for old procs, at least for glibc.
>
>> If you really want to select with an indirect branch rather than
>> direct conditional, you can do that all within the library.
>
> OK. It's a little bit more work if that's not the interface the kernel
> will give us, but it's no big deal.
Okay.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH kernel v2 0/7] powerpc/powenv/ioda: Allow huge DMA window at 4GB
From: Oliver O'Halloran @ 2020-04-16 2:53 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: KVM list, Fabiano Rosas, Alistair Popple, kvm-ppc, linuxppc-dev,
David Gibson
In-Reply-To: <CAOSf1CGfjX9LGQ1GDSmxrzjnaWOM3mUvBu9_xe-L2umin9n66w@mail.gmail.com>
On Thu, Apr 16, 2020 at 12:34 PM Oliver O'Halloran <oohall@gmail.com> wrote:
>
> On Thu, Apr 16, 2020 at 11:27 AM Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> >
> > Anyone? Is it totally useless or wrong approach? Thanks,
>
> I wouldn't say it's either, but I still hate it.
>
> The 4GB mode being per-PHB makes it difficult to use unless we force
> that mode on 100% of the time which I'd prefer not to do. Ideally
> devices that actually support 64bit addressing (which is most of them)
> should be able to use no-translate mode when possible since a) It's
> faster, and b) It frees up room in the TCE cache devices that actually
> need them. I know you've done some testing with 100G NICs and found
> the overhead was fine, but IMO that's a bad test since it's pretty
> much the best-case scenario since all the devices on the PHB are in
> the same PE. The PHB's TCE cache only hits when the TCE matches the
> DMA bus address and the PE number for the device so in a multi-PE
> environment there's a lot of potential for TCE cache trashing. If
> there was one or two PEs under that PHB it's probably not going to
> matter, but if you have an NVMe rack with 20 drives it starts to look
> a bit ugly.
>
> That all said, it might be worth doing this anyway since we probably
> want the software infrastructure in place to take advantage of it.
> Maybe expand the command line parameters to allow it to be enabled on
> a per-PHB basis rather than globally.
Since we're on the topic
I've been thinking the real issue we have is that we're trying to pick
an "optimal" IOMMU config at a point where we don't have enough
information to work out what's actually optimal. The IOMMU config is
done on a per-PE basis, but since PEs may contain devices with
different DMA masks (looking at you wierd AMD audio function) we're
always going to have to pick something conservative as the default
config for TVE#0 (64k, no bypass mapping) since the driver will tell
us what the device actually supports long after the IOMMU configuation
is done. What we really want is to be able to have separate IOMMU
contexts for each device, or at the very least a separate context for
the crippled devices.
We could allow a per-device IOMMU context by extending the Master /
Slave PE thing to cover DMA in addition to MMIO. Right now we only use
slave PEs when a device's MMIO BARs extend over multiple m64 segments.
When that happens an MMIO error causes the PHB to freezes the PE
corresponding to one of those segments, but not any of the others. To
present a single "PE" to the EEH core we check the freeze status of
each of the slave PEs when the EEH core does a PE status check and if
any of them are frozen, we freeze the rest of them too. When a driver
sets a limited DMA mask we could move that device to a seperate slave
PE so that it has it's own IOMMU context taylored to its DMA
addressing limits.
Thoughts?
Oliver
^ permalink raw reply
* Re: [PATCH v2 4/4] mm/vmalloc: Hugepage vmalloc mappings
From: Nicholas Piggin @ 2020-04-16 2:38 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch, Catalin Marinas, x86, linux-kernel, linux-mm,
Ingo Molnar, Borislav Petkov, H. Peter Anvin, Thomas Gleixner,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20200415104755.GD12621@willie-the-truck>
Excerpts from Will Deacon's message of April 15, 2020 8:47 pm:
> Hi Nick,
>
> On Mon, Apr 13, 2020 at 10:53:03PM +1000, Nicholas Piggin wrote:
>> For platforms that define HAVE_ARCH_HUGE_VMAP and support PMD vmap mappings,
>> have vmalloc attempt to allocate PMD-sized pages first, before falling back
>> to small pages. Allocations which use something other than PAGE_KERNEL
>> protections are not permitted to use huge pages yet, not all callers expect
>> this (e.g., module allocations vs strict module rwx).
>>
>> This gives a 6x reduction in dTLB misses for a `git diff` (of linux), from
>> 45600 to 6500 and a 2.2% reduction in cycles on a 2-node POWER9.
>
> I wonder if it's worth extending vmap() to handle higher order pages in
> a similar way? That might be helpful for tracing PMUs such as Arm SPE,
> where the CPU streams tracing data out to a virtually addressed buffer
> (see rb_alloc_aux_page()).
Yeah it becomes pretty trivial to do that with VM_HUGE_PAGES after
this patch, I have something to do it but no callers ready yet, if
you have an easy one we can add it.
>> This can result in more internal fragmentation and memory overhead for a
>> given allocation. It can also cause greater NUMA unbalance on hashdist
>> allocations.
>>
>> There may be other callers that expect small pages under vmalloc but use
>> PAGE_KERNEL, I'm not sure if it's feasible to catch them all. An
>> alternative would be a new function or flag which enables large mappings,
>> and use that in callers.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> include/linux/vmalloc.h | 2 +
>> mm/vmalloc.c | 135 +++++++++++++++++++++++++++++-----------
>> 2 files changed, 102 insertions(+), 35 deletions(-)
>>
>> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
>> index 291313a7e663..853b82eac192 100644
>> --- a/include/linux/vmalloc.h
>> +++ b/include/linux/vmalloc.h
>> @@ -24,6 +24,7 @@ struct notifier_block; /* in notifier.h */
>> #define VM_UNINITIALIZED 0x00000020 /* vm_struct is not fully initialized */
>> #define VM_NO_GUARD 0x00000040 /* don't add guard page */
>> #define VM_KASAN 0x00000080 /* has allocated kasan shadow memory */
>> +#define VM_HUGE_PAGES 0x00000100 /* may use huge pages */
>
> Please can you add a check for this in the arm64 change_memory_common()
> code? Other architectures might need something similar, but we need to
> forbid changing memory attributes for portions of the huge page.
Yeah good idea, I can look about adding some more checks.
>
> In general, I'm a bit wary of software table walkers tripping over this.
> For example, I don't think apply_to_existing_page_range() can handle
> huge mappings at all, but the one user (KASAN) only ever uses page mappings
> so it's ok there.
Right, I have something to warn for apply to page range (and looking
at adding support for bigger pages). It doesn't even have a test and
warn at the moment which isn't good practice IMO so we should add one
even without huge vmap.
>
>> @@ -2325,9 +2356,11 @@ static struct vm_struct *__get_vm_area_node(unsigned long size,
>> if (unlikely(!size))
>> return NULL;
>>
>> - if (flags & VM_IOREMAP)
>> - align = 1ul << clamp_t(int, get_count_order_long(size),
>> - PAGE_SHIFT, IOREMAP_MAX_ORDER);
>> + if (flags & VM_IOREMAP) {
>> + align = max(align,
>> + 1ul << clamp_t(int, get_count_order_long(size),
>> + PAGE_SHIFT, IOREMAP_MAX_ORDER));
>> + }
>
>
> I don't follow this part. Please could you explain why you're potentially
> aligning above IOREMAP_MAX_ORDER? It doesn't seem to follow from the rest
> of the patch.
Trying to remember. If the caller asks for a particular alignment we
shouldn't reduce it. Should put it in another patch.
Thanks,
Nick
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-16 2:35 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: libc-dev, libc-alpha, linuxppc-dev, musl
In-Reply-To: <1587002854.f0slo0111r.astroid@bobo.none>
On Thu, Apr 16, 2020 at 12:24:16PM +1000, Nicholas Piggin wrote:
> >> > Likewise, it's not useful to have different error return mechanisms
> >> > because the caller just has to branch to support both (or the
> >> > kernel-provided stub just has to emulate one for it; that could work
> >> > if you really want to change the bad existing convention).
> >> >
> >> > Thoughts?
> >>
> >> The existing convention has to change somewhat because of the clobbers,
> >> so I thought we could change the error return at the same time. I'm
> >> open to not changing it and using CR0[SO], but others liked the idea.
> >> Pro: it matches sc and vsyscall. Con: it's different from other common
> >> archs. Performnce-wise it would really be a wash -- cost of conditional
> >> branch is not the cmp but the mispredict.
> >
> > If you do the branch on hwcap at each syscall, then you significantly
> > increase code size of every syscall point, likely turning a bunch of
> > trivial functions that didn't need stack frames into ones that do. You
> > also potentially make them need a TOC pointer. Making them all just do
> > an indirect call unconditionally (with pointer in TLS like i386?) is a
> > lot more efficient in code size and at least as good for performance.
>
> I disagree. Doing the long vdso indirect call *necessarily* requires
> touching a new icache line, and even a new TLB entry. Indirect branches
The increase in number of icache lines from the branch at every
syscall point is far greater than the use of a single extra icache
line shared by all syscalls. Not to mention the dcache line to access
__hwcap or whatever, and the icache lines to setup access TOC-relative
access to it. (Of course you could put a copy of its value in TLS at a
fixed offset, which would somewhat mitigate both.)
> And finally, the HWCAP test can eventually go away in future. A vdso
> call can not.
We support nearly arbitrarily old kernels (with limited functionality)
and hardware (with full functionality) and don't intend for that to
change, ever. But indeed glibc might want too eventually drop the
check.
> If you really want to select with an indirect branch rather than
> direct conditional, you can do that all within the library.
OK. It's a little bit more work if that's not the interface the kernel
will give us, but it's no big deal.
Rich
^ permalink raw reply
* Re: [PATCH kernel v2 0/7] powerpc/powenv/ioda: Allow huge DMA window at 4GB
From: Oliver O'Halloran @ 2020-04-16 2:34 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: KVM list, Fabiano Rosas, Alistair Popple, kvm-ppc, linuxppc-dev,
David Gibson
In-Reply-To: <d5cac37a-8b32-cabf-e247-10e64f0110ab@ozlabs.ru>
On Thu, Apr 16, 2020 at 11:27 AM Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>
> Anyone? Is it totally useless or wrong approach? Thanks,
I wouldn't say it's either, but I still hate it.
The 4GB mode being per-PHB makes it difficult to use unless we force
that mode on 100% of the time which I'd prefer not to do. Ideally
devices that actually support 64bit addressing (which is most of them)
should be able to use no-translate mode when possible since a) It's
faster, and b) It frees up room in the TCE cache devices that actually
need them. I know you've done some testing with 100G NICs and found
the overhead was fine, but IMO that's a bad test since it's pretty
much the best-case scenario since all the devices on the PHB are in
the same PE. The PHB's TCE cache only hits when the TCE matches the
DMA bus address and the PE number for the device so in a multi-PE
environment there's a lot of potential for TCE cache trashing. If
there was one or two PEs under that PHB it's probably not going to
matter, but if you have an NVMe rack with 20 drives it starts to look
a bit ugly.
That all said, it might be worth doing this anyway since we probably
want the software infrastructure in place to take advantage of it.
Maybe expand the command line parameters to allow it to be enabled on
a per-PHB basis rather than globally.
Oliver
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Nicholas Piggin @ 2020-04-16 2:24 UTC (permalink / raw)
To: Rich Felker; +Cc: libc-dev, libc-alpha, linuxppc-dev, musl
In-Reply-To: <20200416004843.GO11469@brightrain.aerifal.cx>
Excerpts from Rich Felker's message of April 16, 2020 10:48 am:
> On Thu, Apr 16, 2020 at 10:16:54AM +1000, Nicholas Piggin wrote:
>> Excerpts from Rich Felker's message of April 16, 2020 8:55 am:
>> > On Thu, Apr 16, 2020 at 07:45:09AM +1000, Nicholas Piggin wrote:
>> >> I would like to enable Linux support for the powerpc 'scv' instruction,
>> >> as a faster system call instruction.
>> >>
>> >> This requires two things to be defined: Firstly a way to advertise to
>> >> userspace that kernel supports scv, and a way to allocate and advertise
>> >> support for individual scv vectors. Secondly, a calling convention ABI
>> >> for this new instruction.
>> >>
>> >> Thanks to those who commented last time, since then I have removed my
>> >> answered questions and unpopular alternatives but you can find them
>> >> here
>> >>
>> >> https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-January/203545.html
>> >>
>> >> Let me try one more with a wider cc list, and then we'll get something
>> >> merged. Any questions or counter-opinions are welcome.
>> >>
>> >> System Call Vectored (scv) ABI
>> >> ==============================
>> >>
>> >> The scv instruction is introduced with POWER9 / ISA3, it comes with an
>> >> rfscv counter-part. The benefit of these instructions is performance
>> >> (trading slower SRR0/1 with faster LR/CTR registers, and entering the
>> >> kernel with MSR[EE] and MSR[RI] left enabled, which can reduce MSR
>> >> updates. The scv instruction has 128 interrupt entry points (not enough
>> >> to cover the Linux system call space).
>> >>
>> >> The proposal is to assign scv numbers very conservatively and allocate
>> >> them as individual HWCAP features as we add support for more. The zero
>> >> vector ('scv 0') will be used for normal system calls, equivalent to 'sc'.
>> >>
>> >> Advertisement
>> >>
>> >> Linux has not enabled FSCR[SCV] yet, so the instruction will cause a
>> >> SIGILL in current environments. Linux has defined a HWCAP2 bit
>> >> PPC_FEATURE2_SCV for SCV support, but does not set it.
>> >>
>> >> When scv instruction support and the scv 0 vector for system calls are
>> >> added, PPC_FEATURE2_SCV will indicate support for these. Other vectors
>> >> should not be used without future HWCAP bits indicating support, which is
>> >> how we will allocate them. (Should unallocated ones generate SIGILL, or
>> >> return -ENOSYS in r3?)
>> >>
>> >> Calling convention
>> >>
>> >> The proposal is for scv 0 to provide the standard Linux system call ABI
>> >> with the following differences from sc convention[1]:
>> >>
>> >> - LR is to be volatile across scv calls. This is necessary because the
>> >> scv instruction clobbers LR. From previous discussion, this should be
>> >> possible to deal with in GCC clobbers and CFI.
>> >>
>> >> - CR1 and CR5-CR7 are volatile. This matches the C ABI and would allow the
>> >> kernel system call exit to avoid restoring the CR register (although
>> >> we probably still would anyway to avoid information leak).
>> >>
>> >> - Error handling: I think the consensus has been to move to using negative
>> >> return value in r3 rather than CR0[SO]=1 to indicate error, which matches
>> >> most other architectures and is closer to a function call.
>> >>
>> >> The number of scratch registers (r9-r12) at kernel entry seems
>> >> sufficient that we don't have any costly spilling, patch is here[2].
>> >>
>> >> [1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/syscall64-abi.rst
>> >> [2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204840..html
>> >
>> > My preference would be that it work just like the i386 AT_SYSINFO
>> > where you just replace "int $128" with "call *%%gs:16" and the kernel
>> > provides a stub in the vdso that performs either scv or the old
>> > mechanism with the same calling convention. Then if the kernel doesn't
>> > provide it (because the kernel is too old) libc would have to provide
>> > its own stub that uses the legacy method and matches the calling
>> > convention of the one the kernel is expected to provide.
>>
>> I'm not sure if that's necessary. That's done on x86-32 because they
>> select different sequences to use based on the CPU running and if the host
>> kernel is 32 or 64 bit. Sure they could in theory have a bunch of HWCAP
>> bits and select the right sequence in libc as well I suppose.
>
> It's not just a HWCAP. It's a contract between the kernel and
> userspace to support a particular calling convention that's not
> exposed except as the public entry point the kernel exports via
> AT_SYSINFO.
Right.
>> > Note that any libc that actually makes use of the new functionality is
>> > not going to be able to make clobbers conditional on support for it;
>> > branching around different clobbers is going to defeat any gains vs
>> > always just treating anything clobbered by either method as clobbered.
>>
>> Well it would have to test HWCAP and patch in or branch to two
>> completely different sequences including register save/restores yes.
>> You could have the same asm and matching clobbers to put the sequence
>> inline and then you could patch the one sc/scv instruction I suppose.
>>
>> A bit of logic to select between them doesn't defeat gains though,
>> it's about 90 cycle improvement which is a handful of branch mispredicts
>> so it really is an improvement. Eventually userspace will stop
>> supporting the old variant too.
>
> Oh, I didn't mean it would neutralize the benefit of svc. Rather, I
> meant it would be worse to do:
>
> if (hwcap & X) {
> __asm__(... with some clobbers);
> } else {
> __asm__(... with different clobbers);
> }
>
> instead of just
>
> __asm__("indirect call" ... with common clobbers);
Ah okay. Well that's debatable but if you didn't have an indirect call,
rather a runtime-patched sequence, then yes saving the LR clobber or
whatever wouldn't be worth a branch.
> where the indirect call is to an address ideally provided like on
> i386, or otherwise initialized to one of two or more code addresses in
> libc based on hwcap bits.
Right, I'm just skeptical we need the indirect call or need to provide
it in the vdso. The "clever" reason to add it on x86-32 was because of
the bugs and different combinations needed, that doesn't really apply
to scv 0 and was not necessarily a great choice.
>
>> > Likewise, it's not useful to have different error return mechanisms
>> > because the caller just has to branch to support both (or the
>> > kernel-provided stub just has to emulate one for it; that could work
>> > if you really want to change the bad existing convention).
>> >
>> > Thoughts?
>>
>> The existing convention has to change somewhat because of the clobbers,
>> so I thought we could change the error return at the same time. I'm
>> open to not changing it and using CR0[SO], but others liked the idea.
>> Pro: it matches sc and vsyscall. Con: it's different from other common
>> archs. Performnce-wise it would really be a wash -- cost of conditional
>> branch is not the cmp but the mispredict.
>
> If you do the branch on hwcap at each syscall, then you significantly
> increase code size of every syscall point, likely turning a bunch of
> trivial functions that didn't need stack frames into ones that do. You
> also potentially make them need a TOC pointer. Making them all just do
> an indirect call unconditionally (with pointer in TLS like i386?) is a
> lot more efficient in code size and at least as good for performance.
I disagree. Doing the long vdso indirect call *necessarily* requires
touching a new icache line, and even a new TLB entry. Indirect branches
also tend to be more costly and/or less accurate to predict than
direct even without spectre (generally fewer indirect predictor entries
than direct, far branches in particular require a lot of bits for
target). And with spectre we're flushing the indirect predictors
on context switch or even disabling indirect prediction or flushing
across privilege domains in the same context.
And finally, the HWCAP test can eventually go away in future. A vdso
call can not.
If you really want to select with an indirect branch rather than
direct conditional, you can do that all within the library.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH 01/34] docs: filesystems: fix references for doc files there
From: Joseph Qi @ 2020-04-16 1:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Linux Doc Mailing List
Cc: Jan Kara, Rafael J. Wysocki, David Airlie, Amir Goldstein,
dri-devel, linux-unionfs, David Howells, Harry Wei,
Paul Mackerras, Mikulas Patocka, Alex Shi, linux-afs,
Jonathan Corbet, Mark Fasheh, Tyler Hicks, Christoph Hellwig,
Anton Altaparmakov, Federico Vaga, Alexey Dobriyan, freedreno,
linux-arm-msm, ecryptfs, Alexander Viro, Tigran A. Aivazian,
David Sterba, Sean Paul, OGAWA Hirofumi, Nicolas Pitre,
linux-ntfs-dev, Greg Kroah-Hartman, Miklos Szeredi, linux-kernel,
Rob Clark, Daniel Vetter, linux-fsdevel, linuxppc-dev,
ocfs2-devel, Joel Becker
In-Reply-To: <4233bc0ed8d3ebd45da248332c157a9e04a16058.1586960617.git.mchehab+huawei@kernel.org>
On 2020/4/15 22:32, Mauro Carvalho Chehab wrote:
> Several files there were renamed to ReST. Fix the broken
> references.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
> Documentation/ABI/stable/sysfs-devices-node | 2 +-
> Documentation/ABI/testing/procfs-smaps_rollup | 2 +-
> Documentation/admin-guide/cpu-load.rst | 2 +-
> Documentation/admin-guide/nfs/nfsroot.rst | 2 +-
> Documentation/driver-api/driver-model/device.rst | 2 +-
> Documentation/driver-api/driver-model/overview.rst | 2 +-
> Documentation/filesystems/dax.txt | 2 +-
> Documentation/filesystems/dnotify.txt | 2 +-
> Documentation/filesystems/ramfs-rootfs-initramfs.rst | 2 +-
> Documentation/powerpc/firmware-assisted-dump.rst | 2 +-
> Documentation/process/adding-syscalls.rst | 2 +-
> .../translations/it_IT/process/adding-syscalls.rst | 2 +-
> Documentation/translations/zh_CN/filesystems/sysfs.txt | 6 +++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 +-
> fs/Kconfig | 2 +-
> fs/Kconfig.binfmt | 2 +-
> fs/adfs/Kconfig | 2 +-
> fs/affs/Kconfig | 2 +-
> fs/afs/Kconfig | 6 +++---
> fs/bfs/Kconfig | 2 +-
> fs/cramfs/Kconfig | 2 +-
> fs/ecryptfs/Kconfig | 2 +-
> fs/fat/Kconfig | 8 ++++----
> fs/fuse/Kconfig | 2 +-
> fs/fuse/dev.c | 2 +-
> fs/hfs/Kconfig | 2 +-
> fs/hpfs/Kconfig | 2 +-
> fs/isofs/Kconfig | 2 +-
> fs/namespace.c | 2 +-
> fs/notify/inotify/Kconfig | 2 +-
> fs/ntfs/Kconfig | 2 +-
> fs/ocfs2/Kconfig | 2 +-
For ocfs2 part,
Acked-by: Joseph Qi <joseph.qi@linux.alibaba.com>
> fs/overlayfs/Kconfig | 6 +++---
> fs/proc/Kconfig | 4 ++--
> fs/romfs/Kconfig | 2 +-
> fs/sysfs/dir.c | 2 +-
> fs/sysfs/file.c | 2 +-
> fs/sysfs/mount.c | 2 +-
> fs/sysfs/symlink.c | 2 +-
> fs/sysv/Kconfig | 2 +-
> fs/udf/Kconfig | 2 +-
> include/linux/relay.h | 2 +-
> include/linux/sysfs.h | 2 +-
> kernel/relay.c | 2 +-
> 44 files changed, 54 insertions(+), 54 deletions(-)
>
> diff --git a/Documentation/ABI/stable/sysfs-devices-node b/Documentation/ABI/stable/sysfs-devices-node
> index df8413cf1468..484fc04bcc25 100644
> --- a/Documentation/ABI/stable/sysfs-devices-node
> +++ b/Documentation/ABI/stable/sysfs-devices-node
> @@ -54,7 +54,7 @@ Date: October 2002
> Contact: Linux Memory Management list <linux-mm@kvack.org>
> Description:
> Provides information about the node's distribution and memory
> - utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.txt
> + utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.rst
>
> What: /sys/devices/system/node/nodeX/numastat
> Date: October 2002
> diff --git a/Documentation/ABI/testing/procfs-smaps_rollup b/Documentation/ABI/testing/procfs-smaps_rollup
> index 274df44d8b1b..046978193368 100644
> --- a/Documentation/ABI/testing/procfs-smaps_rollup
> +++ b/Documentation/ABI/testing/procfs-smaps_rollup
> @@ -11,7 +11,7 @@ Description:
> Additionally, the fields Pss_Anon, Pss_File and Pss_Shmem
> are not present in /proc/pid/smaps. These fields represent
> the sum of the Pss field of each type (anon, file, shmem).
> - For more details, see Documentation/filesystems/proc.txt
> + For more details, see Documentation/filesystems/proc.rst
> and the procfs man page.
>
> Typical output looks like this:
> diff --git a/Documentation/admin-guide/cpu-load.rst b/Documentation/admin-guide/cpu-load.rst
> index 2d01ce43d2a2..ebdecf864080 100644
> --- a/Documentation/admin-guide/cpu-load.rst
> +++ b/Documentation/admin-guide/cpu-load.rst
> @@ -105,7 +105,7 @@ References
> ----------
>
> - http://lkml.org/lkml/2007/2/12/6
> -- Documentation/filesystems/proc.txt (1.8)
> +- Documentation/filesystems/proc.rst (1.8)
>
>
> Thanks
> diff --git a/Documentation/admin-guide/nfs/nfsroot.rst b/Documentation/admin-guide/nfs/nfsroot.rst
> index 82a4fda057f9..c6772075c80c 100644
> --- a/Documentation/admin-guide/nfs/nfsroot.rst
> +++ b/Documentation/admin-guide/nfs/nfsroot.rst
> @@ -18,7 +18,7 @@ Mounting the root filesystem via NFS (nfsroot)
> In order to use a diskless system, such as an X-terminal or printer server for
> example, it is necessary for the root filesystem to be present on a non-disk
> device. This may be an initramfs (see
> -Documentation/filesystems/ramfs-rootfs-initramfs.txt), a ramdisk (see
> +Documentation/filesystems/ramfs-rootfs-initramfs.rst), a ramdisk (see
> Documentation/admin-guide/initrd.rst) or a filesystem mounted via NFS. The
> following text describes on how to use NFS for the root filesystem. For the rest
> of this text 'client' means the diskless system, and 'server' means the NFS
> diff --git a/Documentation/driver-api/driver-model/device.rst b/Documentation/driver-api/driver-model/device.rst
> index 2b868d49d349..b8c15a39a9a0 100644
> --- a/Documentation/driver-api/driver-model/device.rst
> +++ b/Documentation/driver-api/driver-model/device.rst
> @@ -50,7 +50,7 @@ Attributes
>
> Attributes of devices can be exported by a device driver through sysfs.
>
> -Please see Documentation/filesystems/sysfs.txt for more information
> +Please see Documentation/filesystems/sysfs.rst for more information
> on how sysfs works.
>
> As explained in Documentation/kobject.txt, device attributes must be
> diff --git a/Documentation/driver-api/driver-model/overview.rst b/Documentation/driver-api/driver-model/overview.rst
> index d4d1e9b40e0c..e98d0ab4a9b6 100644
> --- a/Documentation/driver-api/driver-model/overview.rst
> +++ b/Documentation/driver-api/driver-model/overview.rst
> @@ -121,4 +121,4 @@ device-specific data or tunable interfaces.
>
> More information about the sysfs directory layout can be found in
> the other documents in this directory and in the file
> -Documentation/filesystems/sysfs.txt.
> +Documentation/filesystems/sysfs.rst.
> diff --git a/Documentation/filesystems/dax.txt b/Documentation/filesystems/dax.txt
> index 679729442fd2..735f3859b19f 100644
> --- a/Documentation/filesystems/dax.txt
> +++ b/Documentation/filesystems/dax.txt
> @@ -74,7 +74,7 @@ are zeroed out and converted to written extents before being returned to avoid
> exposure of uninitialized data through mmap.
>
> These filesystems may be used for inspiration:
> -- ext2: see Documentation/filesystems/ext2.txt
> +- ext2: see Documentation/filesystems/ext2.rst
> - ext4: see Documentation/filesystems/ext4/
> - xfs: see Documentation/admin-guide/xfs.rst
>
> diff --git a/Documentation/filesystems/dnotify.txt b/Documentation/filesystems/dnotify.txt
> index 15156883d321..08d575ece45d 100644
> --- a/Documentation/filesystems/dnotify.txt
> +++ b/Documentation/filesystems/dnotify.txt
> @@ -67,4 +67,4 @@ See tools/testing/selftests/filesystems/dnotify_test.c for an example.
> NOTE
> ----
> Beginning with Linux 2.6.13, dnotify has been replaced by inotify.
> -See Documentation/filesystems/inotify.txt for more information on it.
> +See Documentation/filesystems/inotify.rst for more information on it.
> diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.rst b/Documentation/filesystems/ramfs-rootfs-initramfs.rst
> index 6c576e241d86..3fddacc6bf14 100644
> --- a/Documentation/filesystems/ramfs-rootfs-initramfs.rst
> +++ b/Documentation/filesystems/ramfs-rootfs-initramfs.rst
> @@ -71,7 +71,7 @@ be allowed write access to a ramfs mount.
>
> A ramfs derivative called tmpfs was created to add size limits, and the ability
> to write the data to swap space. Normal users can be allowed write access to
> -tmpfs mounts. See Documentation/filesystems/tmpfs.txt for more information.
> +tmpfs mounts. See Documentation/filesystems/tmpfs.rst for more information.
>
> What is rootfs?
> ---------------
> diff --git a/Documentation/powerpc/firmware-assisted-dump.rst b/Documentation/powerpc/firmware-assisted-dump.rst
> index b3f3ee135dbe..20ea8cdee0aa 100644
> --- a/Documentation/powerpc/firmware-assisted-dump.rst
> +++ b/Documentation/powerpc/firmware-assisted-dump.rst
> @@ -344,7 +344,7 @@ Here is the list of files under powerpc debugfs:
>
>
> NOTE:
> - Please refer to Documentation/filesystems/debugfs.txt on
> + Please refer to Documentation/filesystems/debugfs.rst on
> how to mount the debugfs filesystem.
>
>
> diff --git a/Documentation/process/adding-syscalls.rst b/Documentation/process/adding-syscalls.rst
> index 1c3a840d06b9..a6b4a3a5bf3f 100644
> --- a/Documentation/process/adding-syscalls.rst
> +++ b/Documentation/process/adding-syscalls.rst
> @@ -33,7 +33,7 @@ interface.
> to a somewhat opaque API.
>
> - If you're just exposing runtime system information, a new node in sysfs
> - (see ``Documentation/filesystems/sysfs.txt``) or the ``/proc`` filesystem may
> + (see ``Documentation/filesystems/sysfs.rst``) or the ``/proc`` filesystem may
> be more appropriate. However, access to these mechanisms requires that the
> relevant filesystem is mounted, which might not always be the case (e.g.
> in a namespaced/sandboxed/chrooted environment). Avoid adding any API to
> diff --git a/Documentation/translations/it_IT/process/adding-syscalls.rst b/Documentation/translations/it_IT/process/adding-syscalls.rst
> index c3a3439595a6..bff0a82bf127 100644
> --- a/Documentation/translations/it_IT/process/adding-syscalls.rst
> +++ b/Documentation/translations/it_IT/process/adding-syscalls.rst
> @@ -39,7 +39,7 @@ vostra interfaccia.
> un qualche modo opaca.
>
> - Se dovete esporre solo delle informazioni sul sistema, un nuovo nodo in
> - sysfs (vedere ``Documentation/filesystems/sysfs.txt``) o
> + sysfs (vedere ``Documentation/filesystems/sysfs.rst``) o
> in procfs potrebbe essere sufficiente. Tuttavia, l'accesso a questi
> meccanismi richiede che il filesystem sia montato, il che potrebbe non
> essere sempre vero (per esempio, in ambienti come namespace/sandbox/chroot).
> diff --git a/Documentation/translations/zh_CN/filesystems/sysfs.txt b/Documentation/translations/zh_CN/filesystems/sysfs.txt
> index ee1f37da5b23..782500d85936 100644
> --- a/Documentation/translations/zh_CN/filesystems/sysfs.txt
> +++ b/Documentation/translations/zh_CN/filesystems/sysfs.txt
> @@ -1,4 +1,4 @@
> -Chinese translated version of Documentation/filesystems/sysfs.txt
> +Chinese translated version of Documentation/filesystems/sysfs.rst
>
> If you have any comment or update to the content, please contact the
> original document maintainer directly. However, if you have a problem
> @@ -10,7 +10,7 @@ Maintainer: Patrick Mochel <mochel@osdl.org>
> Mike Murphy <mamurph@cs.clemson.edu>
> Chinese maintainer: Fu Wei <tekkamanninja@gmail.com>
> ---------------------------------------------------------------------
> -Documentation/filesystems/sysfs.txt 的中文翻译
> +Documentation/filesystems/sysfs.rst 的中文翻译
>
> 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
> 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
> @@ -281,7 +281,7 @@ drivers/ 包含了每个已为特定总线上的设备而挂载的驱动程序
> 假定驱动没有跨越多个总线类型)。
>
> fs/ 包含了一个为文件系统设立的目录。现在每个想要导出属性的文件系统必须
> -在 fs/ 下创建自己的层次结构(参见Documentation/filesystems/fuse.txt)。
> +在 fs/ 下创建自己的层次结构(参见Documentation/filesystems/fuse.rst)。
>
> dev/ 包含两个子目录： char/ 和 block/。在这两个子目录中，有以
> <major>:<minor> 格式命名的符号链接。这些符号链接指向 sysfs 目录
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> index 211f5de99a44..9aba2910d83a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> @@ -170,7 +170,7 @@ struct dpu_global_state
> *
> * Main debugfs documentation is located at,
> *
> - * Documentation/filesystems/debugfs.txt
> + * Documentation/filesystems/debugfs.rst
> *
> * @dpu_debugfs_setup_regset32: Initialize data for dpu_debugfs_create_regset32
> * @dpu_debugfs_create_regset32: Create 32-bit register dump file
> diff --git a/fs/Kconfig b/fs/Kconfig
> index f08fbbfafd9a..d1ad3935fb85 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -166,7 +166,7 @@ config TMPFS
> space. If you unmount a tmpfs instance, everything stored therein is
> lost.
>
> - See <file:Documentation/filesystems/tmpfs.txt> for details.
> + See <file:Documentation/filesystems/tmpfs.rst> for details.
>
> config TMPFS_POSIX_ACL
> bool "Tmpfs POSIX Access Control Lists"
> diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
> index 62dc4f577ba1..3fbbd54f50fd 100644
> --- a/fs/Kconfig.binfmt
> +++ b/fs/Kconfig.binfmt
> @@ -72,7 +72,7 @@ config CORE_DUMP_DEFAULT_ELF_HEADERS
>
> The core dump behavior can be controlled per process using
> the /proc/PID/coredump_filter pseudo-file; this setting is
> - inherited. See Documentation/filesystems/proc.txt for details.
> + inherited. See Documentation/filesystems/proc.rst for details.
>
> This config option changes the default setting of coredump_filter
> seen at boot time. If unsure, say Y.
> diff --git a/fs/adfs/Kconfig b/fs/adfs/Kconfig
> index df4650dccf68..44738fed6625 100644
> --- a/fs/adfs/Kconfig
> +++ b/fs/adfs/Kconfig
> @@ -12,7 +12,7 @@ config ADFS_FS
>
> The ADFS partition should be the first partition (i.e.,
> /dev/[hs]d?1) on each of your drives. Please read the file
> - <file:Documentation/filesystems/adfs.txt> for further details.
> + <file:Documentation/filesystems/adfs.rst> for further details.
>
> To compile this code as a module, choose M here: the module will be
> called adfs.
> diff --git a/fs/affs/Kconfig b/fs/affs/Kconfig
> index 84c46b9025c5..eb9d0ab850cb 100644
> --- a/fs/affs/Kconfig
> +++ b/fs/affs/Kconfig
> @@ -9,7 +9,7 @@ config AFFS_FS
> FFS partition on your hard drive. Amiga floppies however cannot be
> read with this driver due to an incompatibility of the floppy
> controller used in an Amiga and the standard floppy controller in
> - PCs and workstations. Read <file:Documentation/filesystems/affs.txt>
> + PCs and workstations. Read <file:Documentation/filesystems/affs.rst>
> and <file:fs/affs/Changes>.
>
> With this driver you can also mount disk files used by Bernd
> diff --git a/fs/afs/Kconfig b/fs/afs/Kconfig
> index 3fb1f559e317..1ad211d72b3b 100644
> --- a/fs/afs/Kconfig
> +++ b/fs/afs/Kconfig
> @@ -8,7 +8,7 @@ config AFS_FS
> If you say Y here, you will get an experimental Andrew File System
> driver. It currently only supports unsecured read-only AFS access.
>
> - See <file:Documentation/filesystems/afs.txt> for more information.
> + See <file:Documentation/filesystems/afs.rst> for more information.
>
> If unsure, say N.
>
> @@ -18,7 +18,7 @@ config AFS_DEBUG
> help
> Say Y here to make runtime controllable debugging messages appear.
>
> - See <file:Documentation/filesystems/afs.txt> for more information.
> + See <file:Documentation/filesystems/afs.rst> for more information.
>
> If unsure, say N.
>
> @@ -37,6 +37,6 @@ config AFS_DEBUG_CURSOR
> the dmesg log if the server rotation algorithm fails to successfully
> contact a server.
>
> - See <file:Documentation/filesystems/afs.txt> for more information.
> + See <file:Documentation/filesystems/afs.rst> for more information.
>
> If unsure, say N.
> diff --git a/fs/bfs/Kconfig b/fs/bfs/Kconfig
> index 3e1247f07913..3a757805b585 100644
> --- a/fs/bfs/Kconfig
> +++ b/fs/bfs/Kconfig
> @@ -11,7 +11,7 @@ config BFS_FS
> on your /stand slice from within Linux. You then also need to say Y
> to "UnixWare slices support", below. More information about the BFS
> file system is contained in the file
> - <file:Documentation/filesystems/bfs.txt>.
> + <file:Documentation/filesystems/bfs.rst>.
>
> If you don't know what this is about, say N.
>
> diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig
> index c8bebb70a971..d98cef0dbb6b 100644
> --- a/fs/cramfs/Kconfig
> +++ b/fs/cramfs/Kconfig
> @@ -9,7 +9,7 @@ config CRAMFS
> limited to 256MB file systems (with 16MB files), and doesn't support
> 16/32 bits uid/gid, hard links and timestamps.
>
> - See <file:Documentation/filesystems/cramfs.txt> and
> + See <file:Documentation/filesystems/cramfs.rst> and
> <file:fs/cramfs/README> for further information.
>
> To compile this as a module, choose M here: the module will be called
> diff --git a/fs/ecryptfs/Kconfig b/fs/ecryptfs/Kconfig
> index 522c35d5292b..1bdeaa6d5790 100644
> --- a/fs/ecryptfs/Kconfig
> +++ b/fs/ecryptfs/Kconfig
> @@ -7,7 +7,7 @@ config ECRYPT_FS
> select CRYPTO_MD5
> help
> Encrypted filesystem that operates on the VFS layer. See
> - <file:Documentation/filesystems/ecryptfs.txt> to learn more about
> + <file:Documentation/filesystems/ecryptfs.rst> to learn more about
> eCryptfs. Userspace components are required and can be
> obtained from <http://ecryptfs.sf.net>.
>
> diff --git a/fs/fat/Kconfig b/fs/fat/Kconfig
> index 718163d0c621..ca31993dcb47 100644
> --- a/fs/fat/Kconfig
> +++ b/fs/fat/Kconfig
> @@ -69,7 +69,7 @@ config VFAT_FS
>
> The VFAT support enlarges your kernel by about 10 KB and it only
> works if you said Y to the "DOS FAT fs support" above. Please read
> - the file <file:Documentation/filesystems/vfat.txt> for details. If
> + the file <file:Documentation/filesystems/vfat.rst> for details. If
> unsure, say Y.
>
> To compile this as a module, choose M here: the module will be called
> @@ -82,7 +82,7 @@ config FAT_DEFAULT_CODEPAGE
> help
> This option should be set to the codepage of your FAT filesystems.
> It can be overridden with the "codepage" mount option.
> - See <file:Documentation/filesystems/vfat.txt> for more information.
> + See <file:Documentation/filesystems/vfat.rst> for more information.
>
> config FAT_DEFAULT_IOCHARSET
> string "Default iocharset for FAT"
> @@ -96,7 +96,7 @@ config FAT_DEFAULT_IOCHARSET
> Note that "utf8" is not recommended for FAT filesystems.
> If unsure, you shouldn't set "utf8" here - select the next option
> instead if you would like to use UTF-8 encoded file names by default.
> - See <file:Documentation/filesystems/vfat.txt> for more information.
> + See <file:Documentation/filesystems/vfat.rst> for more information.
>
> Enable any character sets you need in File Systems/Native Language
> Support.
> @@ -114,4 +114,4 @@ config FAT_DEFAULT_UTF8
>
> Say Y if you use UTF-8 encoding for file names, N otherwise.
>
> - See <file:Documentation/filesystems/vfat.txt> for more information.
> + See <file:Documentation/filesystems/vfat.rst> for more information.
> diff --git a/fs/fuse/Kconfig b/fs/fuse/Kconfig
> index eb2a585572dc..774b2618018a 100644
> --- a/fs/fuse/Kconfig
> +++ b/fs/fuse/Kconfig
> @@ -12,7 +12,7 @@ config FUSE_FS
> although chances are your distribution already has that library
> installed if you've installed the "fuse" package itself.
>
> - See <file:Documentation/filesystems/fuse.txt> for more information.
> + See <file:Documentation/filesystems/fuse.rst> for more information.
> See <file:Documentation/Changes> for needed library/utility version.
>
> If you want to develop a userspace FS, or if you want to use
> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> index 97eec7522bf2..c7a65cf2bcca 100644
> --- a/fs/fuse/dev.c
> +++ b/fs/fuse/dev.c
> @@ -2081,7 +2081,7 @@ static void end_polls(struct fuse_conn *fc)
> * The same effect is usually achievable through killing the filesystem daemon
> * and all users of the filesystem. The exception is the combination of an
> * asynchronous request and the tricky deadlock (see
> - * Documentation/filesystems/fuse.txt).
> + * Documentation/filesystems/fuse.rst).
> *
> * Aborting requests under I/O goes as follows: 1: Separate out unlocked
> * requests, they should be finished off immediately. Locked requests will be
> diff --git a/fs/hfs/Kconfig b/fs/hfs/Kconfig
> index 44f6e89bcb75..129926b5142d 100644
> --- a/fs/hfs/Kconfig
> +++ b/fs/hfs/Kconfig
> @@ -6,7 +6,7 @@ config HFS_FS
> help
> If you say Y here, you will be able to mount Macintosh-formatted
> floppy disks and hard drive partitions with full read-write access.
> - Please read <file:Documentation/filesystems/hfs.txt> to learn about
> + Please read <file:Documentation/filesystems/hfs.rst> to learn about
> the available mount options.
>
> To compile this file system support as a module, choose M here: the
> diff --git a/fs/hpfs/Kconfig b/fs/hpfs/Kconfig
> index 56aa0336254a..2b36dc6f0a10 100644
> --- a/fs/hpfs/Kconfig
> +++ b/fs/hpfs/Kconfig
> @@ -9,7 +9,7 @@ config HPFS_FS
> write files to an OS/2 HPFS partition on your hard drive. OS/2
> floppies however are in regular MSDOS format, so you don't need this
> option in order to be able to read them. Read
> - <file:Documentation/filesystems/hpfs.txt>.
> + <file:Documentation/filesystems/hpfs.rst>.
>
> To compile this file system support as a module, choose M here: the
> module will be called hpfs. If unsure, say N.
> diff --git a/fs/isofs/Kconfig b/fs/isofs/Kconfig
> index 5e7419599f50..08ffd37b9bb8 100644
> --- a/fs/isofs/Kconfig
> +++ b/fs/isofs/Kconfig
> @@ -8,7 +8,7 @@ config ISO9660_FS
> long Unix filenames and symbolic links are also supported by this
> driver. If you have a CD-ROM drive and want to do more with it than
> just listen to audio CDs and watch its LEDs, say Y (and read
> - <file:Documentation/filesystems/isofs.txt> and the CD-ROM-HOWTO,
> + <file:Documentation/filesystems/isofs.rst> and the CD-ROM-HOWTO,
> available from <http://www.tldp.org/docs.html#howto>), thereby
> enlarging your kernel by about 27 KB; otherwise say N.
>
> diff --git a/fs/namespace.c b/fs/namespace.c
> index e6aed405611d..894a1d12fe5f 100644
> --- a/fs/namespace.c
> +++ b/fs/namespace.c
> @@ -3592,7 +3592,7 @@ EXPORT_SYMBOL(path_is_under);
> * file system may be mounted on put_old. After all, new_root is a mountpoint.
> *
> * Also, the current root cannot be on the 'rootfs' (initial ramfs) filesystem.
> - * See Documentation/filesystems/ramfs-rootfs-initramfs.txt for alternatives
> + * See Documentation/filesystems/ramfs-rootfs-initramfs.rst for alternatives
> * in this situation.
> *
> * Notes:
> diff --git a/fs/notify/inotify/Kconfig b/fs/notify/inotify/Kconfig
> index 6736e47d94d8..7715fadd5fff 100644
> --- a/fs/notify/inotify/Kconfig
> +++ b/fs/notify/inotify/Kconfig
> @@ -12,6 +12,6 @@ config INOTIFY_USER
> new features including multiple file events, one-shot support, and
> unmount notification.
>
> - For more information, see <file:Documentation/filesystems/inotify.txt>
> + For more information, see <file:Documentation/filesystems/inotify.rst>
>
> If unsure, say Y.
> diff --git a/fs/ntfs/Kconfig b/fs/ntfs/Kconfig
> index de9fb5cff226..1667a7e590d8 100644
> --- a/fs/ntfs/Kconfig
> +++ b/fs/ntfs/Kconfig
> @@ -18,7 +18,7 @@ config NTFS_FS
> the Linux 2.4 kernel series is separately available as a patch
> from the project web site.
>
> - For more information see <file:Documentation/filesystems/ntfs.txt>
> + For more information see <file:Documentation/filesystems/ntfs.rst>
> and <http://www.linux-ntfs.org/>.
>
> To compile this file system support as a module, choose M here: the
> diff --git a/fs/ocfs2/Kconfig b/fs/ocfs2/Kconfig
> index 46bba20da6b5..1177c33df895 100644
> --- a/fs/ocfs2/Kconfig
> +++ b/fs/ocfs2/Kconfig
> @@ -21,7 +21,7 @@ config OCFS2_FS
> OCFS2 mailing lists: http://oss.oracle.com/projects/ocfs2/mailman/
>
> For more information on OCFS2, see the file
> - <file:Documentation/filesystems/ocfs2.txt>.
> + <file:Documentation/filesystems/ocfs2.rst>.
>
> config OCFS2_FS_O2CB
> tristate "O2CB Kernelspace Clustering"
> diff --git a/fs/overlayfs/Kconfig b/fs/overlayfs/Kconfig
> index 714c14c47ca5..dd188c7996b3 100644
> --- a/fs/overlayfs/Kconfig
> +++ b/fs/overlayfs/Kconfig
> @@ -9,7 +9,7 @@ config OVERLAY_FS
> 'lower' filesystem is either hidden or, in the case of directories,
> merged with the 'upper' object.
>
> - For more information see Documentation/filesystems/overlayfs.txt
> + For more information see Documentation/filesystems/overlayfs.rst
>
> config OVERLAY_FS_REDIRECT_DIR
> bool "Overlayfs: turn on redirect directory feature by default"
> @@ -38,7 +38,7 @@ config OVERLAY_FS_REDIRECT_ALWAYS_FOLLOW
> If backward compatibility is not an issue, then it is safe and
> recommended to say N here.
>
> - For more information, see Documentation/filesystems/overlayfs.txt
> + For more information, see Documentation/filesystems/overlayfs.rst
>
> If unsure, say Y.
>
> @@ -103,7 +103,7 @@ config OVERLAY_FS_XINO_AUTO
> If compatibility with applications that expect 32bit inodes is not an
> issue, then it is safe and recommended to say Y here.
>
> - For more information, see Documentation/filesystems/overlayfs.txt
> + For more information, see Documentation/filesystems/overlayfs.rst
>
> If unsure, say N.
>
> diff --git a/fs/proc/Kconfig b/fs/proc/Kconfig
> index 27ef84d99f59..971a42f6357d 100644
> --- a/fs/proc/Kconfig
> +++ b/fs/proc/Kconfig
> @@ -23,7 +23,7 @@ config PROC_FS
> /proc" or the equivalent line in /etc/fstab does the job.
>
> The /proc file system is explained in the file
> - <file:Documentation/filesystems/proc.txt> and on the proc(5) manpage
> + <file:Documentation/filesystems/proc.rst> and on the proc(5) manpage
> ("man 5 proc").
>
> This option will enlarge your kernel by about 67 KB. Several
> @@ -95,7 +95,7 @@ config PROC_CHILDREN
> default n
> help
> Provides a fast way to retrieve first level children pids of a task. See
> - <file:Documentation/filesystems/proc.txt> for more information.
> + <file:Documentation/filesystems/proc.rst> for more information.
>
> Say Y if you are running any user-space software which takes benefit from
> this interface. For example, rkt is such a piece of software.
> diff --git a/fs/romfs/Kconfig b/fs/romfs/Kconfig
> index ad4c45788896..9737b8e68878 100644
> --- a/fs/romfs/Kconfig
> +++ b/fs/romfs/Kconfig
> @@ -6,7 +6,7 @@ config ROMFS_FS
> This is a very small read-only file system mainly intended for
> initial ram disks of installation disks, but it could be used for
> other read-only media as well. Read
> - <file:Documentation/filesystems/romfs.txt> for details.
> + <file:Documentation/filesystems/romfs.rst> for details.
>
> To compile this file system support as a module, choose M here: the
> module will be called romfs. Note that the file system of your
> diff --git a/fs/sysfs/dir.c b/fs/sysfs/dir.c
> index aa85f2874a9f..59dffd5ca517 100644
> --- a/fs/sysfs/dir.c
> +++ b/fs/sysfs/dir.c
> @@ -6,7 +6,7 @@
> * Copyright (c) 2007 SUSE Linux Products GmbH
> * Copyright (c) 2007 Tejun Heo <teheo@suse.de>
> *
> - * Please see Documentation/filesystems/sysfs.txt for more information.
> + * Please see Documentation/filesystems/sysfs.rst for more information.
> */
>
> #define pr_fmt(fmt) "sysfs: " fmt
> diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
> index 26bbf960e2a2..f275fcda62fb 100644
> --- a/fs/sysfs/file.c
> +++ b/fs/sysfs/file.c
> @@ -6,7 +6,7 @@
> * Copyright (c) 2007 SUSE Linux Products GmbH
> * Copyright (c) 2007 Tejun Heo <teheo@suse.de>
> *
> - * Please see Documentation/filesystems/sysfs.txt for more information.
> + * Please see Documentation/filesystems/sysfs.rst for more information.
> */
>
> #include <linux/module.h>
> diff --git a/fs/sysfs/mount.c b/fs/sysfs/mount.c
> index db81cfbab9d6..e747c135c1d1 100644
> --- a/fs/sysfs/mount.c
> +++ b/fs/sysfs/mount.c
> @@ -6,7 +6,7 @@
> * Copyright (c) 2007 SUSE Linux Products GmbH
> * Copyright (c) 2007 Tejun Heo <teheo@suse.de>
> *
> - * Please see Documentation/filesystems/sysfs.txt for more information.
> + * Please see Documentation/filesystems/sysfs.rst for more information.
> */
>
> #include <linux/fs.h>
> diff --git a/fs/sysfs/symlink.c b/fs/sysfs/symlink.c
> index c4deecc80f67..5603530a1a52 100644
> --- a/fs/sysfs/symlink.c
> +++ b/fs/sysfs/symlink.c
> @@ -6,7 +6,7 @@
> * Copyright (c) 2007 SUSE Linux Products GmbH
> * Copyright (c) 2007 Tejun Heo <teheo@suse.de>
> *
> - * Please see Documentation/filesystems/sysfs.txt for more information.
> + * Please see Documentation/filesystems/sysfs.rst for more information.
> */
>
> #include <linux/fs.h>
> diff --git a/fs/sysv/Kconfig b/fs/sysv/Kconfig
> index d4edf7d9ae10..b4e23e03fbeb 100644
> --- a/fs/sysv/Kconfig
> +++ b/fs/sysv/Kconfig
> @@ -28,7 +28,7 @@ config SYSV_FS
> tar" or preferably "info tar"). Note also that this option has
> nothing whatsoever to do with the option "System V IPC". Read about
> the System V file system in
> - <file:Documentation/filesystems/sysv-fs.txt>.
> + <file:Documentation/filesystems/sysv-fs.rst>.
> Saying Y here will enlarge your kernel by about 27 KB.
>
> To compile this as a module, choose M here: the module will be called
> diff --git a/fs/udf/Kconfig b/fs/udf/Kconfig
> index 6848de581ce1..26e1a49f3ba7 100644
> --- a/fs/udf/Kconfig
> +++ b/fs/udf/Kconfig
> @@ -9,7 +9,7 @@ config UDF_FS
> compatible with standard unix file systems, it is also suitable for
> removable USB disks. Say Y if you intend to mount DVD discs or CDRW's
> written in packet mode, or if you want to use UDF for removable USB
> - disks. Please read <file:Documentation/filesystems/udf.txt>.
> + disks. Please read <file:Documentation/filesystems/udf.rst>.
>
> To compile this file system support as a module, choose M here: the
> module will be called udf.
> diff --git a/include/linux/relay.h b/include/linux/relay.h
> index c759f96e39c1..e13a333e7c37 100644
> --- a/include/linux/relay.h
> +++ b/include/linux/relay.h
> @@ -141,7 +141,7 @@ struct rchan_callbacks
> * cause relay_open() to create a single global buffer rather
> * than the default set of per-cpu buffers.
> *
> - * See Documentation/filesystems/relay.txt for more info.
> + * See Documentation/filesystems/relay.rst for more info.
> */
> struct dentry *(*create_buf_file)(const char *filename,
> struct dentry *parent,
> diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
> index 80bb865b3a33..86067dbe7745 100644
> --- a/include/linux/sysfs.h
> +++ b/include/linux/sysfs.h
> @@ -7,7 +7,7 @@
> * Copyright (c) 2007 SUSE Linux Products GmbH
> * Copyright (c) 2007 Tejun Heo <teheo@suse.de>
> *
> - * Please see Documentation/filesystems/sysfs.txt for more information.
> + * Please see Documentation/filesystems/sysfs.rst for more information.
> */
>
> #ifndef _SYSFS_H_
> diff --git a/kernel/relay.c b/kernel/relay.c
> index 07ee1a791d85..628f570ca678 100644
> --- a/kernel/relay.c
> +++ b/kernel/relay.c
> @@ -1,7 +1,7 @@
> /*
> * Public API and common code for kernel->userspace relay file support.
> *
> - * See Documentation/filesystems/relay.txt for an overview.
> + * See Documentation/filesystems/relay.rst for an overview.
> *
> * Copyright (C) 2002-2005 - Tom Zanussi (zanussi@us.ibm.com), IBM Corp
> * Copyright (C) 1999-2005 - Karim Yaghmour (karim@opersys.com)
>
^ permalink raw reply
* Re: [PATCH kernel v2 0/7] powerpc/powenv/ioda: Allow huge DMA window at 4GB
From: Alexey Kardashevskiy @ 2020-04-16 1:27 UTC (permalink / raw)
To: linuxppc-dev
Cc: kvm, Fabiano Rosas, Alistair Popple, kvm-ppc, Oliver,
David Gibson
In-Reply-To: <b512ac5e-dca5-4c08-8ea1-a636b887c0d0@ozlabs.ru>
Anyone? Is it totally useless or wrong approach? Thanks,
On 08/04/2020 19:43, Alexey Kardashevskiy wrote:
>
>
> On 23/03/2020 18:53, Alexey Kardashevskiy wrote:
>> Here is an attempt to support bigger DMA space for devices
>> supporting DMA masks less than 59 bits (GPUs come into mind
>> first). POWER9 PHBs have an option to map 2 windows at 0
>> and select a windows based on DMA address being below or above
>> 4GB.
>>
>> This adds the "iommu=iommu_bypass" kernel parameter and
>> supports VFIO+pseries machine - current this requires telling
>> upstream+unmodified QEMU about this via
>> -global spapr-pci-host-bridge.dma64_win_addr=0x100000000
>> or per-phb property. 4/4 advertises the new option but
>> there is no automation around it in QEMU (should it be?).
>>
>> For now it is either 1<<59 or 4GB mode; dynamic switching is
>> not supported (could be via sysfs).
>>
>> This is a rebased version of
>> https://lore.kernel.org/kvm/20191202015953.127902-1-aik@ozlabs.ru/
>>
>> The main change since v1 is that now it is 7 patches with
>> clearer separation of steps.
>>
>>
>> This is based on 6c90b86a745a "Merge tag 'mmc-v5.6-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc"
>>
>> Please comment. Thanks.
>
> Ping?
>
>
>>
>>
>>
>> Alexey Kardashevskiy (7):
>> powerpc/powernv/ioda: Move TCE bypass base to PE
>> powerpc/powernv/ioda: Rework for huge DMA window at 4GB
>> powerpc/powernv/ioda: Allow smaller TCE table levels
>> powerpc/powernv/phb4: Use IOMMU instead of bypassing
>> powerpc/iommu: Add a window number to
>> iommu_table_group_ops::get_table_size
>> powerpc/powernv/phb4: Add 4GB IOMMU bypass mode
>> vfio/spapr_tce: Advertise and allow a huge DMA windows at 4GB
>>
>> arch/powerpc/include/asm/iommu.h | 3 +
>> arch/powerpc/include/asm/opal-api.h | 9 +-
>> arch/powerpc/include/asm/opal.h | 2 +
>> arch/powerpc/platforms/powernv/pci.h | 4 +-
>> include/uapi/linux/vfio.h | 2 +
>> arch/powerpc/platforms/powernv/npu-dma.c | 1 +
>> arch/powerpc/platforms/powernv/opal-call.c | 2 +
>> arch/powerpc/platforms/powernv/pci-ioda-tce.c | 4 +-
>> arch/powerpc/platforms/powernv/pci-ioda.c | 234 ++++++++++++++----
>> drivers/vfio/vfio_iommu_spapr_tce.c | 17 +-
>> 10 files changed, 213 insertions(+), 65 deletions(-)
>>
>
--
Alexey
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: 85xx: make FSL_85XX_CACHE_SRAM configurable
From: kbuild test robot @ 2020-04-16 0:58 UTC (permalink / raw)
To: Wang Wenhu, gregkh, linux-kernel, oss, christophe.leroy,
linuxppc-dev
Cc: kernel, Wang Wenhu, kbuild-all
In-Reply-To: <20200415123346.116212-2-wenhu.wang@vivo.com>
[-- Attachment #1: Type: text/plain, Size: 21439 bytes --]
Hi Wang,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on char-misc/char-misc-testing staging/staging-testing v5.7-rc1 next-20200415]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Wang-Wenhu/drivers-uio-new-driver-uio_fsl_85xx_cache_sram/20200416-040633
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-allyesconfig (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All error/warnings (new ones prefixed by >>):
WARNING: unmet direct dependencies detected for ARCH_32BIT_OFF_T
Depends on !64BIT
Selected by
- PPC && PPC32
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:14:3: error: conflicting types for 'atomic64_t'
14 | } atomic64_t;
| ^~~~~~~~~~
In file included from include/linux/page-flags.h:9,
from kernel/bounds.c:10:
include/linux/types.h:178:3: note: previous declaration of 'atomic64_t' was here
178 | } atomic64_t;
| ^~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:18:12: error: conflicting types for 'atomic64_read'
18 | extern s64 atomic64_read(const atomic64_t
| ^~~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:300:23: note: previous definition of 'atomic64_read' was here
300 | static __inline__ s64 atomic64_read(const atomic64_t
| ^~~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:19:13: error: conflicting types for 'atomic64_set'
19 | extern void atomic64_set(atomic64_t s64 i);
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:309:24: note: previous definition of 'atomic64_set' was here
309 | static __inline__ void atomic64_set(atomic64_t s64 i)
| ^~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:32: warning: "ATOMIC64_OPS" redefined
32 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op)
|
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:380: note: this is the location of the previous definition
380 | #define ATOMIC64_OPS(op, asm_op) |
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_add'
24 | extern void atomic64_##op(s64 a, atomic64_t
| ^~~~~~~~~
>> include/asm-generic/atomic64.h:32:26: note: in expansion of macro 'ATOMIC64_OP'
32 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op)
| ^~~~~~~~~~~
>> include/asm-generic/atomic64.h:34:1: note: in expansion of macro 'ATOMIC64_OPS'
34 | ATOMIC64_OPS(add)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_add' was here
315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~
>> arch/powerpc/include/asm/atomic.h:366:2: note: in expansion of macro 'ATOMIC64_OP'
366 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~
>> arch/powerpc/include/asm/atomic.h:370:1: note: in expansion of macro 'ATOMIC64_OPS'
370 | ATOMIC64_OPS(add, add)
| ^~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_sub'
24 | extern void atomic64_##op(s64 a, atomic64_t
| ^~~~~~~~~
>> include/asm-generic/atomic64.h:32:26: note: in expansion of macro 'ATOMIC64_OP'
32 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op)
| ^~~~~~~~~~~
include/asm-generic/atomic64.h:35:1: note: in expansion of macro 'ATOMIC64_OPS'
35 | ATOMIC64_OPS(sub)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_sub' was here
315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~
>> arch/powerpc/include/asm/atomic.h:366:2: note: in expansion of macro 'ATOMIC64_OP'
366 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:371:1: note: in expansion of macro 'ATOMIC64_OPS'
371 | ATOMIC64_OPS(sub, subf)
| ^~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_and'
24 | extern void atomic64_##op(s64 a, atomic64_t
| ^~~~~~~~~
include/asm-generic/atomic64.h:38:26: note: in expansion of macro 'ATOMIC64_OP'
38 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op)
| ^~~~~~~~~~~
include/asm-generic/atomic64.h:40:1: note: in expansion of macro 'ATOMIC64_OPS'
40 | ATOMIC64_OPS(and)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_and' was here
315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~
arch/powerpc/include/asm/atomic.h:381:2: note: in expansion of macro 'ATOMIC64_OP'
381 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:384:1: note: in expansion of macro 'ATOMIC64_OPS'
384 | ATOMIC64_OPS(and, and)
| ^~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_or'
24 | extern void atomic64_##op(s64 a, atomic64_t
| ^~~~~~~~~
include/asm-generic/atomic64.h:38:26: note: in expansion of macro 'ATOMIC64_OP'
38 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op)
| ^~~~~~~~~~~
include/asm-generic/atomic64.h:41:1: note: in expansion of macro 'ATOMIC64_OPS'
41 | ATOMIC64_OPS(or)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_or' was here
315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~
arch/powerpc/include/asm/atomic.h:381:2: note: in expansion of macro 'ATOMIC64_OP'
381 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:385:1: note: in expansion of macro 'ATOMIC64_OPS'
385 | ATOMIC64_OPS(or, or)
| ^~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> include/asm-generic/atomic64.h:24:14: error: conflicting types for 'atomic64_xor'
24 | extern void atomic64_##op(s64 a, atomic64_t
| ^~~~~~~~~
include/asm-generic/atomic64.h:38:26: note: in expansion of macro 'ATOMIC64_OP'
38 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op)
| ^~~~~~~~~~~
include/asm-generic/atomic64.h:42:1: note: in expansion of macro 'ATOMIC64_OPS'
42 | ATOMIC64_OPS(xor)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:315:24: note: previous definition of 'atomic64_xor' was here
315 | static __inline__ void atomic64_##op(s64 a, atomic64_t | ^~~~~~~~~
arch/powerpc/include/asm/atomic.h:381:2: note: in expansion of macro 'ATOMIC64_OP'
381 | ATOMIC64_OP(op, asm_op) | ^~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:386:1: note: in expansion of macro 'ATOMIC64_OPS'
386 | ATOMIC64_OPS(xor, xor)
| ^~~~~~~~~~~~
>> arch/powerpc/include/asm/atomic.h:485:34: error: conflicting types for 'atomic64_dec_if_positive'
485 | #define atomic64_dec_if_positive atomic64_dec_if_positive
| ^~~~~~~~~~~~~~~~~~~~~~~~
>> include/asm-generic/atomic64.h:49:12: note: in expansion of macro 'atomic64_dec_if_positive'
49 | extern s64 atomic64_dec_if_positive(atomic64_t
| ^~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:466:23: note: previous definition of 'atomic64_dec_if_positive' was here
466 | static __inline__ s64 atomic64_dec_if_positive(atomic64_t
| ^~~~~~~~~~~~~~~~~~~~~~~~
In file included from arch/powerpc/include/asm/atomic.h:11,
from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
>> arch/powerpc/include/asm/cmpxchg.h:482:4: error: expected identifier or '(' before '{' token
482 | ({ | ^
>> arch/powerpc/include/asm/atomic.h:487:36: note: in expansion of macro 'cmpxchg'
487 | #define atomic64_cmpxchg(v, o, n) (cmpxchg(&((v)->counter), (o), (n)))
| ^~~~~~~
>> include/asm-generic/atomic64.h:51:12: note: in expansion of macro 'atomic64_cmpxchg'
51 | extern s64 atomic64_cmpxchg(atomic64_t s64 o, s64 n);
| ^~~~~~~~~~~~~~~~
In file included from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
include/linux/atomic.h:66:2: error: expected identifier or '(' before '{' token
66 | ({ | ^
include/linux/atomic-fallback.h:27:2: note: in expansion of macro '__atomic_op_fence'
27 | __atomic_op_fence(xchg, __VA_ARGS__)
| ^~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:493:32: note: in expansion of macro 'xchg'
493 | #define atomic64_xchg(v, new) (xchg(&((v)->counter), new))
| ^~~~
include/asm-generic/atomic64.h:52:12: note: in expansion of macro 'atomic64_xchg'
52 | extern s64 atomic64_xchg(atomic64_t s64 new);
| ^~~~~~~~~~~~~
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:526:35: error: conflicting types for 'atomic64_fetch_add_unless'
526 | #define atomic64_fetch_add_unless atomic64_fetch_add_unless
| ^~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/atomic64.h:53:12: note: in expansion of macro 'atomic64_fetch_add_unless'
53 | extern s64 atomic64_fetch_add_unless(atomic64_t s64 a, s64 u);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:505:23: note: previous definition of 'atomic64_fetch_add_unless' was here
505 | static __inline__ s64 atomic64_fetch_add_unless(atomic64_t s64 a, s64 u)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
include/linux/atomic-fallback.h: In function 'atomic64_add_return_acquire':
include/linux/atomic-fallback.h:1216:43: error: passing argument 2 of 'atomic64_add_return_relaxed' from incompatible pointer type
1216 | s64 ret = atomic64_add_return_relaxed(i, v);
| ^
| |
| atomic64_t Makefile arch block certs crypto drivers fs include init ipc kernel lib mm net scripts security sound source usr virt {aka struct <anonymous>
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:331:51: note: expected 'atomic64_t {aka 'struct <anonymous> but argument is of type 'atomic64_t {aka 'struct <anonymous>
331 | atomic64_##op##_return_relaxed(s64 a, atomic64_t | ~~~~~~~~~~~~^
arch/powerpc/include/asm/atomic.h:367:2: note: in expansion of macro 'ATOMIC64_OP_RETURN_RELAXED'
367 | ATOMIC64_OP_RETURN_RELAXED(op, asm_op) | ^~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:370:1: note: in expansion of macro 'ATOMIC64_OPS'
370 | ATOMIC64_OPS(add, add)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
include/linux/atomic-fallback.h: In function 'atomic64_add_return_release':
include/linux/atomic-fallback.h:1228:40: error: passing argument 2 of 'atomic64_add_return_relaxed' from incompatible pointer type
1228 | return atomic64_add_return_relaxed(i, v);
| ^
| |
| atomic64_t Makefile arch block certs crypto drivers fs include init ipc kernel lib mm net scripts security sound source usr virt {aka struct <anonymous>
In file included from include/linux/atomic.h:7,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
arch/powerpc/include/asm/atomic.h:331:51: note: expected 'atomic64_t {aka 'struct <anonymous> but argument is of type 'atomic64_t {aka 'struct <anonymous>
331 | atomic64_##op##_return_relaxed(s64 a, atomic64_t | ~~~~~~~~~~~~^
arch/powerpc/include/asm/atomic.h:367:2: note: in expansion of macro 'ATOMIC64_OP_RETURN_RELAXED'
367 | ATOMIC64_OP_RETURN_RELAXED(op, asm_op) | ^~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/atomic.h:370:1: note: in expansion of macro 'ATOMIC64_OPS'
370 | ATOMIC64_OPS(add, add)
| ^~~~~~~~~~~~
In file included from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
include/linux/atomic-fallback.h: At top level:
include/linux/atomic-fallback.h:1235:1: error: static declaration of 'atomic64_add_return' follows non-static declaration
1235 | atomic64_add_return(s64 i, atomic64_t
| ^~~~~~~~~~~~~~~~~~~
In file included from include/linux/atomic-fallback.h:1185,
from include/linux/atomic.h:74,
from include/linux/debug_locks.h:6,
from include/linux/lockdep.h:28,
from include/linux/spinlock_types.h:18,
from kernel/bounds.c:14:
include/asm-generic/atomic64.h:27:12: note: previous declaration of 'atomic64_add_return' was here
27 | extern s64 atomic64_##op##_return(s64 a, atomic64_t
| ^~~~~~~~~
include/asm-generic/atomic64.h:32:42: note: in expansion of macro 'ATOMIC64_OP_RETURN'
32 | #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op)
| ^~~~~~~~~~~~~~~~~~
include/asm-generic/atomic64.h:34:1: note: in expansion of macro 'ATOMIC64_OPS'
34 | ATOMIC64_OPS(add)
vim +/atomic64_t +14 include/asm-generic/atomic64.h
09d4e0edd4614e7 Paul Mackerras 2009-06-12 11
09d4e0edd4614e7 Paul Mackerras 2009-06-12 12 typedef struct {
9255813d5841e15 Mark Rutland 2019-05-22 13 s64 counter;
09d4e0edd4614e7 Paul Mackerras 2009-06-12 @14 } atomic64_t;
09d4e0edd4614e7 Paul Mackerras 2009-06-12 15
09d4e0edd4614e7 Paul Mackerras 2009-06-12 16 #define ATOMIC64_INIT(i) { (i) }
09d4e0edd4614e7 Paul Mackerras 2009-06-12 17
9255813d5841e15 Mark Rutland 2019-05-22 @18 extern s64 atomic64_read(const atomic64_t *v);
9255813d5841e15 Mark Rutland 2019-05-22 @19 extern void atomic64_set(atomic64_t *v, s64 i);
560cb12a4080a48 Peter Zijlstra 2014-04-23 20
9d664c0aec3bfdb Peter Zijlstra 2017-06-09 21 #define atomic64_set_release(v, i) atomic64_set((v), (i))
9d664c0aec3bfdb Peter Zijlstra 2017-06-09 22
560cb12a4080a48 Peter Zijlstra 2014-04-23 23 #define ATOMIC64_OP(op) \
9255813d5841e15 Mark Rutland 2019-05-22 @24 extern void atomic64_##op(s64 a, atomic64_t *v);
560cb12a4080a48 Peter Zijlstra 2014-04-23 25
560cb12a4080a48 Peter Zijlstra 2014-04-23 26 #define ATOMIC64_OP_RETURN(op) \
9255813d5841e15 Mark Rutland 2019-05-22 27 extern s64 atomic64_##op##_return(s64 a, atomic64_t *v);
560cb12a4080a48 Peter Zijlstra 2014-04-23 28
28aa2bda2211f43 Peter Zijlstra 2016-04-18 29 #define ATOMIC64_FETCH_OP(op) \
9255813d5841e15 Mark Rutland 2019-05-22 30 extern s64 atomic64_fetch_##op(s64 a, atomic64_t *v);
28aa2bda2211f43 Peter Zijlstra 2016-04-18 31
28aa2bda2211f43 Peter Zijlstra 2016-04-18 @32 #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op)
560cb12a4080a48 Peter Zijlstra 2014-04-23 33
560cb12a4080a48 Peter Zijlstra 2014-04-23 @34 ATOMIC64_OPS(add)
560cb12a4080a48 Peter Zijlstra 2014-04-23 35 ATOMIC64_OPS(sub)
560cb12a4080a48 Peter Zijlstra 2014-04-23 36
28aa2bda2211f43 Peter Zijlstra 2016-04-18 37 #undef ATOMIC64_OPS
28aa2bda2211f43 Peter Zijlstra 2016-04-18 38 #define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op)
28aa2bda2211f43 Peter Zijlstra 2016-04-18 39
28aa2bda2211f43 Peter Zijlstra 2016-04-18 40 ATOMIC64_OPS(and)
28aa2bda2211f43 Peter Zijlstra 2016-04-18 41 ATOMIC64_OPS(or)
28aa2bda2211f43 Peter Zijlstra 2016-04-18 42 ATOMIC64_OPS(xor)
e6942b7de2dfe44 Peter Zijlstra 2014-04-23 43
560cb12a4080a48 Peter Zijlstra 2014-04-23 44 #undef ATOMIC64_OPS
28aa2bda2211f43 Peter Zijlstra 2016-04-18 45 #undef ATOMIC64_FETCH_OP
560cb12a4080a48 Peter Zijlstra 2014-04-23 46 #undef ATOMIC64_OP_RETURN
560cb12a4080a48 Peter Zijlstra 2014-04-23 47 #undef ATOMIC64_OP
560cb12a4080a48 Peter Zijlstra 2014-04-23 48
9255813d5841e15 Mark Rutland 2019-05-22 @49 extern s64 atomic64_dec_if_positive(atomic64_t *v);
b3a2a05f9111de0 Mark Rutland 2018-06-21 50 #define atomic64_dec_if_positive atomic64_dec_if_positive
9255813d5841e15 Mark Rutland 2019-05-22 @51 extern s64 atomic64_cmpxchg(atomic64_t *v, s64 o, s64 n);
9255813d5841e15 Mark Rutland 2019-05-22 @52 extern s64 atomic64_xchg(atomic64_t *v, s64 new);
9255813d5841e15 Mark Rutland 2019-05-22 @53 extern s64 atomic64_fetch_add_unless(atomic64_t *v, s64 a, s64 u);
00b808ab79ead37 Mark Rutland 2018-06-21 54 #define atomic64_fetch_add_unless atomic64_fetch_add_unless
09d4e0edd4614e7 Paul Mackerras 2009-06-12 55
:::::: The code at line 14 was first introduced by commit
:::::: 09d4e0edd4614e787393acc582ac701c6ec3565b lib: Provide generic atomic64_t implementation
:::::: TO: Paul Mackerras <paulus@samba.org>
:::::: CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 68870 bytes --]
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-16 0:48 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: libc-dev, libc-alpha, linuxppc-dev, musl
In-Reply-To: <1586994952.nnxigedbu2.astroid@bobo.none>
On Thu, Apr 16, 2020 at 10:16:54AM +1000, Nicholas Piggin wrote:
> Excerpts from Rich Felker's message of April 16, 2020 8:55 am:
> > On Thu, Apr 16, 2020 at 07:45:09AM +1000, Nicholas Piggin wrote:
> >> I would like to enable Linux support for the powerpc 'scv' instruction,
> >> as a faster system call instruction.
> >>
> >> This requires two things to be defined: Firstly a way to advertise to
> >> userspace that kernel supports scv, and a way to allocate and advertise
> >> support for individual scv vectors. Secondly, a calling convention ABI
> >> for this new instruction.
> >>
> >> Thanks to those who commented last time, since then I have removed my
> >> answered questions and unpopular alternatives but you can find them
> >> here
> >>
> >> https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-January/203545.html
> >>
> >> Let me try one more with a wider cc list, and then we'll get something
> >> merged. Any questions or counter-opinions are welcome.
> >>
> >> System Call Vectored (scv) ABI
> >> ==============================
> >>
> >> The scv instruction is introduced with POWER9 / ISA3, it comes with an
> >> rfscv counter-part. The benefit of these instructions is performance
> >> (trading slower SRR0/1 with faster LR/CTR registers, and entering the
> >> kernel with MSR[EE] and MSR[RI] left enabled, which can reduce MSR
> >> updates. The scv instruction has 128 interrupt entry points (not enough
> >> to cover the Linux system call space).
> >>
> >> The proposal is to assign scv numbers very conservatively and allocate
> >> them as individual HWCAP features as we add support for more. The zero
> >> vector ('scv 0') will be used for normal system calls, equivalent to 'sc'.
> >>
> >> Advertisement
> >>
> >> Linux has not enabled FSCR[SCV] yet, so the instruction will cause a
> >> SIGILL in current environments. Linux has defined a HWCAP2 bit
> >> PPC_FEATURE2_SCV for SCV support, but does not set it.
> >>
> >> When scv instruction support and the scv 0 vector for system calls are
> >> added, PPC_FEATURE2_SCV will indicate support for these. Other vectors
> >> should not be used without future HWCAP bits indicating support, which is
> >> how we will allocate them. (Should unallocated ones generate SIGILL, or
> >> return -ENOSYS in r3?)
> >>
> >> Calling convention
> >>
> >> The proposal is for scv 0 to provide the standard Linux system call ABI
> >> with the following differences from sc convention[1]:
> >>
> >> - LR is to be volatile across scv calls. This is necessary because the
> >> scv instruction clobbers LR. From previous discussion, this should be
> >> possible to deal with in GCC clobbers and CFI.
> >>
> >> - CR1 and CR5-CR7 are volatile. This matches the C ABI and would allow the
> >> kernel system call exit to avoid restoring the CR register (although
> >> we probably still would anyway to avoid information leak).
> >>
> >> - Error handling: I think the consensus has been to move to using negative
> >> return value in r3 rather than CR0[SO]=1 to indicate error, which matches
> >> most other architectures and is closer to a function call.
> >>
> >> The number of scratch registers (r9-r12) at kernel entry seems
> >> sufficient that we don't have any costly spilling, patch is here[2].
> >>
> >> [1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/syscall64-abi.rst
> >> [2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204840..html
> >
> > My preference would be that it work just like the i386 AT_SYSINFO
> > where you just replace "int $128" with "call *%%gs:16" and the kernel
> > provides a stub in the vdso that performs either scv or the old
> > mechanism with the same calling convention. Then if the kernel doesn't
> > provide it (because the kernel is too old) libc would have to provide
> > its own stub that uses the legacy method and matches the calling
> > convention of the one the kernel is expected to provide.
>
> I'm not sure if that's necessary. That's done on x86-32 because they
> select different sequences to use based on the CPU running and if the host
> kernel is 32 or 64 bit. Sure they could in theory have a bunch of HWCAP
> bits and select the right sequence in libc as well I suppose.
It's not just a HWCAP. It's a contract between the kernel and
userspace to support a particular calling convention that's not
exposed except as the public entry point the kernel exports via
AT_SYSINFO.
> > Note that any libc that actually makes use of the new functionality is
> > not going to be able to make clobbers conditional on support for it;
> > branching around different clobbers is going to defeat any gains vs
> > always just treating anything clobbered by either method as clobbered.
>
> Well it would have to test HWCAP and patch in or branch to two
> completely different sequences including register save/restores yes.
> You could have the same asm and matching clobbers to put the sequence
> inline and then you could patch the one sc/scv instruction I suppose.
>
> A bit of logic to select between them doesn't defeat gains though,
> it's about 90 cycle improvement which is a handful of branch mispredicts
> so it really is an improvement. Eventually userspace will stop
> supporting the old variant too.
Oh, I didn't mean it would neutralize the benefit of svc. Rather, I
meant it would be worse to do:
if (hwcap & X) {
__asm__(... with some clobbers);
} else {
__asm__(... with different clobbers);
}
instead of just
__asm__("indirect call" ... with common clobbers);
where the indirect call is to an address ideally provided like on
i386, or otherwise initialized to one of two or more code addresses in
libc based on hwcap bits.
> > Likewise, it's not useful to have different error return mechanisms
> > because the caller just has to branch to support both (or the
> > kernel-provided stub just has to emulate one for it; that could work
> > if you really want to change the bad existing convention).
> >
> > Thoughts?
>
> The existing convention has to change somewhat because of the clobbers,
> so I thought we could change the error return at the same time. I'm
> open to not changing it and using CR0[SO], but others liked the idea.
> Pro: it matches sc and vsyscall. Con: it's different from other common
> archs. Performnce-wise it would really be a wash -- cost of conditional
> branch is not the cmp but the mispredict.
If you do the branch on hwcap at each syscall, then you significantly
increase code size of every syscall point, likely turning a bunch of
trivial functions that didn't need stack frames into ones that do. You
also potentially make them need a TOC pointer. Making them all just do
an indirect call unconditionally (with pointer in TLS like i386?) is a
lot more efficient in code size and at least as good for performance.
Rich
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Nicholas Piggin @ 2020-04-16 0:16 UTC (permalink / raw)
To: Rich Felker; +Cc: libc-dev, libc-alpha, linuxppc-dev, musl
In-Reply-To: <20200415225539.GL11469@brightrain.aerifal.cx>
Excerpts from Rich Felker's message of April 16, 2020 8:55 am:
> On Thu, Apr 16, 2020 at 07:45:09AM +1000, Nicholas Piggin wrote:
>> I would like to enable Linux support for the powerpc 'scv' instruction,
>> as a faster system call instruction.
>>
>> This requires two things to be defined: Firstly a way to advertise to
>> userspace that kernel supports scv, and a way to allocate and advertise
>> support for individual scv vectors. Secondly, a calling convention ABI
>> for this new instruction.
>>
>> Thanks to those who commented last time, since then I have removed my
>> answered questions and unpopular alternatives but you can find them
>> here
>>
>> https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-January/203545.html
>>
>> Let me try one more with a wider cc list, and then we'll get something
>> merged. Any questions or counter-opinions are welcome.
>>
>> System Call Vectored (scv) ABI
>> ==============================
>>
>> The scv instruction is introduced with POWER9 / ISA3, it comes with an
>> rfscv counter-part. The benefit of these instructions is performance
>> (trading slower SRR0/1 with faster LR/CTR registers, and entering the
>> kernel with MSR[EE] and MSR[RI] left enabled, which can reduce MSR
>> updates. The scv instruction has 128 interrupt entry points (not enough
>> to cover the Linux system call space).
>>
>> The proposal is to assign scv numbers very conservatively and allocate
>> them as individual HWCAP features as we add support for more. The zero
>> vector ('scv 0') will be used for normal system calls, equivalent to 'sc'.
>>
>> Advertisement
>>
>> Linux has not enabled FSCR[SCV] yet, so the instruction will cause a
>> SIGILL in current environments. Linux has defined a HWCAP2 bit
>> PPC_FEATURE2_SCV for SCV support, but does not set it.
>>
>> When scv instruction support and the scv 0 vector for system calls are
>> added, PPC_FEATURE2_SCV will indicate support for these. Other vectors
>> should not be used without future HWCAP bits indicating support, which is
>> how we will allocate them. (Should unallocated ones generate SIGILL, or
>> return -ENOSYS in r3?)
>>
>> Calling convention
>>
>> The proposal is for scv 0 to provide the standard Linux system call ABI
>> with the following differences from sc convention[1]:
>>
>> - LR is to be volatile across scv calls. This is necessary because the
>> scv instruction clobbers LR. From previous discussion, this should be
>> possible to deal with in GCC clobbers and CFI.
>>
>> - CR1 and CR5-CR7 are volatile. This matches the C ABI and would allow the
>> kernel system call exit to avoid restoring the CR register (although
>> we probably still would anyway to avoid information leak).
>>
>> - Error handling: I think the consensus has been to move to using negative
>> return value in r3 rather than CR0[SO]=1 to indicate error, which matches
>> most other architectures and is closer to a function call.
>>
>> The number of scratch registers (r9-r12) at kernel entry seems
>> sufficient that we don't have any costly spilling, patch is here[2].
>>
>> [1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/syscall64-abi.rst
>> [2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204840.html
>
> My preference would be that it work just like the i386 AT_SYSINFO
> where you just replace "int $128" with "call *%%gs:16" and the kernel
> provides a stub in the vdso that performs either scv or the old
> mechanism with the same calling convention. Then if the kernel doesn't
> provide it (because the kernel is too old) libc would have to provide
> its own stub that uses the legacy method and matches the calling
> convention of the one the kernel is expected to provide.
I'm not sure if that's necessary. That's done on x86-32 because they
select different sequences to use based on the CPU running and if the host
kernel is 32 or 64 bit. Sure they could in theory have a bunch of HWCAP
bits and select the right sequence in libc as well I suppose.
> Note that any libc that actually makes use of the new functionality is
> not going to be able to make clobbers conditional on support for it;
> branching around different clobbers is going to defeat any gains vs
> always just treating anything clobbered by either method as clobbered.
Well it would have to test HWCAP and patch in or branch to two
completely different sequences including register save/restores yes.
You could have the same asm and matching clobbers to put the sequence
inline and then you could patch the one sc/scv instruction I suppose.
A bit of logic to select between them doesn't defeat gains though,
it's about 90 cycle improvement which is a handful of branch mispredicts
so it really is an improvement. Eventually userspace will stop
supporting the old variant too.
> Likewise, it's not useful to have different error return mechanisms
> because the caller just has to branch to support both (or the
> kernel-provided stub just has to emulate one for it; that could work
> if you really want to change the bad existing convention).
>
> Thoughts?
The existing convention has to change somewhat because of the clobbers,
so I thought we could change the error return at the same time. I'm
open to not changing it and using CR0[SO], but others liked the idea.
Pro: it matches sc and vsyscall. Con: it's different from other common
archs. Performnce-wise it would really be a wash -- cost of conditional
branch is not the cmp but the mispredict.
Thanks,
Nick
^ permalink raw reply
* Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
From: Rich Felker @ 2020-04-15 22:55 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: libc-alpha, musl, linuxppc-dev, libc-dev
In-Reply-To: <1586931450.ub4c8cq8dj.astroid@bobo.none>
On Thu, Apr 16, 2020 at 07:45:09AM +1000, Nicholas Piggin wrote:
> I would like to enable Linux support for the powerpc 'scv' instruction,
> as a faster system call instruction.
>
> This requires two things to be defined: Firstly a way to advertise to
> userspace that kernel supports scv, and a way to allocate and advertise
> support for individual scv vectors. Secondly, a calling convention ABI
> for this new instruction.
>
> Thanks to those who commented last time, since then I have removed my
> answered questions and unpopular alternatives but you can find them
> here
>
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-January/203545.html
>
> Let me try one more with a wider cc list, and then we'll get something
> merged. Any questions or counter-opinions are welcome.
>
> System Call Vectored (scv) ABI
> ==============================
>
> The scv instruction is introduced with POWER9 / ISA3, it comes with an
> rfscv counter-part. The benefit of these instructions is performance
> (trading slower SRR0/1 with faster LR/CTR registers, and entering the
> kernel with MSR[EE] and MSR[RI] left enabled, which can reduce MSR
> updates. The scv instruction has 128 interrupt entry points (not enough
> to cover the Linux system call space).
>
> The proposal is to assign scv numbers very conservatively and allocate
> them as individual HWCAP features as we add support for more. The zero
> vector ('scv 0') will be used for normal system calls, equivalent to 'sc'.
>
> Advertisement
>
> Linux has not enabled FSCR[SCV] yet, so the instruction will cause a
> SIGILL in current environments. Linux has defined a HWCAP2 bit
> PPC_FEATURE2_SCV for SCV support, but does not set it.
>
> When scv instruction support and the scv 0 vector for system calls are
> added, PPC_FEATURE2_SCV will indicate support for these. Other vectors
> should not be used without future HWCAP bits indicating support, which is
> how we will allocate them. (Should unallocated ones generate SIGILL, or
> return -ENOSYS in r3?)
>
> Calling convention
>
> The proposal is for scv 0 to provide the standard Linux system call ABI
> with the following differences from sc convention[1]:
>
> - LR is to be volatile across scv calls. This is necessary because the
> scv instruction clobbers LR. From previous discussion, this should be
> possible to deal with in GCC clobbers and CFI.
>
> - CR1 and CR5-CR7 are volatile. This matches the C ABI and would allow the
> kernel system call exit to avoid restoring the CR register (although
> we probably still would anyway to avoid information leak).
>
> - Error handling: I think the consensus has been to move to using negative
> return value in r3 rather than CR0[SO]=1 to indicate error, which matches
> most other architectures and is closer to a function call.
>
> The number of scratch registers (r9-r12) at kernel entry seems
> sufficient that we don't have any costly spilling, patch is here[2].
>
> [1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/syscall64-abi.rst
> [2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204840.html
My preference would be that it work just like the i386 AT_SYSINFO
where you just replace "int $128" with "call *%%gs:16" and the kernel
provides a stub in the vdso that performs either scv or the old
mechanism with the same calling convention. Then if the kernel doesn't
provide it (because the kernel is too old) libc would have to provide
its own stub that uses the legacy method and matches the calling
convention of the one the kernel is expected to provide.
Note that any libc that actually makes use of the new functionality is
not going to be able to make clobbers conditional on support for it;
branching around different clobbers is going to defeat any gains vs
always just treating anything clobbered by either method as clobbered.
Likewise, it's not useful to have different error return mechanisms
because the caller just has to branch to support both (or the
kernel-provided stub just has to emulate one for it; that could work
if you really want to change the bad existing convention).
Thoughts?
Rich
^ permalink raw reply
* Re: [PATCH v2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'
From: Segher Boessenkool @ 2020-04-15 22:37 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, npiggin, Paul Mackerras, linuxppc-dev
In-Reply-To: <c9abd91e9bb0b3dd6e3470015e92b98bc2483780.1586942304.git.christophe.leroy@c-s.fr>
Hi!
On Wed, Apr 15, 2020 at 09:25:59AM +0000, Christophe Leroy wrote:
> +#define __put_user_goto(x, ptr, label) \
> + __put_user_nocheck_goto((__typeof__(*(ptr)))(x), (ptr), sizeof(*(ptr)), label)
This line gets too long, can you break it up somehow?
> +#define __put_user_asm_goto(x, addr, label, op) \
> + asm volatile goto( \
> + "1: " op "%U1%X1 %0,%1 # put_user\n" \
> + EX_TABLE(1b, %l2) \
> + : \
> + : "r" (x), "m" (*addr) \
> + : \
> + : label)
Same "%Un" problem as in the other patch. You could use "m<>" here,
but maybe just dropping "%Un" is better.
> +#ifdef __powerpc64__
> +#define __put_user_asm2_goto(x, ptr, label) \
> + __put_user_asm_goto(x, ptr, label, "std")
> +#else /* __powerpc64__ */
> +#define __put_user_asm2_goto(x, addr, label) \
> + asm volatile goto( \
> + "1: stw%U1%X1 %0, %1\n" \
> + "2: stw%U1%X1 %L0, %L1\n" \
> + EX_TABLE(1b, %l2) \
> + EX_TABLE(2b, %l2) \
> + : \
> + : "r" (x), "m" (*addr) \
> + : \
> + : label)
> +#endif /* __powerpc64__ */
Here, you should drop it for sure.
Rest looks fine.
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply
* Re: [PATCH] powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()
From: Segher Boessenkool @ 2020-04-15 22:06 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, npiggin, Paul Mackerras, linuxppc-dev
In-Reply-To: <4fdc2aba6f5e51887d1cd0fee94be0989eada2cd.1586942312.git.christophe.leroy@c-s.fr>
Hi!
On Wed, Apr 15, 2020 at 09:20:26AM +0000, Christophe Leroy wrote:
> At the time being, __put_user()/__get_user() and friends only use
> register indirect with immediate index addressing, with the index
> set to 0. Ex:
>
> lwz reg1, 0(reg2)
This is called a "D-form" instruction, or sometimes "offset addressing".
Don't talk about an "index", it confuses things, because the *other*
kind is called "indexed" already, also in the ISA docs! (X-form, aka
indexed addressing, [reg+reg], where D-form does [reg+imm], and both
forms can do [reg]).
> Give the compiler the opportunity to use other adressing modes
> whenever possible, to get more optimised code.
Great :-)
> --- a/arch/powerpc/include/asm/uaccess.h
> +++ b/arch/powerpc/include/asm/uaccess.h
> @@ -114,7 +114,7 @@ extern long __put_user_bad(void);
> */
> #define __put_user_asm(x, addr, err, op) \
> __asm__ __volatile__( \
> - "1: " op " %1,0(%2) # put_user\n" \
> + "1: " op "%U2%X2 %1,%2 # put_user\n" \
> "2:\n" \
> ".section .fixup,\"ax\"\n" \
> "3: li %0,%3\n" \
> @@ -122,7 +122,7 @@ extern long __put_user_bad(void);
> ".previous\n" \
> EX_TABLE(1b, 3b) \
> : "=r" (err) \
> - : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err))
> + : "r" (x), "m" (*addr), "i" (-EFAULT), "0" (err))
%Un on an "m" operand doesn't do much: you need to make it "m<>" if you
want pre-modify ("update") insns to be generated. (You then will want
to make sure that operand is used in a way GCC can understand; since it
is used only once here, that works fine).
> @@ -130,8 +130,8 @@ extern long __put_user_bad(void);
> #else /* __powerpc64__ */
> #define __put_user_asm2(x, addr, err) \
> __asm__ __volatile__( \
> - "1: stw %1,0(%2)\n" \
> - "2: stw %1+1,4(%2)\n" \
> + "1: stw%U2%X2 %1,%2\n" \
> + "2: stw%U2%X2 %L1,%L2\n" \
> "3:\n" \
> ".section .fixup,\"ax\"\n" \
> "4: li %0,%3\n" \
> @@ -140,7 +140,7 @@ extern long __put_user_bad(void);
> EX_TABLE(1b, 4b) \
> EX_TABLE(2b, 4b) \
> : "=r" (err) \
> - : "r" (x), "b" (addr), "i" (-EFAULT), "0" (err))
> + : "r" (x), "m" (*addr), "i" (-EFAULT), "0" (err))
Here, it doesn't work. You don't want two consecutive update insns in
any case. Easiest is to just not use "m<>", and then, don't use %Un
(which won't do anything, but it is confusing).
Same for the reads.
Rest looks fine, and update should be good with that fixed as said.
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Segher
^ permalink raw reply
* Powerpc Linux 'scv' system call ABI proposal take 2
From: Nicholas Piggin @ 2020-04-15 21:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: libc-dev, libc-alpha, musl
I would like to enable Linux support for the powerpc 'scv' instruction,
as a faster system call instruction.
This requires two things to be defined: Firstly a way to advertise to
userspace that kernel supports scv, and a way to allocate and advertise
support for individual scv vectors. Secondly, a calling convention ABI
for this new instruction.
Thanks to those who commented last time, since then I have removed my
answered questions and unpopular alternatives but you can find them
here
https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-January/203545.html
Let me try one more with a wider cc list, and then we'll get something
merged. Any questions or counter-opinions are welcome.
System Call Vectored (scv) ABI
==============================
The scv instruction is introduced with POWER9 / ISA3, it comes with an
rfscv counter-part. The benefit of these instructions is performance
(trading slower SRR0/1 with faster LR/CTR registers, and entering the
kernel with MSR[EE] and MSR[RI] left enabled, which can reduce MSR
updates. The scv instruction has 128 interrupt entry points (not enough
to cover the Linux system call space).
The proposal is to assign scv numbers very conservatively and allocate
them as individual HWCAP features as we add support for more. The zero
vector ('scv 0') will be used for normal system calls, equivalent to 'sc'.
Advertisement
Linux has not enabled FSCR[SCV] yet, so the instruction will cause a
SIGILL in current environments. Linux has defined a HWCAP2 bit
PPC_FEATURE2_SCV for SCV support, but does not set it.
When scv instruction support and the scv 0 vector for system calls are
added, PPC_FEATURE2_SCV will indicate support for these. Other vectors
should not be used without future HWCAP bits indicating support, which is
how we will allocate them. (Should unallocated ones generate SIGILL, or
return -ENOSYS in r3?)
Calling convention
The proposal is for scv 0 to provide the standard Linux system call ABI
with the following differences from sc convention[1]:
- LR is to be volatile across scv calls. This is necessary because the
scv instruction clobbers LR. From previous discussion, this should be
possible to deal with in GCC clobbers and CFI.
- CR1 and CR5-CR7 are volatile. This matches the C ABI and would allow the
kernel system call exit to avoid restoring the CR register (although
we probably still would anyway to avoid information leak).
- Error handling: I think the consensus has been to move to using negative
return value in r3 rather than CR0[SO]=1 to indicate error, which matches
most other architectures and is closer to a function call.
The number of scratch registers (r9-r12) at kernel entry seems
sufficient that we don't have any costly spilling, patch is here[2].
[1] https://github.com/torvalds/linux/blob/master/Documentation/powerpc/syscall64-abi.rst
[2] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-February/204840.html
^ permalink raw reply
* Re: [PATCH v5 0/6] implement KASLR for powerpc/fsl_booke/64
From: Scott Wood @ 2020-04-15 19:31 UTC (permalink / raw)
To: Jason Yan, mpe, linuxppc-dev, diana.craciun, christophe.leroy,
benh, paulus, npiggin, keescook, kernel-hardening
Cc: dja, linux-kernel, zhaohongjiang
In-Reply-To: <20200330022023.3691-1-yanaijie@huawei.com>
On Mon, 2020-03-30 at 10:20 +0800, Jason Yan wrote:
> This is a try to implement KASLR for Freescale BookE64 which is based on
> my earlier implementation for Freescale BookE32:
>
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=131718&state=*
>
> The implementation for Freescale BookE64 is similar as BookE32. One
> difference is that Freescale BookE64 set up a TLB mapping of 1G during
> booting. Another difference is that ppc64 needs the kernel to be
> 64K-aligned. So we can randomize the kernel in this 1G mapping and make
> it 64K-aligned. This can save some code to creat another TLB map at
> early boot. The disadvantage is that we only have about 1G/64K = 16384
> slots to put the kernel in.
>
> KERNELBASE
>
> 64K |--> kernel <--|
> | | |
> +--+--+--+ +--+--+--+--+--+--+--+--+--+ +--+--+
> | | | |....| | | | | | | | | |....| | |
> +--+--+--+ +--+--+--+--+--+--+--+--+--+ +--+--+
> | | 1G
> |-----> offset <-----|
>
> kernstart_virt_addr
>
> I'm not sure if the slot numbers is enough or the design has any
> defects. If you have some better ideas, I would be happy to hear that.
>
> Thank you all.
>
> v4->v5:
> Fix "-Werror=maybe-uninitialized" compile error.
> Fix typo "similar as" -> "similar to".
> v3->v4:
> Do not define __kaslr_offset as a fixed symbol. Reference __run_at_load
> and
> __kaslr_offset by symbol instead of magic offsets.
> Use IS_ENABLED(CONFIG_PPC32) instead of #ifdef CONFIG_PPC32.
> Change kaslr-booke32 to kaslr-booke in index.rst
> Switch some instructions to 64-bit.
> v2->v3:
> Fix build error when KASLR is disabled.
> v1->v2:
> Add __kaslr_offset for the secondary cpu boot up.
>
> Jason Yan (6):
> powerpc/fsl_booke/kaslr: refactor kaslr_legal_offset() and
> kaslr_early_init()
> powerpc/fsl_booke/64: introduce reloc_kernel_entry() helper
> powerpc/fsl_booke/64: implement KASLR for fsl_booke64
> powerpc/fsl_booke/64: do not clear the BSS for the second pass
> powerpc/fsl_booke/64: clear the original kernel if randomized
> powerpc/fsl_booke/kaslr: rename kaslr-booke32.rst to kaslr-booke.rst
> and add 64bit part
>
> Documentation/powerpc/index.rst | 2 +-
> .../{kaslr-booke32.rst => kaslr-booke.rst} | 35 ++++++-
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/kernel/exceptions-64e.S | 23 +++++
> arch/powerpc/kernel/head_64.S | 13 +++
> arch/powerpc/kernel/setup_64.c | 3 +
> arch/powerpc/mm/mmu_decl.h | 23 +++--
> arch/powerpc/mm/nohash/kaslr_booke.c | 91 +++++++++++++------
> 8 files changed, 147 insertions(+), 45 deletions(-)
> rename Documentation/powerpc/{kaslr-booke32.rst => kaslr-booke.rst} (59%)
>
Acked-by: Scott Wood <oss@buserror.net>
-Scott
^ permalink raw reply
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram
From: Scott Wood @ 2020-04-15 19:27 UTC (permalink / raw)
To: Christophe Leroy, Wang Wenhu, gregkh, linux-kernel, linuxppc-dev; +Cc: kernel
In-Reply-To: <37b6b890-e537-7424-6b26-04565681f40a@c-s.fr>
On Wed, 2020-04-15 at 18:52 +0200, Christophe Leroy wrote:
>
> Le 15/04/2020 à 17:24, Wang Wenhu a écrit :
> > +
> > + if (uiomem >= &info->mem[MAX_UIO_MAPS]) {
>
> I'd prefer
> if (uiomem - info->mem >= MAX_UIO_MAPS) {
>
> > + dev_warn(&pdev->dev, "more than %d uio-maps for
> > device.\n",
> > + MAX_UIO_MAPS);
> > + break;
> > + }
> > + }
> > +
> > + while (uiomem < &info->mem[MAX_UIO_MAPS]) {
>
> I'd prefer
>
> while (uiomem - info->mem < MAX_UIO_MAPS) {
>
I wouldn't. You're turning a simple comparison into a division and a
comparison (if the compiler doesn't optimize it back into the original form),
and making it less clear in the process.
Of course, working with array indices to begin with instead of incrementing a
pointer would be more idiomatic.
> > + uiomem->size = 0;
> > + ++uiomem;
> > + }
> > +
> > + if (info->mem[0].size == 0) {
>
> Is there any point in doing all the clearing loop above if it's to bail
> out here ?
>
> Wouldn't it be cleaner to do the test above the clearing loop, by just
> checking whether uiomem is still equal to info->mem ?
There's no point doing the clearing at all, since the array was allocated with
kzalloc().
> > + dev_err(&pdev->dev, "error no valid uio-map configured\n");
> > + ret = -EINVAL;
> > + goto err_info_free_internel;
> > + }
> > +
> > + info->version = "0.1.0";
>
> Could you define some DRIVER_VERSION in the top of the file next to
> DRIVER_NAME instead of hard coding in the middle on a function ?
That's what v1 had, and Greg KH said to remove it. I'm guessing that he
thought it was the common-but-pointless practice of having the driver print a
version number that never gets updated, rather than something the UIO API
(unfortunately, compared to a feature query interface) expects. That said,
I'm not sure what the value is of making it a macro since it should only be
used once, that use is self documenting, it isn't tunable, etc. Though if
this isn't a macro, UIO_NAME also shouldn't be (and if it is made a macro
again, it should be UIO_VERSION, not DRIVER_VERSION).
Does this really need a three-part version scheme? What's wrong with a
version of "1", to be changed to "2" in the hopefully-unlikely event that the
userspace API changes? Assuming UIO is used for this at all, which doesn't
seem like a great fit to me.
-Scott
^ permalink raw reply
* Re: [PATCH v2,5/5] drivers: uio: new driver for fsl_85xx_cache_sram
From: Scott Wood @ 2020-04-15 19:26 UTC (permalink / raw)
To: Wang Wenhu, gregkh, linux-kernel, christophe.leroy, linuxppc-dev; +Cc: kernel
In-Reply-To: <20200415152442.122873-6-wenhu.wang@vivo.com>
On Wed, 2020-04-15 at 08:24 -0700, Wang Wenhu wrote:
> +static const struct of_device_id uio_mpc85xx_l2ctlr_of_match[] = {
> + { .compatible = "uio,fsl,p2020-l2-cache-controller", },
> + { .compatible = "uio,fsl,p2010-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1020-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1011-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1013-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1022-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8548-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8544-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8572-l2-cache-controller", },
> + { .compatible = "uio,fsl,mpc8536-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1021-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1012-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1025-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1016-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1024-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1015-l2-cache-controller", },
> + { .compatible = "uio,fsl,p1010-l2-cache-controller", },
> + { .compatible = "uio,fsl,bsc9131-l2-cache-controller", },
> + {},
> +};
NACK
The device tree describes the hardware, not what driver you want to bind the
hardware to, or how you want to allocate the resources. And even if defining
nodes for sram allocation were the right way to go, why do you have a separate
compatible for each chip when you're just describing software configuration?
Instead, have module parameters that take the sizes and alignments you'd like
to allocate and expose to userspace. Better still would be some sort of
dynamic allocation (e.g. open a fd, ioctl to set the requested size/alignment,
if it succeeds you can mmap it, and when the fd is closed the region is
freed).
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox