diff mbox

[v2,0/8] sparc64: MM/IRQ patch queue.

Message ID 20140930.222900.1514307861753222790.davem@davemloft.net
State RFC
Delegated to: David Miller
Headers show

Commit Message

David Miller Oct. 1, 2014, 2:29 a.m. UTC 
From: Bob Picco <bpicco@meloft.net>
Date: Tue, 30 Sep 2014 18:28:41 -0400

> Okay, I lied partially. Let me examine this in the morning. You can
> go first :)

Thanks :)  The boot mostly looks successful no?

There are a couple blips, let's take a look:

> Performance events: No support for PMU type 'niagara5'

Hmmm, this was patched into an older tree I guess, as supported_pmu()
accepts 'niagara5' as far as I can tell.  Oh I see, you patched
against vanilla 3.17-rc7 instead of my 'sparc' GIT tree.

> SELinux:  Registering netfilter hooks
> Kernel unaligned access at TPC[675f74] sha256_transform+0x14/0x2840
> Kernel unaligned access at TPC[675f88] sha256_transform+0x28/0x2840
> Kernel unaligned access at TPC[675f88] sha256_transform+0x28/0x2840
> Kernel unaligned access at TPC[675f88] sha256_transform+0x28/0x2840
> Kernel unaligned access at TPC[675f88] sha256_transform+0x28/0x2840
> alg: No test for stdrng (krng)

Interesting.  sha256_transform() depends upon the input data being
at least 32-bit aligned.  Let's get a stack backtrace to see how
this happens:

====================

> f0290d30: ttyS0 at I/O 0x0 (irq = 1, base_baud = 115200) is a SUN4V HCONS
> NMI watchdog: BUG: soft lockup - CPU#527 stuck for 22s! [swapper/0:1]
> Modules linked in:

I think this is triggered because in console_unlock() all buffered console
output is emitted all at once.  And with all of those vmemmap log messages
it gets huge.

I guess this is another reason to trim down those messages, so I'll work
on that now. :)

> aes_sparc64: Using sparc64 aes opcodes optimized AES implementation
> alg: skcipher-ddst: Test 5 failed on encryption for ctr-aes-sparc64
> 00000000: da 4e 3f bc e8 b6 3a a2 d5 4d 84 4a a9 0c e1 a5

Hmmm, interesting.  I just noticed that I haven't enabled the
sparc64 crypto drivers in my current test .config, but I
turned them on and I don't get this test failure.

I'll try to reproduce with the 'tcrypt' module or similar.

> sd 5:0:2:0: attempting task abort! scmd(fff8183f401d97a0)
> sd 5:0:2:0: [sde] CDB: 
> Read(10): 28 20 0a 20 2b 23 00 00 08 00
> scsi target5:0:2: handle(0x000b), sas_address(0x5000cca016322f71), phy(2)
> scsi target5:0:2: enclosure_logical_id(0x508002000159c0d1), slot(2)
> sd 5:0:2:0: task abort: SUCCESS scmd(fff8183f401d97a0)

I get these every once in a while, the block I/O always recovers.

I assume this booted all the way to a login prompt or similar?

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

David Miller Oct. 1, 2014, 2:57 a.m. UTC | #1 
From: David Miller <davem@davemloft.net>
Date: Tue, 30 Sep 2014 22:29:00 -0400 (EDT)

> From: Bob Picco <bpicco@meloft.net>
> Date: Tue, 30 Sep 2014 18:28:41 -0400
> 
>> aes_sparc64: Using sparc64 aes opcodes optimized AES implementation
>> alg: skcipher-ddst: Test 5 failed on encryption for ctr-aes-sparc64
>> 00000000: da 4e 3f bc e8 b6 3a a2 d5 4d 84 4a a9 0c e1 a5
> 
> Hmmm, interesting.  I just noticed that I haven't enabled the
> sparc64 crypto drivers in my current test .config, but I
> turned them on and I don't get this test failure.
> 
> I'll try to reproduce with the 'tcrypt' module or similar.

I don't see it because my config has CRYPTO_MANAGER_DISABLE_TESTS set,
which is the default :-/

