Re: PROBLEM: Power9: kernel oops on memory hotunplug from ppc64le guest
On Mon, May 20, 2019 at 02:48:35PM +1000, Nicholas Piggin wrote:
> >> > git bisect points to
> >> >
> >> > commit 4231aba000f5a4583dd9f67057aadb68c3eca99d
> >> > Author: Nicholas Piggin
> >> > Date: Fri Jul 27 21:48:17 2018 +1000
> >> >
> >> > powerpc/64s: Fix page table fragment refcount race vs speculative
> >> > references
> >> >
> >> > The page table fragment allocator uses the main page refcount racily
> >> > with respect to speculative references. A customer observed a BUG due
> >> > to page table page refcount underflow in the fragment allocator. This
> >> > can be caused by the fragment allocator set_page_count stomping on a
> >> > speculative reference, and then the speculative failure handler
> >> > decrements the new reference, and the underflow eventually pops when
> >> > the page tables are freed.
> >> >
> >> > Fix this by using a dedicated field in the struct page for the page
> >> > table fragment allocator.
> >> >
> >> > Fixes: 5c1f6ee9a31c ("powerpc: Reduce PTE table memory wastage")
> >> > Cc: sta...@vger.kernel.org # v3.10+
> >>
> >> That's the commit that added the BUG_ON(), so prior to that you won't
> >> see the crash.
> >
> > Right, but the commit says it fixes page table page refcount underflow by
> > introducing a new field >pt_frag_refcount. Now we are hitting the
> > underflow
> > for this pt_frag_refcount.
>
> The fixed underflow is caused by a bug (race on page count) that got
> fixed by that patch. You are hitting a different underflow here. It's
> not certain my patch caused it, I'm just trying to reproduce now.
Ok.
>
> >
> > BTW, if I go below this commit, I don't hit the pagecount
> >
> > VM_BUG_ON_PAGE(page_ref_count(page) == 0, page);
> >
> > which is in pte_fragment_free() path.
>
> Do you have CONFIG_DEBUG_VM=y?
Yes.
Regards,
Bharata.
Re: PROBLEM: Power9: kernel oops on memory hotunplug from ppc64le guest
Bharata B Rao's on May 20, 2019 2:25 pm: > On Mon, May 20, 2019 at 12:02:23PM +1000, Michael Ellerman wrote: >> Bharata B Rao writes: >> > On Thu, May 16, 2019 at 07:44:20PM +0530, srikanth wrote: >> >> Hello, >> >> >> >> On power9 host, performing memory hotunplug from ppc64le guest results in >> >> kernel oops. >> >> >> >> Kernel used : https://github.com/torvalds/linux/tree/v5.1 built using >> >> ppc64le_defconfig for host and ppc64le_guest_defconfig for guest. >> >> >> >> Recreation steps: >> >> >> >> 1. Boot a guest with below mem configuration: >> >> 33554432 >> >> 8388608 >> >> 4194304 >> >> >> >> >> >> >> >> >> >> >> >> >> >> 2. From host hotplug 8G memory -> verify memory hotadded succesfully -> >> >> now >> >> reboot guest -> once guest comes back try to unplug 8G memory >> >> >> >> mem.xml used: >> >> >> >> >> >> 8 >> >> 0 >> >> >> >> >> >> >> >> Memory attach and detach commands used: >> >> virsh attach-device vm1 ./mem.xml --live >> >> virsh detach-device vm1 ./mem.xml --live >> >> >> >> Trace seen inside guest after unplug, guest just hangs there forever: >> >> >> >> [ 21.962986] kernel BUG at arch/powerpc/mm/pgtable-frag.c:113! >> >> [ 21.963064] Oops: Exception in kernel mode, sig: 5 [#1] >> >> [ 21.963090] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA >> >> pSeries >> >> [ 21.963131] Modules linked in: xt_tcpudp iptable_filter squashfs fuse >> >> vmx_crypto ib_iser rdma_cm iw_cm ib_cm ib_core libiscsi >> >> scsi_transport_iscsi >> >> ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress >> >> lzo_compress >> >> raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx >> >> xor raid6_pq multipath crc32c_vpmsum >> >> [ 21.963281] CPU: 11 PID: 316 Comm: kworker/u64:5 Kdump: loaded Not >> >> tainted 5.1.0-dirty #2 >> >> [ 21.963323] Workqueue: pseries hotplug workque pseries_hp_work_fn >> >> [ 21.963355] NIP: c0079e18 LR: c0c79308 CTR: >> >> 8000 >> >> [ 21.963392] REGS: c003f88034f0 TRAP: 0700 Not tainted >> >> (5.1.0-dirty) >> >> [ 21.963422] MSR: 8282b033 >> >> CR: >> >> 28002884 XER: 2004 >> >> [ 21.963470] CFAR: c0c79304 IRQMASK: 0 >> >> [ 21.963470] GPR00: c0c79308 c003f8803780 c1521000 >> >> 00fff8c0 >> >> [ 21.963470] GPR04: 0001 ffe30005 0005 >> >> 0020 >> >> [ 21.963470] GPR08: 0001 c00a00fff8e0 >> >> c16d21a0 >> >> [ 21.963470] GPR12: c16e7b90 c7ff2700 c00a00a0 >> >> c003ffe30100 >> >> [ 21.963470] GPR16: c003ffe3 c14aa4de c00a009f >> >> c16d21b0 >> >> [ 21.963470] GPR20: c14de588 0001 c16d21b8 >> >> c00a00a0 >> >> [ 21.963470] GPR24: c00a00a0 >> >> c003ffe96000 >> >> [ 21.963470] GPR28: c00a00a0 c00a00a0 c003fffec000 >> >> c00a00fff8c0 >> >> [ 21.963802] NIP [c0079e18] pte_fragment_free+0x48/0xd0 >> >> [ 21.963838] LR [c0c79308] remove_pagetable+0x49c/0x5b4 >> >> [ 21.963873] Call Trace: >> >> [ 21.963890] [c003f8803780] [c003ffe997f0] 0xc003ffe997f0 >> >> (unreliable) >> >> [ 21.963933] [c003f88037b0] [] (null) >> >> [ 21.963969] [c003f88038c0] [c006f038] >> >> vmemmap_free+0x218/0x2e0 >> >> [ 21.964006] [c003f8803940] [c036f100] >> >> sparse_remove_one_section+0xd0/0x138 >> >> [ 21.964050] [c003f8803980] [c0383a50] >> >> __remove_pages+0x410/0x560 >> >> [ 21.964093] [c003f8803a90] [c0c784d8] >> >> arch_remove_memory+0x68/0xdc >> >> [ 21.964136] [c003f8803ad0] [c0385d74] >> >> __remove_memory+0xc4/0x110 >> >> [ 21.964180] [c003f8803b10] [c00d44e4] >> >> dlpar_remove_lmb+0x94/0x140 >> >> [ 21.964223] [c003f8803b50] [c00d52b4] >> >> dlpar_memory+0x464/0xd00 >> >> [ 21.964259] [c003f8803be0] [c00cd5c0] >> >> handle_dlpar_errorlog+0xc0/0x190 >> >> [ 21.964303] [c003f8803c50] [c00cd6bc] >> >> pseries_hp_work_fn+0x2c/0x60 >> >> [ 21.964346] [c003f8803c80] [c013a4a0] >> >> process_one_work+0x2b0/0x5a0 >> >> [ 21.964388] [c003f8803d10] [c013a818] >> >> worker_thread+0x88/0x610 >> >> [ 21.964434] [c003f8803db0] [c0143884] kthread+0x1a4/0x1b0 >> >> [ 21.964468] [c003f8803e20] [c000bdc4] >> >> ret_from_kernel_thread+0x5c/0x78 >> >> [ 21.964506] Instruction dump: >> >> [ 21.964527] fbe1fff8 f821ffd1 78638502 78633664 ebe9 7fff1a14 >> >> 395f0020 813f0020 >> >> [ 21.964569] 7d2907b4 7d2900d0 79290fe0 69290001 <0b09> 7c0004ac >> >> 7d205028 3129 >> >> [ 21.964613] ---[ end trace aaa571aa1636fee6 ]--- >> >> [ 21.966349] >> >> [ 21.966383] Sending IPI to other CPUs >> >> [
Re: PROBLEM: Power9: kernel oops on memory hotunplug from ppc64le guest
On Mon, May 20, 2019 at 12:02:23PM +1000, Michael Ellerman wrote: > Bharata B Rao writes: > > On Thu, May 16, 2019 at 07:44:20PM +0530, srikanth wrote: > >> Hello, > >> > >> On power9 host, performing memory hotunplug from ppc64le guest results in > >> kernel oops. > >> > >> Kernel used : https://github.com/torvalds/linux/tree/v5.1 built using > >> ppc64le_defconfig for host and ppc64le_guest_defconfig for guest. > >> > >> Recreation steps: > >> > >> 1. Boot a guest with below mem configuration: > >> 33554432 > >> 8388608 > >> 4194304 > >> > >> > >> > >> > >> > >> > >> 2. From host hotplug 8G memory -> verify memory hotadded succesfully -> now > >> reboot guest -> once guest comes back try to unplug 8G memory > >> > >> mem.xml used: > >> > >> > >> 8 > >> 0 > >> > >> > >> > >> Memory attach and detach commands used: > >> virsh attach-device vm1 ./mem.xml --live > >> virsh detach-device vm1 ./mem.xml --live > >> > >> Trace seen inside guest after unplug, guest just hangs there forever: > >> > >> [ 21.962986] kernel BUG at arch/powerpc/mm/pgtable-frag.c:113! > >> [ 21.963064] Oops: Exception in kernel mode, sig: 5 [#1] > >> [ 21.963090] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA > >> pSeries > >> [ 21.963131] Modules linked in: xt_tcpudp iptable_filter squashfs fuse > >> vmx_crypto ib_iser rdma_cm iw_cm ib_cm ib_core libiscsi > >> scsi_transport_iscsi > >> ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress lzo_compress > >> raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx > >> xor raid6_pq multipath crc32c_vpmsum > >> [ 21.963281] CPU: 11 PID: 316 Comm: kworker/u64:5 Kdump: loaded Not > >> tainted 5.1.0-dirty #2 > >> [ 21.963323] Workqueue: pseries hotplug workque pseries_hp_work_fn > >> [ 21.963355] NIP: c0079e18 LR: c0c79308 CTR: > >> 8000 > >> [ 21.963392] REGS: c003f88034f0 TRAP: 0700 Not tainted > >> (5.1.0-dirty) > >> [ 21.963422] MSR: 8282b033 > >> CR: > >> 28002884 XER: 2004 > >> [ 21.963470] CFAR: c0c79304 IRQMASK: 0 > >> [ 21.963470] GPR00: c0c79308 c003f8803780 c1521000 > >> 00fff8c0 > >> [ 21.963470] GPR04: 0001 ffe30005 0005 > >> 0020 > >> [ 21.963470] GPR08: 0001 c00a00fff8e0 > >> c16d21a0 > >> [ 21.963470] GPR12: c16e7b90 c7ff2700 c00a00a0 > >> c003ffe30100 > >> [ 21.963470] GPR16: c003ffe3 c14aa4de c00a009f > >> c16d21b0 > >> [ 21.963470] GPR20: c14de588 0001 c16d21b8 > >> c00a00a0 > >> [ 21.963470] GPR24: c00a00a0 > >> c003ffe96000 > >> [ 21.963470] GPR28: c00a00a0 c00a00a0 c003fffec000 > >> c00a00fff8c0 > >> [ 21.963802] NIP [c0079e18] pte_fragment_free+0x48/0xd0 > >> [ 21.963838] LR [c0c79308] remove_pagetable+0x49c/0x5b4 > >> [ 21.963873] Call Trace: > >> [ 21.963890] [c003f8803780] [c003ffe997f0] 0xc003ffe997f0 > >> (unreliable) > >> [ 21.963933] [c003f88037b0] [] (null) > >> [ 21.963969] [c003f88038c0] [c006f038] > >> vmemmap_free+0x218/0x2e0 > >> [ 21.964006] [c003f8803940] [c036f100] > >> sparse_remove_one_section+0xd0/0x138 > >> [ 21.964050] [c003f8803980] [c0383a50] > >> __remove_pages+0x410/0x560 > >> [ 21.964093] [c003f8803a90] [c0c784d8] > >> arch_remove_memory+0x68/0xdc > >> [ 21.964136] [c003f8803ad0] [c0385d74] > >> __remove_memory+0xc4/0x110 > >> [ 21.964180] [c003f8803b10] [c00d44e4] > >> dlpar_remove_lmb+0x94/0x140 > >> [ 21.964223] [c003f8803b50] [c00d52b4] > >> dlpar_memory+0x464/0xd00 > >> [ 21.964259] [c003f8803be0] [c00cd5c0] > >> handle_dlpar_errorlog+0xc0/0x190 > >> [ 21.964303] [c003f8803c50] [c00cd6bc] > >> pseries_hp_work_fn+0x2c/0x60 > >> [ 21.964346] [c003f8803c80] [c013a4a0] > >> process_one_work+0x2b0/0x5a0 > >> [ 21.964388] [c003f8803d10] [c013a818] > >> worker_thread+0x88/0x610 > >> [ 21.964434] [c003f8803db0] [c0143884] kthread+0x1a4/0x1b0 > >> [ 21.964468] [c003f8803e20] [c000bdc4] > >> ret_from_kernel_thread+0x5c/0x78 > >> [ 21.964506] Instruction dump: > >> [ 21.964527] fbe1fff8 f821ffd1 78638502 78633664 ebe9 7fff1a14 > >> 395f0020 813f0020 > >> [ 21.964569] 7d2907b4 7d2900d0 79290fe0 69290001 <0b09> 7c0004ac > >> 7d205028 3129 > >> [ 21.964613] ---[ end trace aaa571aa1636fee6 ]--- > >> [ 21.966349] > >> [ 21.966383] Sending IPI to other CPUs > >> [ 21.978335] IPI complete > >> [ 21.981354] kexec: Starting switchover sequence. > >> I'm in purgatory > > > > git bisect points to > > > > commit
[PATCH] kbuild: do not check name uniqueness of builtin modules
I just thought it was a good idea to scan builtin.modules in the name
uniqueness checking, but Stephen reported a false positive.
ppc64_defconfig produces:
warning: same basename if the following are built as modules:
arch/powerpc/platforms/powermac/nvram.ko
drivers/char/nvram.ko
..., which is a false positive because the former is never built as
a module as you see in arch/powerpc/platforms/powermac/Makefile:
# CONFIG_NVRAM is an arch. independent tristate symbol, for pmac32 we really
# need this to be a bool. Cheat here and pretend CONFIG_NVRAM=m is really
# CONFIG_NVRAM=y
obj-$(CONFIG_NVRAM:m=y) += nvram.o
Since we cannot predict how tricky Makefiles are written in wild,
builtin.modules may potentially contain false positives. I do not
think it is a big deal as far as kmod is concerned, but false positive
warnings in the kernel build makes people upset. It is better to not
do it.
Even without checking builtin.modules, we have enough (and more solid)
test coverage with allmodconfig.
While I touched this part, I replaced the sed code with neater one
provided by Stephen.
Link: https://lkml.org/lkml/2019/5/19/120
Link: https://lkml.org/lkml/2019/5/19/123
Fixes: 3a48a91901c5 ("kbuild: check uniqueness of module names")
Reported-by: Stephen Rothwell
Signed-off-by: Masahiro Yamada
---
scripts/modules-check.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/scripts/modules-check.sh b/scripts/modules-check.sh
index 2f659530e1ec..39e8cb36ba19 100755
--- a/scripts/modules-check.sh
+++ b/scripts/modules-check.sh
@@ -6,10 +6,10 @@ set -e
# Check uniqueness of module names
check_same_name_modules()
{
- for m in $(sed 's:.*/::' modules.order modules.builtin | sort | uniq -d)
+ for m in $(sed 's:.*/::' modules.order | sort | uniq -d)
do
- echo "warning: same basename if the following are built as
modules:" >&2
- sed "/\/$m/!d;s:^kernel/: :" modules.order modules.builtin >&2
+ echo "warning: same module names found:" >&2
+ sed -n "/\/$m/s:^kernel/: :p" modules.order >&2
done
}
--
2.17.1
RE: [PATCH V2 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
Hi Pavel,
On Monday, May 20, 2019 05:35, Pavel Machek wrote:
>
> > --- a/include/linux/pm_wakeup.h
>
> > @@ -70,6 +71,7 @@ struct wakeup_source {
> > unsigned long wakeup_count;
> > boolactive:1;
> > boolautosleep_enabled:1;
> > + struct device *attached_dev;
> > };
> >
> > #ifdef CONFIG_PM_SLEEP
>
> You might want to format this similary to the rest...
OK, will update, thanks.
Regards,
Ran
Re: PROBLEM: Power9: kernel oops on memory hotunplug from ppc64le guest
Bharata B Rao writes: > On Thu, May 16, 2019 at 07:44:20PM +0530, srikanth wrote: >> Hello, >> >> On power9 host, performing memory hotunplug from ppc64le guest results in >> kernel oops. >> >> Kernel used : https://github.com/torvalds/linux/tree/v5.1 built using >> ppc64le_defconfig for host and ppc64le_guest_defconfig for guest. >> >> Recreation steps: >> >> 1. Boot a guest with below mem configuration: >> 33554432 >> 8388608 >> 4194304 >> >> >> >> >> >> >> 2. From host hotplug 8G memory -> verify memory hotadded succesfully -> now >> reboot guest -> once guest comes back try to unplug 8G memory >> >> mem.xml used: >> >> >> 8 >> 0 >> >> >> >> Memory attach and detach commands used: >> virsh attach-device vm1 ./mem.xml --live >> virsh detach-device vm1 ./mem.xml --live >> >> Trace seen inside guest after unplug, guest just hangs there forever: >> >> [ 21.962986] kernel BUG at arch/powerpc/mm/pgtable-frag.c:113! >> [ 21.963064] Oops: Exception in kernel mode, sig: 5 [#1] >> [ 21.963090] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA >> pSeries >> [ 21.963131] Modules linked in: xt_tcpudp iptable_filter squashfs fuse >> vmx_crypto ib_iser rdma_cm iw_cm ib_cm ib_core libiscsi scsi_transport_iscsi >> ip_tables x_tables autofs4 btrfs zstd_decompress zstd_compress lzo_compress >> raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx >> xor raid6_pq multipath crc32c_vpmsum >> [ 21.963281] CPU: 11 PID: 316 Comm: kworker/u64:5 Kdump: loaded Not >> tainted 5.1.0-dirty #2 >> [ 21.963323] Workqueue: pseries hotplug workque pseries_hp_work_fn >> [ 21.963355] NIP: c0079e18 LR: c0c79308 CTR: >> 8000 >> [ 21.963392] REGS: c003f88034f0 TRAP: 0700 Not tainted (5.1.0-dirty) >> [ 21.963422] MSR: 8282b033 CR: >> 28002884 XER: 2004 >> [ 21.963470] CFAR: c0c79304 IRQMASK: 0 >> [ 21.963470] GPR00: c0c79308 c003f8803780 c1521000 >> 00fff8c0 >> [ 21.963470] GPR04: 0001 ffe30005 0005 >> 0020 >> [ 21.963470] GPR08: 0001 c00a00fff8e0 >> c16d21a0 >> [ 21.963470] GPR12: c16e7b90 c7ff2700 c00a00a0 >> c003ffe30100 >> [ 21.963470] GPR16: c003ffe3 c14aa4de c00a009f >> c16d21b0 >> [ 21.963470] GPR20: c14de588 0001 c16d21b8 >> c00a00a0 >> [ 21.963470] GPR24: c00a00a0 >> c003ffe96000 >> [ 21.963470] GPR28: c00a00a0 c00a00a0 c003fffec000 >> c00a00fff8c0 >> [ 21.963802] NIP [c0079e18] pte_fragment_free+0x48/0xd0 >> [ 21.963838] LR [c0c79308] remove_pagetable+0x49c/0x5b4 >> [ 21.963873] Call Trace: >> [ 21.963890] [c003f8803780] [c003ffe997f0] 0xc003ffe997f0 >> (unreliable) >> [ 21.963933] [c003f88037b0] [] (null) >> [ 21.963969] [c003f88038c0] [c006f038] >> vmemmap_free+0x218/0x2e0 >> [ 21.964006] [c003f8803940] [c036f100] >> sparse_remove_one_section+0xd0/0x138 >> [ 21.964050] [c003f8803980] [c0383a50] >> __remove_pages+0x410/0x560 >> [ 21.964093] [c003f8803a90] [c0c784d8] >> arch_remove_memory+0x68/0xdc >> [ 21.964136] [c003f8803ad0] [c0385d74] >> __remove_memory+0xc4/0x110 >> [ 21.964180] [c003f8803b10] [c00d44e4] >> dlpar_remove_lmb+0x94/0x140 >> [ 21.964223] [c003f8803b50] [c00d52b4] >> dlpar_memory+0x464/0xd00 >> [ 21.964259] [c003f8803be0] [c00cd5c0] >> handle_dlpar_errorlog+0xc0/0x190 >> [ 21.964303] [c003f8803c50] [c00cd6bc] >> pseries_hp_work_fn+0x2c/0x60 >> [ 21.964346] [c003f8803c80] [c013a4a0] >> process_one_work+0x2b0/0x5a0 >> [ 21.964388] [c003f8803d10] [c013a818] >> worker_thread+0x88/0x610 >> [ 21.964434] [c003f8803db0] [c0143884] kthread+0x1a4/0x1b0 >> [ 21.964468] [c003f8803e20] [c000bdc4] >> ret_from_kernel_thread+0x5c/0x78 >> [ 21.964506] Instruction dump: >> [ 21.964527] fbe1fff8 f821ffd1 78638502 78633664 ebe9 7fff1a14 >> 395f0020 813f0020 >> [ 21.964569] 7d2907b4 7d2900d0 79290fe0 69290001 <0b09> 7c0004ac >> 7d205028 3129 >> [ 21.964613] ---[ end trace aaa571aa1636fee6 ]--- >> [ 21.966349] >> [ 21.966383] Sending IPI to other CPUs >> [ 21.978335] IPI complete >> [ 21.981354] kexec: Starting switchover sequence. >> I'm in purgatory > > git bisect points to > > commit 4231aba000f5a4583dd9f67057aadb68c3eca99d > Author: Nicholas Piggin > Date: Fri Jul 27 21:48:17 2018 +1000 > > powerpc/64s: Fix page table fragment refcount race vs speculative > references > > The page table fragment allocator uses the main page refcount racily > with respect to speculative references. A customer observed a BUG due
Re: [PATCH] crypto: vmx - CTR: always increment IV as quadword
Daniel Axtens writes:
> The kernel self-tests picked up an issue with CTR mode:
> alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test
> vector 3, cfg="uneven misaligned splits, may sleep"
>
> Test vector 3 has an IV of FFFD, so
> after 3 increments it should wrap around to 0.
>
> In the aesp8-ppc code from OpenSSL, there are two paths that
> increment IVs: the bulk (8 at a time) path, and the individual
> path which is used when there are fewer than 8 AES blocks to
> process.
>
> In the bulk path, the IV is incremented with vadduqm: "Vector
> Add Unsigned Quadword Modulo", which does 128-bit addition.
>
> In the individual path, however, the IV is incremented with
> vadduwm: "Vector Add Unsigned Word Modulo", which instead
> does 4 32-bit additions. Thus the IV would instead become
> , throwing off the result.
>
> Use vadduqm.
>
> This was probably a typo originally, what with q and w being
> adjacent. It is a pretty narrow edge case: I am really
> impressed by the quality of the kernel self-tests!
>
> Fixes: 5c380d623ed3 ("crypto: vmx - Add support for VMS instructions by ASM")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Daniel Axtens
>
> ---
>
> I'll pass this along internally to get it into OpenSSL as well.
I passed this along to OpenSSL and got pretty comprehensively schooled:
https://github.com/openssl/openssl/pull/8942
It seems we tweak the openssl code to use a 128-bit counter, whereas
the original code was in fact designed for a 32-bit counter. We must
have changed the vaddu instruction in the bulk path but not in the
individual path, as they're both vadduwm (4x32-bit) upstream.
I think this change is still correct with regards to the kernel,
but I guess it's probably something where I should have done a more
thorough read of the documentation before diving in to the code, and
perhaps we should note it in the code somewhere too. Ah well.
Regards,
Daniel
> ---
> drivers/crypto/vmx/aesp8-ppc.pl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/vmx/aesp8-ppc.pl b/drivers/crypto/vmx/aesp8-ppc.pl
> index de78282b8f44..9c6b5c1d6a1a 100644
> --- a/drivers/crypto/vmx/aesp8-ppc.pl
> +++ b/drivers/crypto/vmx/aesp8-ppc.pl
> @@ -1357,7 +1357,7 @@ Loop_ctr32_enc:
> addi$idx,$idx,16
> bdnzLoop_ctr32_enc
>
> - vadduwm $ivec,$ivec,$one
> + vadduqm $ivec,$ivec,$one
>vmr$dat,$inptail
>lvx$inptail,0,$inp
>addi $inp,$inp,16
> --
> 2.19.1
[Bug 203597] kernel 4.9.175 fails to boot on a PowerMac G4 3,6 at early stage
https://bugzilla.kernel.org/show_bug.cgi?id=203597 Michael Ellerman (mich...@ellerman.id.au) changed: What|Removed |Added Status|RESOLVED|CLOSED CC||mich...@ellerman.id.au -- You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] ocxl: Fix potential memory leak on context creation
On 18/5/19 12:20 am, Frederic Barrat wrote:
If we couldn't fully init a context, we were leaking memory.
Fixes: b9721d275cc2 ("ocxl: Allow external drivers to use OpenCAPI contexts")
Signed-off-by: Frederic Barrat
Acked-by: Andrew Donnellan
---
drivers/misc/ocxl/context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/ocxl/context.c b/drivers/misc/ocxl/context.c
index bab9c9364184..ab93156aa83e 100644
--- a/drivers/misc/ocxl/context.c
+++ b/drivers/misc/ocxl/context.c
@@ -22,6 +22,7 @@ int ocxl_context_alloc(struct ocxl_context **context, struct
ocxl_afu *afu,
afu->pasid_base + afu->pasid_max, GFP_KERNEL);
if (pasid < 0) {
mutex_unlock(>contexts_lock);
+ kfree(*context);
(defensive programming: set *context = NULL so that if the caller
ignores the return code we get an obvious crash)
return pasid;
}
afu->pasid_count++;
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
Re: [PATCH V2 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
> --- a/include/linux/pm_wakeup.h
> @@ -70,6 +71,7 @@ struct wakeup_source {
> unsigned long wakeup_count;
> boolactive:1;
> boolautosleep_enabled:1;
> + struct device *attached_dev;
> };
>
> #ifdef CONFIG_PM_SLEEP
You might want to format this similary to the rest...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH V2 3/3] soc: fsl: add RCPM driver
Hi!
> +
> +struct rcpm {
> + unsigned int wakeup_cells;
> + void __iomem *ippdexpcr_base;
> + boollittle_endian;
> +};
Inconsistent whitespace
> +static int rcpm_pm_prepare(struct device *dev)
> +{
> + struct device_node *np = dev->of_node;
> + struct wakeup_source *ws;
> + struct rcpm *rcpm;
> + u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1], tmp;
> + int i, ret;
> +
> + rcpm = dev_get_drvdata(dev);
> + if (!rcpm)
> + return -EINVAL;
> +
> + /* Begin with first registered wakeup source */
> + ws = wakeup_source_get_next(NULL);
> + while (ws) {
while (ws = wakeup_source_get_next(NULL)) ?
> +static int rcpm_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct resource *r;
> + struct rcpm *rcpm;
> + int ret;
Whitespace.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
[Bug 203597] kernel 4.9.175 fails to boot on a PowerMac G4 3,6 at early stage
https://bugzilla.kernel.org/show_bug.cgi?id=203597 Erhard F. (erhar...@mailbox.org) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #3 from Erhard F. (erhar...@mailbox.org) --- (In reply to Christophe Leroy from comment #2) > You are missing following commit: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/ > ?id=b45ba4a51cd Your fix landed in 4.9.177 and I can confirm my G4 boots fine now. Thanks! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 203647] Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x
https://bugzilla.kernel.org/show_bug.cgi?id=203647 --- Comment #5 from Erhard F. (erhar...@mailbox.org) --- Created attachment 282841 --> https://bugzilla.kernel.org/attachment.cgi?id=282841=edit kernel .config (5.1.3, G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 203647] Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x
https://bugzilla.kernel.org/show_bug.cgi?id=203647 --- Comment #4 from Erhard F. (erhar...@mailbox.org) --- Created attachment 282839 --> https://bugzilla.kernel.org/attachment.cgi?id=282839=edit dmesg (4.9.177, G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 203647] Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x
https://bugzilla.kernel.org/show_bug.cgi?id=203647 --- Comment #3 from Erhard F. (erhar...@mailbox.org) --- Created attachment 282837 --> https://bugzilla.kernel.org/attachment.cgi?id=282837=edit dmesg (4.14.120, G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 203647] Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x
https://bugzilla.kernel.org/show_bug.cgi?id=203647 --- Comment #2 from Erhard F. (erhar...@mailbox.org) --- Created attachment 282835 --> https://bugzilla.kernel.org/attachment.cgi?id=282835=edit dmesg (4.19.44, G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 203647] Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x
https://bugzilla.kernel.org/show_bug.cgi?id=203647 --- Comment #1 from Erhard F. (erhar...@mailbox.org) --- Created attachment 282833 --> https://bugzilla.kernel.org/attachment.cgi?id=282833=edit dmesg (5.0.17, G5 11,2) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 203647] New: Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x
https://bugzilla.kernel.org/show_bug.cgi?id=203647 Bug ID: 203647 Summary: Locking API testsuite fails "mixed read-lock/lock-write ABBA" rlock on kernels >=4.14.x Product: Platform Specific/Hardware Version: 2.5 Kernel Version: 5.1.3 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: PPC-64 Assignee: platform_ppc...@kernel-bugs.osdl.org Reporter: erhar...@mailbox.org Regression: No Created attachment 282831 --> https://bugzilla.kernel.org/attachment.cgi?id=282831=edit dmesg (5.1.3, G5 11,2) Probably this test fails on ppc64 since it is around. Kernel 4.9.x passes all tests, since it does not seem to contain "mixed read-lock/lock-write ABBA". Machine is a PowerMac G5 11,2 running Gentoo Linux ppc64, Big Endian, 4 KiB pagesize. [0.002051] [0.002065] | Locking API testsuite: [0.002079] [0.002111] | spin |wlock |rlock |mutex | wsem | rsem | [0.002142] -- [0.002179] A-A deadlock: ok | ok | ok | ok | ok | ok | ok | [0.007366] A-B-B-A deadlock: ok | ok | ok | ok | ok | ok | ok | [0.012471] A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok | ok | [0.017598] A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok | ok | [0.022740] A-B-B-C-C-D-D-A deadlock: ok | ok | ok | ok | ok | ok | ok | [0.027912] A-B-C-D-B-D-D-A deadlock: ok | ok | ok | ok | ok | ok | ok | [0.033083] A-B-C-D-B-C-D-A deadlock: ok | ok | ok | ok | ok | ok | ok | [0.038269] double unlock: ok | ok | ok | ok | ok | ok | ok | [0.043319] initialize held: ok | ok | ok | ok | ok | ok | ok | [0.048379] -- [0.048411] recursive read-lock: | ok | | ok | [0.049894]recursive read-lock #2: | ok | | ok | [0.051375] mixed read-write-lock: | ok | | ok | [0.052859] mixed write-read-lock: | ok | | ok | [0.054333] mixed read-lock/lock-write ABBA: |FAILED| | ok | [0.055802]mixed read-lock/lock-read ABBA: | ok | | ok | [0.057290] mixed write-lock/lock-write ABBA: | ok | | ok | [0.058771] -- -- You are receiving this mail because: You are watching the assignee of the bug.
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.2-2 tag
The pull request you sent on Sat, 18 May 2019 21:12:54 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.2-2 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/86a78a8b8d0414455c2174852968ce54205add82 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [PATCH] mm/nvdimm: Pick the right alignment default when creating dax devices
On Sun, May 19, 2019 at 1:55 AM Aneesh Kumar K.V
wrote:
>
>
> Hi Dan,
>
> "Aneesh Kumar K.V" writes:
>
> > On 5/17/19 8:19 PM, Vaibhav Jain wrote:
> >> Hi Aneesh,
> >>
>
>
>
> >>
> >>> + /*
> >>> +* Check whether the we support the alignment. For Dax if the
> >>> +* superblock alignment is not matching, we won't initialize
> >>> +* the device.
> >>> +*/
> >>> + if (!nd_supported_alignment(align) &&
> >>> + memcmp(pfn_sb->signature, DAX_SIG, PFN_SIG_LEN)) {
> >> Suggestion to change this check to:
> >>
> >> if (memcmp(pfn_sb->signature, DAX_SIG, PFN_SIG_LEN) &&
> >> !nd_supported_alignment(align))
> >>
> >> It would look a bit more natural i.e. "If the device has dax signature
> >> and alignment is
> >> not supported".
> >>
> >
> > I guess that should be !memcmp()? . I will send an updated patch with
> > the hash failure details in the commit message.
> >
>
> We need clarification on what the expected failure behaviour should be.
> The nd_pmem_probe doesn't really have a failure behaviour in this
> regard. For example.
>
> I created a dax device with 16M alignment
>
> {
> "dev":"namespace0.0",
> "mode":"devdax",
> "map":"dev",
> "size":"9.98 GiB (10.72 GB)",
> "uuid":"ba62ef22-ebdf-4779-96f5-e6135383ed22",
> "raw_uuid":"7b2492f9-7160-4ee9-9c3d-2f547d9ef3ee",
> "daxregion":{
> "id":0,
> "size":"9.98 GiB (10.72 GB)",
> "align":16777216,
> "devices":[
> {
> "chardev":"dax0.0",
> "size":"9.98 GiB (10.72 GB)"
> }
> ]
> },
> "align":16777216,
> "numa_node":0,
> "supported_alignments":[
> 65536,
> 16777216
> ]
> }
>
> Now what we want is to fail the initialization of the device when we
> boot a kernel that doesn't support 16M page size. But with the
> nd_pmem_probe failure behaviour we now end up with
>
> [
> {
> "dev":"namespace0.0",
> "mode":"fsdax",
> "map":"mem",
> "size":10737418240,
> "uuid":"7b2492f9-7160-4ee9-9c3d-2f547d9ef3ee",
> "blockdev":"pmem0"
> }
> ]
>
> So it did fallthrough the
>
> /* if we find a valid info-block we'll come back as that personality
> */
> if (nd_btt_probe(dev, ndns) == 0 || nd_pfn_probe(dev, ndns) == 0
> || nd_dax_probe(dev, ndns) == 0)
> return -ENXIO;
>
> /* ...otherwise we're just a raw pmem device */
> return pmem_attach_disk(dev, ndns);
>
>
> Is it ok if i update the code such that we don't do that default
> pmem_atach_disk if we have a label area?
Yes. This seems a new case where the driver finds a valid info-block,
but the capability to load that configuration is missing. So perhaps
special case a EOPNOTSUPP return code from those info-block probe
routines as "fail, and don't fallback to a raw device".
Re: [PATCH] mm/nvdimm: Pick the right alignment default when creating dax devices
Hi Dan,
"Aneesh Kumar K.V" writes:
> On 5/17/19 8:19 PM, Vaibhav Jain wrote:
>> Hi Aneesh,
>>
>>
>>> + /*
>>> +* Check whether the we support the alignment. For Dax if the
>>> +* superblock alignment is not matching, we won't initialize
>>> +* the device.
>>> +*/
>>> + if (!nd_supported_alignment(align) &&
>>> + memcmp(pfn_sb->signature, DAX_SIG, PFN_SIG_LEN)) {
>> Suggestion to change this check to:
>>
>> if (memcmp(pfn_sb->signature, DAX_SIG, PFN_SIG_LEN) &&
>> !nd_supported_alignment(align))
>>
>> It would look a bit more natural i.e. "If the device has dax signature and
>> alignment is
>> not supported".
>>
>
> I guess that should be !memcmp()? . I will send an updated patch with
> the hash failure details in the commit message.
>
We need clarification on what the expected failure behaviour should be.
The nd_pmem_probe doesn't really have a failure behaviour in this
regard. For example.
I created a dax device with 16M alignment
{
"dev":"namespace0.0",
"mode":"devdax",
"map":"dev",
"size":"9.98 GiB (10.72 GB)",
"uuid":"ba62ef22-ebdf-4779-96f5-e6135383ed22",
"raw_uuid":"7b2492f9-7160-4ee9-9c3d-2f547d9ef3ee",
"daxregion":{
"id":0,
"size":"9.98 GiB (10.72 GB)",
"align":16777216,
"devices":[
{
"chardev":"dax0.0",
"size":"9.98 GiB (10.72 GB)"
}
]
},
"align":16777216,
"numa_node":0,
"supported_alignments":[
65536,
16777216
]
}
Now what we want is to fail the initialization of the device when we
boot a kernel that doesn't support 16M page size. But with the
nd_pmem_probe failure behaviour we now end up with
[
{
"dev":"namespace0.0",
"mode":"fsdax",
"map":"mem",
"size":10737418240,
"uuid":"7b2492f9-7160-4ee9-9c3d-2f547d9ef3ee",
"blockdev":"pmem0"
}
]
So it did fallthrough the
/* if we find a valid info-block we'll come back as that personality */
if (nd_btt_probe(dev, ndns) == 0 || nd_pfn_probe(dev, ndns) == 0
|| nd_dax_probe(dev, ndns) == 0)
return -ENXIO;
/* ...otherwise we're just a raw pmem device */
return pmem_attach_disk(dev, ndns);
Is it ok if i update the code such that we don't do that default
pmem_atach_disk if we have a label area?
-aneesh