I can reproduce this AES failure as well as the unaligned accesses.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bob Picco Oct. 1, 2014, 11:51 a.m. UTC | #2 
Hi,
David Miller wrote:	[Tue Sep 30 2014, 10:29:00PM EDT]
> From: Bob Picco <bpicco@meloft.net>
> Date: Tue, 30 Sep 2014 18:28:41 -0400
> 
> > Okay, I lied partially. Let me examine this in the morning. You can
> > go first :)
> 
> Thanks :)  The boot mostly looks successful no?
You're welcome. Yes it does.
> 
> There are a couple blips, let's take a look:
> 
> > Performance events: No support for PMU type 'niagara5'
> 
> Hmmm, this was patched into an older tree I guess, as supported_pmu()
> accepts 'niagara5' as far as I can tell.  Oh I see, you patched
> against vanilla 3.17-rc7 instead of my 'sparc' GIT tree.
Yes.
> 
> > SELinux:  Registering netfilter hooks
> > Kernel unaligned access at TPC[675f74] sha256_transform+0x14/0x2840
> > Kernel unaligned access at TPC[675f88] sha256_transform+0x28/0x2840
> > Kernel unaligned access at TPC[675f88] sha256_transform+0x28/0x2840
> > Kernel unaligned access at TPC[675f88] sha256_transform+0x28/0x2840
> > Kernel unaligned access at TPC[675f88] sha256_transform+0x28/0x2840
> > alg: No test for stdrng (krng)
> 
> Interesting.  sha256_transform() depends upon the input data being
> at least 32-bit aligned.  Let's get a stack backtrace to see how
> this happens:
> 
> ====================
> diff --git a/arch/sparc/kernel/unaligned_64.c b/arch/sparc/kernel/unaligned_64.c
> index 62098a8..59ea98a 100644
> --- a/arch/sparc/kernel/unaligned_64.c
> +++ b/arch/sparc/kernel/unaligned_64.c
> @@ -299,6 +299,7 @@ static void log_unaligned(struct pt_regs *regs)
>  	if (__ratelimit(&ratelimit)) {
>  		printk("Kernel unaligned access at TPC[%lx] %pS\n",
>  		       regs->tpc, (void *) regs->tpc);
> +		dump_stack();
>  	}
>  }
>  
> ====================
> 
> > f0290d30: ttyS0 at I/O 0x0 (irq = 1, base_baud = 115200) is a SUN4V HCONS
> > NMI watchdog: BUG: soft lockup - CPU#527 stuck for 22s! [swapper/0:1]
> > Modules linked in:
> 
> I think this is triggered because in console_unlock() all buffered console
> output is emitted all at once.  And with all of those vmemmap log messages
> it gets huge.
Agree.
> 
> I guess this is another reason to trim down those messages, so I'll work
> on that now. :)
Thanx.
> 
> > aes_sparc64: Using sparc64 aes opcodes optimized AES implementation
> > alg: skcipher-ddst: Test 5 failed on encryption for ctr-aes-sparc64
> > 00000000: da 4e 3f bc e8 b6 3a a2 d5 4d 84 4a a9 0c e1 a5
> 
> Hmmm, interesting.  I just noticed that I haven't enabled the
> sparc64 crypto drivers in my current test .config, but I
> turned them on and I don't get this test failure.
> 
> I'll try to reproduce with the 'tcrypt' module or similar.
okay.
> 
> > sd 5:0:2:0: attempting task abort! scmd(fff8183f401d97a0)
> > sd 5:0:2:0: [sde] CDB: 
> > Read(10): 28 20 0a 20 2b 23 00 00 08 00
> > scsi target5:0:2: handle(0x000b), sas_address(0x5000cca016322f71), phy(2)
> > scsi target5:0:2: enclosure_logical_id(0x508002000159c0d1), slot(2)
> > sd 5:0:2:0: task abort: SUCCESS scmd(fff8183f401d97a0)
> 
> I get these every once in a while, the block I/O always recovers.
Me too. One exception being local T5-2 because of management dinosaur
deception.
> 
> I assume this booted all the way to a login prompt or similar?
Yes. I just cloned sparc.git during VPN and proxy quiet period.
I'll attempt to hang on to T5-8 until we conclude :)
> 
> Thanks!
you're welcome and thanx!
> 
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bob Picco Oct. 1, 2014, 2:29 p.m. UTC | #3 
Bob Picco wrote:	[Wed Oct 01 2014, 07:51:08AM EDT]
> Hi,
> David Miller wrote:	[Tue Sep 30 2014, 10:29:00PM EDT]
> > I assume this booted all the way to a login prompt or similar?
> Yes. I just cloned sparc.git during VPN and proxy quiet period.
> I'll attempt to hang on to T5-8 until we conclude :)
We seem to encounter the spec-jbb like issue under heavy threaded make
of sparc.git with our work. A similar load had no issue on local T5-2 and
T4-2. It raised its ugly head quickly on T5-8. It could be painful to pursue
on T5-8.

Last night I was pondering whether it might be slab related for spec-jbb.
Though I've not flushed these thoughts thoroughly in or out.

I'm in pursuit! Bloody dentist today.

[root@ca-qasparc24 ~]# Unable to handle kernel NULL pointer dereference
BUG: Bad page map in process cc1  pte:9800003fdd860690 pmd:183f3f4b6000
page:000600007fbb0c00 count:107055216 mapcount:-524287 mapping:          (null) index:0xfff8000107659c00
page flags: 0x6c4b6e00004f56(error|referenced|dirty|active|owner_priv_1|arch_1|reserved|private|head)
page dumped because: bad pte
addr:0000000000124000 vm_flags:00000875 anon_vma:          (null) mapping:fff8003f18a06a78 index:12
vma->vm_ops->fault: filemap_fault+0x8/0x440
vma->vm_file->f_op->mmap: ext4_file_mmap+0x8/0x40 [ext4]
CPU: 497 PID: 19886 Comm: cc1 Tainted: G             L 3.17.0-rc7 #1
Call Trace:
 [0000000000567394] print_bad_pte+0x134/0x1e0
 [000000000056ade0] zap_pte_range+0x4c0/0x580
 [000000000056afd4] unmap_page_range+0x134/0x220
 [000000000056b11c] unmap_single_vma+0x5c/0xc0
 [000000000056b1a8] unmap_vmas+0x28/0x60
 [000000000056e248] exit_mmap+0x88/0x160
 [0000000000465c74] mmput+0x54/0xe0
 [00000000004691bc] exit_mm+0x13c/0x1c0
 [000000000046a750] do_exit+0x130/0x440
 [000000000046aa90] do_group_exit+0x30/0xc0
 [000000000046ab3c] SyS_exit_group+0x1c/0x40
 [0000000000406234] linux_sparc_syscall+0x34/0x44
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller Oct. 1, 2014, 8:42 p.m. UTC | #4 
From: Bob Picco <bpicco@meloft.net>
Date: Wed, 1 Oct 2014 10:29:00 -0400

> [root@ca-qasparc24 ~]# Unable to handle kernel NULL pointer dereference
> BUG: Bad page map in process cc1  pte:9800003fdd860690 pmd:183f3f4b6000
> page:000600007fbb0c00 count:107055216 mapcount:-524287 mapping:          (null) index:0xfff8000107659c00
> page flags: 0x6c4b6e00004f56(error|referenced|dirty|active|owner_priv_1|arch_1|reserved|private|head)
> page dumped because: bad pte

The first thing I notice is that the count, mapcount, and flags are all garbage.

But not just random garbage, all of the non-zero bytes in the page
flags are in visible the ASCII character range.

0x6c = 'l'
0x4b = 'K'
0x6e = 'n'
0x4f = 'O'
0x56 = 'V'

Anyways, just FYI...
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller Oct. 1, 2014, 8:44 p.m. UTC | #5 
From: David Miller <davem@davemloft.net>
Date: Wed, 01 Oct 2014 16:42:01 -0400 (EDT)

> From: Bob Picco <bpicco@meloft.net>
> Date: Wed, 1 Oct 2014 10:29:00 -0400
> 
>> [root@ca-qasparc24 ~]# Unable to handle kernel NULL pointer dereference
>> BUG: Bad page map in process cc1  pte:9800003fdd860690 pmd:183f3f4b6000
>> page:000600007fbb0c00 count:107055216 mapcount:-524287 mapping:          (null) index:0xfff8000107659c00
>> page flags: 0x6c4b6e00004f56(error|referenced|dirty|active|owner_priv_1|arch_1|reserved|private|head)
>> page dumped because: bad pte
> 
> The first thing I notice is that the count, mapcount, and flags are all garbage.
> 
> But not just random garbage, all of the non-zero bytes in the page
> flags are in visible the ASCII character range.
> 
> 0x6c = 'l'
> 0x4b = 'K'
> 0x6e = 'n'
> 0x4f = 'O'
> 0x56 = 'V'
> 
> Anyways, just FYI...

Also, Bob, that "Unable to handle kernel NULL pointer dereference"
should have placed a good register dump and backtrace into the kernel
logs, maybe you can provide that as well.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bob Picco Oct. 1, 2014, 9:51 p.m. UTC | #6 
Hi,
David Miller wrote:	[Wed Oct 01 2014, 04:44:55PM EDT]
> From: David Miller <davem@davemloft.net>
> Date: Wed, 01 Oct 2014 16:42:01 -0400 (EDT)
> 
> > From: Bob Picco <bpicco@meloft.net>
> > Date: Wed, 1 Oct 2014 10:29:00 -0400
> > 
> >> [root@ca-qasparc24 ~]# Unable to handle kernel NULL pointer dereference
> >> BUG: Bad page map in process cc1  pte:9800003fdd860690 pmd:183f3f4b6000
> >> page:000600007fbb0c00 count:107055216 mapcount:-524287 mapping:          (null) index:0xfff8000107659c00
> >> page flags: 0x6c4b6e00004f56(error|referenced|dirty|active|owner_priv_1|arch_1|reserved|private|head)
> >> page dumped because: bad pte
> > 
> > The first thing I notice is that the count, mapcount, and flags are all garbage.
> > 
> > But not just random garbage, all of the non-zero bytes in the page
> > flags are in visible the ASCII character range.
> > 
> > 0x6c = 'l'
> > 0x4b = 'K'
> > 0x6e = 'n'
> > 0x4f = 'O'
> > 0x56 = 'V'
> > 
> > Anyways, just FYI...
> 
> Also, Bob, that "Unable to handle kernel NULL pointer dereference"
> should have placed a good register dump and backtrace into the kernel
> logs, maybe you can provide that as well.
I'll let you examine this one closely. I was examining code and what was
observed on Sunday and not inspected closely.

On T4-2 I'm obtaining a solid baseline. sparc.git !THP and !HUGEPAGES
with spec-jbb. It appears good.

On T5-8 I did build sparc.git but not with as massive parallel make -j10.

Please let me know should you want more or whether this is worthless.

BUG: Bad page map in process cc1  pte:9800003fdd860690 pmd:183f3f4b6000
page:000600007fbb0c00 count:107055216 mapcount:-524287 mapping:          (null) index:0xfff8000107659c00
page flags: 0x6c4b6e00004f56(error|referenced|dirty|active|owner_priv_1|arch_1|reserved|private|head)
page dumped because: bad pte
addr:0000000000124000 vm_flags:00000875 anon_vma:          (null) mapping:fff8003f18a06a78 index:12
vma->vm_ops->fault: filemap_fault+0x8/0x440
vma->vm_file->f_op->mmap: ext4_file_mmap+0x8/0x40 [ext4]
CPU: 497 PID: 19886 Comm: cc1 Tainted: G             L 3.17.0-rc7 #1
Call Trace:
 [0000000000567394] print_bad_pte+0x134/0x1e0
 [000000000056ade0] zap_pte_range+0x4c0/0x580
 [000000000056afd4] unmap_page_range+0x134/0x220
 [000000000056b11c] unmap_single_vma+0x5c/0xc0
 [000000000056b1a8] unmap_vmas+0x28/0x60
 [000000000056e248] exit_mmap+0x88/0x160
 [0000000000465c74] mmput+0x54/0xe0
 [00000000004691bc] exit_mm+0x13c/0x1c0
 [000000000046a750] do_exit+0x130/0x440
 [000000000046aa90] do_group_exit+0x30/0xc0
 [000000000046ab3c] SyS_exit_group+0x1c/0x40
 [0000000000406234] linux_sparc_syscall+0x34/0x44
Disabling lock debugging due to kernel taint
BUG: Bad page map in process cc1  pte:9800003fdd860690 pmd:183f3c6e4000
page:000600007fbb0c00 count:107055215 mapcount:-524288 mapping:          (null) index:0xfff8000107659c00
page flags: 0x6c4b6e00004f56(error|referenced|dirty|active|owner_priv_1|arch_1|reserved|private|head)
page dumped because: bad pte
addr:0000000000124000 vm_flags:00000875 anon_vma:          (null) mapping:fff8003f18a06a78 index:12
vma->vm_ops->fault: filemap_fault+0x8/0x440
vma->vm_file->f_op->mmap: ext4_file_mmap+0x8/0x40 [ext4]
CPU: 442 PID: 19996 Comm: cc1 Tainted: G    B        L 3.17.0-rc7 #1
Call Trace:
 [0000000000567394] print_bad_pte+0x134/0x1e0
 [000000000056ade0] zap_pte_range+0x4c0/0x580
 [000000000056afd4] unmap_page_range+0x134/0x220
 [000000000056b11c] unmap_single_vma+0x5c/0xc0
 [000000000056b1a8] unmap_vmas+0x28/0x60
 [000000000056e248] exit_mmap+0x88/0x160
 [0000000000465c74] mmput+0x54/0xe0
 [00000000004691bc] exit_mm+0x13c/0x1c0
Unable to handle kernel NULL pointer dereference
 [000000000046a750] do_exit+0x130/0x440
tsk->{mm,active_mm}->context = 00000000000017c4
tsk->{mm,active_mm}->pgd = fff8003e95b7e000
 [000000000046aa90] do_group_exit+0x30/0xc0
              \|/ ____ \|/
              "@'/ .. \`@"
              /_| \__/ |_\
                 \__U_/
 [000000000046ab3c] SyS_exit_group+0x1c/0x40
cc1(20076): Oops [#1]
 [0000000000406234] linux_sparc_syscall+0x34/0x44
CPU: 105 PID: 20076 Comm: cc1 Tainted: G    B        L 3.17.0-rc7 #1
task: fff8003f07de88a0 ti: fff8003e95c88000 task.ti: fff8003e95c88000
TSTATE: 0000000011e01602 TPC: 000000000058ea2c TNPC: 000000000058ea30 Y: fcdcf300    Tainted: G    B        L
TPC: <kfree+0x8c/0x2a0>
g0: fff8003fddef7888 g1: 0006000000000000 g2: 00000000000003c8 g3: 0000000000be6800
g4: fff8003f07de88a0 g5: fff8003f5c98e000 g6: fff8003e95c88000 g7: 0000000000d62000
o0: 0000000000000000 o1: 0000000000000081 o2: 0000000000000020 o3: 0000000000000000
o4: 0000000000008000 o5: 0000000000000008 sp: fff8003e95c8aff1 ret_pc: 000000000063e4cc
RPC: <security_inode_permission+0x2c/0x40>
l0: 0000000000000000 l1: fff8003f0852f220 l2: 0000000000000000 l3: 0000000000643408
l4: 0000000000000014 l5: 00000000009fd430 l6: fff8003e95c88000 l7: 00000000005a1860
i0: fff8003f0852f220 i1: 0000000000000081 i2: 0000000000000010 i3: 0000000014fed5a6
i4: 0000000000666100 i5: 0000000000000078 i6: fff8003e95c8b0c1 i7: 0000000000643030
I7: <selinux_file_free_security+0x10/0x20>
Call Trace:
 [0000000000643030] selinux_file_free_security+0x10/0x20
 [000000000063c2b8] security_file_free+0x18/0x40
 [00000000005a55c8] put_filp+0x28/0x60
 [00000000005b336c] path_openat+0xec/0x4c0
 [00000000005b3868] do_filp_open+0x28/0xa0
 [00000000005a1728] do_sys_open+0x148/0x240
 [00000000005a1884] SyS_open+0x24/0x40
 [0000000000406234] linux_sparc_syscall+0x34/0x44
Caller[0000000000643030]: selinux_file_free_security+0x10/0x20
Caller[000000000063c2b8]: security_file_free+0x18/0x40
Caller[00000000005a55c8]: put_filp+0x28/0x60
Caller[00000000005b336c]: path_openat+0xec/0x4c0
Caller[00000000005b3868]: do_filp_open+0x28/0xa0
Caller[00000000005a1728]: do_sys_open+0x148/0x240
Caller[00000000005a1884]: SyS_open+0x24/0x40
Caller[0000000000406234]: linux_sparc_syscall+0x34/0x44
Caller[0000000000659d38]: constraint_expr_eval+0x658/0x6a0
Instruction DUMP: 84048002  80a36001  04400015 <e658a008> c459e2b8  a207a7e7  c658e198  84260002  f077a7f7 
BUG: Bad page map in process cc1  pte:9800003fdd860690 pmd:3e95b92000
page:000600007fbb0c00 count:107055215 mapcount:-524289 mapping:          (null) index:0xfff8000107659c00
page flags: 0x6c4b6e00004f56(error|referenced|dirty|active|owner_priv_1|arch_1|reserved|private|head)
page dumped because: bad pte
addr:0000000000124000 vm_flags:00000875 anon_vma:          (null) mapping:fff8003f18a06a78 index:12
vma->vm_ops->fault: filemap_fault+0x8/0x440
vma->vm_file->f_op->mmap: ext4_file_mmap+0x8/0x40 [ext4]
CPU: 105 PID: 20076 Comm: cc1 Tainted: G    B D      L 3.17.0-rc7 #1
Call Trace:
 [0000000000567394] print_bad_pte+0x134/0x1e0
 [000000000056ade0] zap_pte_range+0x4c0/0x580
 [000000000056afd4] unmap_page_range+0x134/0x220
 [000000000056b11c] unmap_single_vma+0x5c/0xc0
 [000000000056b1a8] unmap_vmas+0x28/0x60
 [000000000056e248] exit_mmap+0x88/0x160
 [0000000000465c74] mmput+0x54/0xe0
 [00000000004691bc] exit_mm+0x13c/0x1c0
 [000000000046a750] do_exit+0x130/0x440
 [0000000000428500] die_if_kernel+0x1a0/0x340
 [000000000097f498] unhandled_fault+0x78/0xe0
 [000000000097f528] do_kernel_fault+0x28/0x100
 [000000000097f820] do_sparc64_fault+0x220/0x7a0
 [0000000000407b8c] sparc64_realfault_common+0x10/0x20
 [000000000058ea2c] kfree+0x8c/0x2a0
 [0000000000643030] selinux_file_free_security+0x10/0x20
BUG: Bad page map in process cc1  pte:9800003f0a92c690 pmd:3e95b92000
page:000600007e152580 count:0 mapcount:-1 mapping:          (null) index:0x0
page flags: 0x0()
page dumped because: bad pte
addr:0000000000126000 vm_flags:00000875 anon_vma:          (null) mapping:fff8003f18a06a78 index:13
vma->vm_ops->fault: filemap_fault+0x8/0x440
vma->vm_file->f_op->mmap: ext4_file_mmap+0x8/0x40 [ext4]
CPU: 105 PID: 20076 Comm: cc1 Tainted: G    B D      L 3.17.0-rc7 #1
Call Trace:
 [0000000000567394] print_bad_pte+0x134/0x1e0
 [000000000056ade0] zap_pte_range+0x4c0/0x580
 [000000000056afd4] unmap_page_range+0x134/0x220
 [000000000056b11c] unmap_single_vma+0x5c/0xc0
 [000000000056b1a8] unmap_vmas+0x28/0x60
 [000000000056e248] exit_mmap+0x88/0x160
 [0000000000465c74] mmput+0x54/0xe0
 [00000000004691bc] exit_mm+0x13c/0x1c0
 [000000000046a750] do_exit+0x130/0x440
 [0000000000428500] die_if_kernel+0x1a0/0x340
 [000000000097f498] unhandled_fault+0x78/0xe0
 [000000000097f528] do_kernel_fault+0x28/0x100
 [000000000097f820] do_sparc64_fault+0x220/0x7a0
 [0000000000407b8c] sparc64_realfault_common+0x10/0x20
 [000000000058ea2c] kfree+0x8c/0x2a0
 [0000000000643030] selinux_file_free_security+0x10/0x20
BUG: Bad page map in process cc1  pte:9800003f0c4d8690 pmd:3e95b92000
page:000600007e189b00 count:0 mapcount:-1 mapping:          (null) index:0x0
page flags: 0x0()
page dumped because: bad pte
addr:0000000000128000 vm_flags:00000875 anon_vma:          (null) mapping:fff8003f18a06a78 index:14
vma->vm_ops->fault: filemap_fault+0x8/0x440
vma->vm_file->f_op->mmap: ext4_file_mmap+0x8/0x40 [ext4]
CPU: 105 PID: 20076 Comm: cc1 Tainted: G    B D      L 3.17.0-rc7 #1
Call Trace:
 [0000000000567394] print_bad_pte+0x134/0x1e0
 [000000000056ade0] zap_pte_range+0x4c0/0x580
 [000000000056afd4] unmap_page_range+0x134/0x220
 [000000000056b11c] unmap_single_vma+0x5c/0xc0
 [000000000056b1a8] unmap_vmas+0x28/0x60
 [000000000056e248] exit_mmap+0x88/0x160
 [0000000000465c74] mmput+0x54/0xe0
 [00000000004691bc] exit_mm+0x13c/0x1c0
 [000000000046a750] do_exit+0x130/0x440
 [0000000000428500] die_if_kernel+0x1a0/0x340
 [000000000097f498] unhandled_fault+0x78/0xe0
 [000000000097f528] do_kernel_fault+0x28/0x100
 [000000000097f820] do_sparc64_fault+0x220/0x7a0
 [0000000000407b8c] sparc64_realfault_common+0x10/0x20
 [000000000058ea2c] kfree+0x8c/0x2a0
 [0000000000643030] selinux_file_free_security+0x10/0x20
BUG: Bad page map in process cc1  pte:9800003f0d876690 pmd:3e95b92000
page:000600007e1b0ec0 count:0 mapcount:-1 mapping:fff800010722cf60 index:0x0
page flags: 0x0()
page dumped because: bad pte
addr:000000000027a000 vm_flags:00000875 anon_vma:          (null) mapping:fff8003f18a06a78 index:bd
vma->vm_ops->fault: filemap_fault+0x8/0x440
vma->vm_file->f_op->mmap: ext4_file_mmap+0x8/0x40 [ext4]
CPU: 105 PID: 20076 Comm: cc1 Tainted: G    B D      L 3.17.0-rc7 #1
Call Trace:
 [0000000000567394] print_bad_pte+0x134/0x1e0
 [000000000056ade0] zap_pte_range+0x4c0/0x580
 [000000000056afd4] unmap_page_range+0x134/0x220
 [000000000056b11c] unmap_single_vma+0x5c/0xc0
 [000000000056b1a8] unmap_vmas+0x28/0x60
 [000000000056e248] exit_mmap+0x88/0x160
 [0000000000465c74] mmput+0x54/0xe0
 [00000000004691bc] exit_mm+0x13c/0x1c0
 [000000000046a750] do_exit+0x130/0x440
 [0000000000428500] die_if_kernel+0x1a0/0x340
 [000000000097f498] unhandled_fault+0x78/0xe0
 [000000000097f528] do_kernel_fault+0x28/0x100
 [000000000097f820] do_sparc64_fault+0x220/0x7a0
 [0000000000407b8c] sparc64_realfault_common+0x10/0x20
 [000000000058ea2c] kfree+0x8c/0x2a0
 [0000000000643030] selinux_file_free_security+0x10/0x20
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 0000000000001835
tsk->{mm,active_mm}->pgd = fff8003e95bf0000
              \|/ ____ \|/
              "@'/ .. \`@"
              /_| \__/ |_\
                 \__U_/
cc1(20161): Oops [#2]
CPU: 3 PID: 20161 Comm: cc1 Tainted: G    B D      L 3.17.0-rc7 #1
task: fff8003e95e19d20 ti: fff8003e95e1c000 task.ti: fff8003e95e1c000
TSTATE: 0000000011e01602 TPC: 000000000058ea2c TNPC: 000000000058ea30 Y: fcdcf300    Tainted: G    B D      L
TPC: <kfree+0x8c/0x2a0>
g0: fff8003fddef7888 g1: 0006000000000000 g2: 0000000000000098 g3: 0000000000be6800
g4: fff8003e95e19d20 g5: fff8003f5c32e000 g6: fff8003e95e1c000 g7: 0000000000d62000
o0: 0000000000000000 o1: 0000000000000081 o2: 0000000000000020 o3: 0000000000000000
o4: 0000000000008000 o5: 0000000000000008 sp: fff8003e95e1eff1 ret_pc: 000000000063e4cc
RPC: <security_inode_permission+0x2c/0x40>
l0: 0000000000000000 l1: fff8003f0f5887e0 l2: 0000000000000000 l3: 0000000000643408
l4: 0000000000000014 l5: 00000000009e3e40 l6: fff8003e95e1c000 l7: 00000000005a1860
i0: fff8003f0f5887e0 i1: 0000000000000081 i2: 0000000000000010 i3: 000000007b401fe7
i4: 0000000000b9f723 i5: 0000000000000078 i6: fff8003e95e1f0c1 i7: 0000000000643030
I7: <selinux_file_free_security+0x10/0x20>
Call Trace:
 [0000000000643030] selinux_file_free_security+0x10/0x20
 [000000000063c2b8] security_file_free+0x18/0x40
 [00000000005a55c8] put_filp+0x28/0x60
 [00000000005b336c] path_openat+0xec/0x4c0
 [00000000005b3868] do_filp_open+0x28/0xa0
 [00000000005a1728] do_sys_open+0x148/0x240
 [00000000005a1884] SyS_open+0x24/0x40
 [0000000000406234] linux_sparc_syscall+0x34/0x44
Caller[0000000000643030]: selinux_file_free_security+0x10/0x20
Caller[000000000063c2b8]: security_file_free+0x18/0x40
Caller[00000000005a55c8]: put_filp+0x28/0x60
Caller[00000000005b336c]: path_openat+0xec/0x4c0
Caller[00000000005b3868]: do_filp_open+0x28/0xa0
Caller[00000000005a1728]: do_sys_open+0x148/0x240
Caller[00000000005a1884]: SyS_open+0x24/0x40
Caller[0000000000406234]: linux_sparc_syscall+0x34/0x44
Caller[0000000000659d38]: constraint_expr_eval+0x658/0x6a0
Instruction DUMP: 84048002  80a36001  04400015 <e658a008> c459e2b8  a207a7e7  c658e198  84260002  f077a7f7 
BUG: Bad page map in process cc1  pte:9800003fdd860690 pmd:3e95e48000
page:000600007fbb0c00 count:107055215 mapcount:-524290 mapping:          (null) index:0xfff8000107659c00
page flags: 0x6c4b6e00004f56(error|referenced|dirty|active|owner_priv_1|arch_1|reserved|private|head)
page dumped because: bad pte
addr:0000000000124000 vm_flags:00000875 anon_vma:          (null) mapping:fff8003f18a06a78 index:12
vma->vm_ops->fault: filemap_fault+0x8/0x440
vma->vm_file->f_op->mmap: ext4_file_mmap+0x8/0x40 [ext4]
CPU: 3 PID: 20161 Comm: cc1 Tainted: G    B D      L 3.17.0-rc7 #1
Call Trace:
 [0000000000567394] print_bad_pte+0x134/0x1e0
 [000000000056ade0] zap_pte_range+0x4c0/0x580
 [000000000056afd4] unmap_page_range+0x134/0x220
 [000000000056b11c] unmap_single_vma+0x5c/0xc0
 [000000000056b1a8] unmap_vmas+0x28/0x60
 [000000000056e248] exit_mmap+0x88/0x160
 [0000000000465c74] mmput+0x54/0xe0
 [00000000004691bc] exit_mm+0x13c/0x1c0
 [000000000046a750] do_exit+0x130/0x440
 [0000000000428500] die_if_kernel+0x1a0/0x340
 [000000000097f498] unhandled_fault+0x78/0xe0
 [000000000097f528] do_kernel_fault+0x28/0x100
 [000000000097f820] do_sparc64_fault+0x220/0x7a0
 [0000000000407b8c] sparc64_realfault_common+0x10/0x20
 [000000000058ea2c] kfree+0x8c/0x2a0
 [0000000000643030] selinux_file_free_security+0x10/0x20
BUG: Bad page map in process cc1  pte:9800003f0a92c690 pmd:3e95e48000
page:000600007e152580 count:0 mapcount:-2 mapping:          (null) index:0x0
page flags: 0x4(referenced)
page dumped because: bad pte
addr:0000000000126000 vm_flags:00000875 anon_vma:          (null) mapping:fff8003f18a06a78 index:13
vma->vm_ops->fault: filemap_fault+0x8/0x440
vma->vm_file->f_op->mmap: ext4_file_mmap+0x8/0x40 [ext4]
CPU: 3 PID: 20161 Comm: cc1 Tainted: G    B D      L 3.17.0-rc7 #1
Call Trace:
 [0000000000567394] print_bad_pte+0x134/0x1e0
 [000000000056ade0] zap_pte_range+0x4c0/0x580
 [000000000056afd4] unmap_page_range+0x134/0x220
 [000000000056b11c] unmap_single_vma+0x5c/0xc0
 [000000000056b1a8] unmap_vmas+0x28/0x60
 [000000000056e248] exit_mmap+0x88/0x160
 [0000000000465c74] mmput+0x54/0xe0
 [00000000004691bc] exit_mm+0x13c/0x1c0
 [000000000046a750] do_exit+0x130/0x440
 [0000000000428500] die_if_kernel+0x1a0/0x340
 [000000000097f498] unhandled_fault+0x78/0xe0
 [000000000097f528] do_kernel_fault+0x28/0x100
 [000000000097f820] do_sparc64_fault+0x220/0x7a0
 [0000000000407b8c] sparc64_realfault_common+0x10/0x20
 [000000000058ea2c] kfree+0x8c/0x2a0
 [0000000000643030] selinux_file_free_security+0x10/0x20
BUG: Bad page map in process cc1  pte:9800003f0ccc6690 pmd:3e95e48000


--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bob Picco Oct. 2, 2014, 2:24 p.m. UTC | #7 
Hi,
Bob Picco wrote:	[Wed Oct 01 2014, 05:51:09PM EDT]
> Hi,
> David Miller wrote:	[Wed Oct 01 2014, 04:44:55PM EDT]
> > From: David Miller <davem@davemloft.net>
> > Date: Wed, 01 Oct 2014 16:42:01 -0400 (EDT)
> > 
> > > From: Bob Picco <bpicco@meloft.net>
> > > Date: Wed, 1 Oct 2014 10:29:00 -0400
> > > 
> > >> [root@ca-qasparc24 ~]# Unable to handle kernel NULL pointer dereference
> > >> BUG: Bad page map in process cc1  pte:9800003fdd860690 pmd:183f3f4b6000
> > >> page:000600007fbb0c00 count:107055216 mapcount:-524287 mapping:          (null) index:0xfff8000107659c00
> > >> page flags: 0x6c4b6e00004f56(error|referenced|dirty|active|owner_priv_1|arch_1|reserved|private|head)
> > >> page dumped because: bad pte
> > > 
Okay I have two meetings today.

This is where we seem to go bad on T4-2. We go equally bad very quickly on
T5-8 with all patches applied and !THP.

T4-2 is configured for THP "madvise". At this commit:
59a35b1 sparc64: Use kernel page tables for vmemmap.
we seem to fall apart on T4-2 with the program below.

./thp4-loop -a 1024 8192

This all needs to be reverified.

thanx!

<<toy program>>

#define	_GNU_SOURCE
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <sys/mman.h>

#ifndef MADV_HUGEPAGE
#define MADV_HUGEPAGE	14
#endif

#define HPAGE_SHIFT	(22UL)
#define	HPAGE_SIZE	(1UL << HPAGE_SHIFT)
#define	PAGE_SHIFT	(13UL)
#define	NR_PAGES_HPAGE	(HPAGE_SIZE >> PAGE_SHIFT)
#define __round_mask(x, y) ((__typeof__(x))((y)-1))
#define round_up(x, y) ((((x)-1) | __round_mask(x, y))+1)

/* Note failure assumes an exit(1).
 */
void *allocate_thps(size_t sz)
{
	int rc;
	void *addr;
	size_t align = HPAGE_SIZE;

	rc = posix_memalign(&addr, align, sz);

	if (rc)
		perror("posix_memalign"), exit(1);

	rc = madvise(addr, sz, MADV_HUGEPAGE);

	if (rc) {
		static int warn_once;

		if (warn_once)
			goto out;
		fprintf(stderr, "Couldn't madvise for MADV_HUGEPAGE.\n");
		warn_once = 1;
	}
out:
	return addr;
}

/* Verify the array.
 */
static void verify_thp(void *addr, void *end, int pagesize, int cnt)
{
	unsigned long pc;
	void *p;

	for (pc = 0, p = addr; p < end; p += pagesize, pc++) {
		if (*(unsigned long *) p != 0xbeefUL + (pc << 32UL)) {
			fprintf(stderr, "\n\tcnt = %d pc=0x%lx thp = 0x%lx "
				" addr=0x%lx *addr=0x%lx\n",
				cnt, pc, pc >> 9UL, p, *(unsigned long *) p);
			pc = (pc + NR_PAGES_HPAGE) & ~(NR_PAGES_HPAGE - 1);
			pc--;
			p = addr + (pc << PAGE_SHIFT);
		}
	}

}

int main(int argc, char **argv)
{
	void *addr, *end, *p;
	size_t sz;
	int pagesize = getpagesize();
	int loop, cnt, nthp, rc;
	int recycle = 1;
	unsigned long pc;
	int optind = 0;

	if (argc == 4 && argv[1][1] == 'a')
		optind = 1;
	else if (argc != 3)
		fprintf(stderr, "%s: -a iterations 4Mb-pages\n",
			argv[0]), exit(1);

	rc = sscanf(argv[optind + 1], "%d", &loop);

	if (rc != 1)
		fprintf(stderr, "%s: sscanf (%s) failed\n",
			argv[0], argv[optind + 1]), exit(1);

	rc = sscanf(argv[optind + 2], "%d", &nthp);

	if (rc != 1)
		fprintf(stderr, "%s: sscanf (%s) failed\n",
			argv[0], argv[optind + 2]), exit(1);

	if (optind)
		recycle = 0;

	sz = HPAGE_SIZE * nthp;

	for (cnt = 0; cnt < loop; cnt++) {
		addr = allocate_thps(sz);
		end = addr + sz;

		fprintf(stderr, "[0x%lx-0x%lx) ",
			(unsigned long) addr, (unsigned long) end);

		for (pc = 0, p = addr; p < end; p += pagesize, pc++)
			*(unsigned long *) p = 0xbeefUL + (pc << 32UL);

		verify_thp(addr, end, pagesize, cnt);

		sleep(cnt % 5);

		verify_thp(addr, end, pagesize, cnt);

		if (recycle)
			free(addr);

		fprintf(stdout, ".\n");
		fflush(stdout);
	}

	fprintf(stderr, "%s: Done! cnt = %d\n", argv[0], cnt);

	return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller Oct. 3, 2014, 10:53 p.m. UTC | #8 
From: Bob Picco <bpicco@meloft.net>
Date: Thu, 2 Oct 2014 10:24:35 -0400

> This is where we seem to go bad on T4-2. We go equally bad very quickly on
> T5-8 with all patches applied and !THP.
> 
> T4-2 is configured for THP "madvise". At this commit:
> 59a35b1 sparc64: Use kernel page tables for vmemmap.
> we seem to fall apart on T4-2 with the program below.
> 
> ./thp4-loop -a 1024 8192
> 
> This all needs to be reverified.

Excellent report, I'll try to reproduce and look into that
vmemmap commit for problems.

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller Oct. 4, 2014, 7:12 p.m. UTC | #9 
From: Bob Picco <bpicco@meloft.net>
Date: Thu, 2 Oct 2014 10:24:35 -0400

> At this commit:
> 59a35b1 sparc64: Use kernel page tables for vmemmap.

I think I figured out what the bug is.

It has to do with how KERN_PGTABLE_WALK masks in the sub-pagesize
bits for huge pages.

That assembler works fine for PAGE_OFFSET mappings where the
sub-pagesize bits always have a direct correspondance to the
physical bits.  But for something like vmemmap that doesn't
work.

I'll verify this and work on a fix.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bob Picco Oct. 5, 2014, 1:51 p.m. UTC | #10 
David Miller wrote:	[Sat Oct 04 2014, 03:12:37PM EDT]
> From: Bob Picco <bpicco@meloft.net>
> Date: Thu, 2 Oct 2014 10:24:35 -0400
> 
> > At this commit:
> > 59a35b1 sparc64: Use kernel page tables for vmemmap.
> 
> I think I figured out what the bug is.
> 
> It has to do with how KERN_PGTABLE_WALK masks in the sub-pagesize
> bits for huge pages.
> 
> That assembler works fine for PAGE_OFFSET mappings where the
> sub-pagesize bits always have a direct correspondance to the
> physical bits.  But for something like vmemmap that doesn't
> work.
> 
> I'll verify this and work on a fix.
This is exactly where I was on Friday afternoon. Unfortunately I was too
exhausted to contribute.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller Oct. 13, 2014, 3:53 a.m. UTC | #11 
From: David Miller <davem@davemloft.net>
Date: Tue, 30 Sep 2014 22:57:12 -0400 (EDT)

> I can reproduce this AES failure as well as the unaligned accesses.

I've figured out the nature of the AES failure.

The code tries to optimize the case of processing many blocks at a
time, by preloading the KEY material into the FPU registers then
running the encrypt/decrypt routine over and over again reusing
those precooked registers.

Somehow it appears that the pre-cooked key registers get spammed
upon.  Even if we get an intervening memcpy() via the blkcipher*()
calls, we fully support recursive FPU usage in the kernel on sparc64
so it should "just work".

The test case passes if I change the ->ecb_encrypt() call in
ctr_crypt_final() to ->encrypt() (which hand loads the key into the
FPU before performing a single block encrypt).

Anyways I'll dig further and fix this.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

====================
diff --git a/arch/sparc/kernel/unaligned_64.c b/arch/sparc/kernel/unaligned_64.c
index 62098a8..59ea98a 100644
--- a/arch/sparc/kernel/unaligned_64.c
+++ b/arch/sparc/kernel/unaligned_64.c
@@ -299,6 +299,7 @@  static void log_unaligned(struct pt_regs *regs)
 	if (__ratelimit(&ratelimit)) {
 		printk("Kernel unaligned access at TPC[%lx] %pS\n",
 		       regs->tpc, (void *) regs->tpc);
+		dump_stack();
 	}
 }