Hi all,

The last time I used my ecovec sh7724 board was with kernel 4.1 and that worked 
fine.

But I needed to do some more testing with the mainline kernel and this 
generated this
error:

------------[ cut here ]------------
kernel BUG at arch/sh/mm/kmap.c:47!
Kernel BUG: 003e [#1]

CPU: 0 PID: 553 Comm: systemd Not tainted 4.5.0-rc5-renesas #49
task: 968ac4a0 ti: 9568e000 task.ti: 9568e000
PC is at kmap_coherent+0x52/0xe0
PR is at kmap_coherent+0x28/0xe0
PC  : 88013d52 SP  : 9568feb0 SR  : 40008000 TEA : 2957677f
R0  : dffff000 R1  : 88664ff8 R2  : 00003810 R3  : 134a750e
R4  : 885a68c4 R5  : 00000000 R6  : 134ae50c R7  : 00003f10
R8  : 887ce5c0 R9  : 0007bfff R10 : 00001000 R11 : 00001040
R12 : 00000001 R13 : 9569230c R14 : 00000000
MACH: 00000002 MACL: 00000000 GBR : 2957bd50 PR  : 88013d28

Call trace:
 [<88011806>] __flush_anon_page+0xc6/0x100
 [<880ae268>] __get_user_pages.part.31+0x348/0x3e0
 [<880d58d6>] copy_strings+0xd6/0x2c0
 [<880d619e>] kernel_read+0x1e/0x40
 [<880d5db2>] copy_strings_kernel+0x12/0x20
 [<880d5b40>] count.constprop.40+0x0/0xe0
 [<880d75cc>] do_execveat_common+0x46c/0x680
 [<880d77f8>] do_execve+0x18/0x40
 [<880d7a80>] SyS_execve+0x0/0x40
 [<8800927e>] syscall_call+0x18/0x1e

Code:
  88013d4c:  tst       r2, r2
  88013d4e:  bt.s      88013da0
  88013d50:  mov.l     @r1, r3
->88013d52:  trapa     #62
  88013d54:  mov.l     88013dd8 <kmap_coherent+0xd8/0xe0>, r2  ! 8864e790 
<0x8864e790>
  88013d56:  mov       r8, r4
  88013d58:  mov.l     @r2, r2
  88013d5a:  sub       r2, r4
  88013d5c:  mov       #-5, r2

Process: systemd (pid: 553, stack limit = 9568e001)
Stack: (0x9568feb0 to 0x95690000)
fea0:                                     88011806 887ce5c0 934ae000 00001040
fec0: 880ae268 7bffffc2 887ce5c0 968ac4a0 95620020 00000001 00000010 00000000
fee0: 880d58d6 00020000 00000000 968b9010 fffff000 7bffffc2 9697dd7c 9697dd00
ff00: 00000017 9568ff34 00000000 00000000 0000003a 880d619e 9697ddb0 00000000
ff20: 00000000 00000ffc 00000000 00000000 00000080 887ce5c0 880d5db2 00000080
ff40: 9697dd7c 9697dd00 7b90feec 7b90fb5c 880d5b40 80000000 880d75cc 968b9000
ff60: 9569230c 95620058 00000000 00000000 880d77f8 7b90fb5c 52be8914 296dac54
ff80: 00000000 00000071 00000100 880d7a80 00000000 8800927e 000000ec fffffec2
ffa0: fffffff4 000000ec fffffec2 fffffff4 0000000b 52bf2438 7b90fb5c 7b90feec
ffc0: 2957b940 52be9e44 7b90fb34 52bf2438 52be6034 296dac54 52be8914 7b90fb5c
ffe0: 7b90fb2c 29636be4 29636d1e 00008001 2957bd50 0a136394 00000040 0000004c
------------[ cut here ]------------

Always at the same place (kmap.c line 47), but with different stack traces,
e.g.:

Call trace:
 [<880114b2>] copy_user_highpage+0x152/0x260
 [<880af48a>] wp_page_copy.isra.102+0x6a/0x600
 [<88037c20>] preempt_count_sub+0x0/0xe0
 [<880b032e>] do_wp_page.isra.104+0x14e/0x9c0
 [<88037c20>] preempt_count_sub+0x0/0xe0
 [<884e864c>] __down_read+0xcc/0x140
 [<880b30d0>] handle_mm_fault+0x8b0/0xfe0
 [<88003820>] arch_local_irq_restore+0x0/0x40
 [<880090ec>] ret_from_exception+0x0/0x8
 [<88043abc>] __up_read+0x1c/0xa0
 [<884e85a0>] __down_read+0x20/0x140
 [<884e864c>] __down_read+0xcc/0x140
 [<88013586>] do_page_fault+0xe6/0x300
 [<880090ec>] ret_from_exception+0x0/0x8
 [<88009010>] tlb_protection_violation_store+0x0/0x4
 [<880090ec>] ret_from_exception+0x0/0x8

I noticed that 4.1 was ok and v4.2 wasn't, so I did a git bisect and ended up 
with
commit 8222dbe21e79338de92d5e1956cd1e3994cc9f93 (sched/preempt, mm/fault: 
Decouple
preemption from the page fault logic) as the culprit.

It makes this change to include/linux/uaccess.h:

 static inline void pagefault_disable(void)
 {
-       preempt_count_inc();
        pagefault_disabled_inc();
        /*
         * make sure to have issued the store before a pagefault
@@ -47,11 +40,6 @@ static inline void pagefault_enable(void)
         */
        barrier();
        pagefault_disabled_dec();
-#ifndef CONFIG_PREEMPT
-       preempt_count_dec();
-#else
-       preempt_enable();
-#endif
 }

I'm sure something was missed in arch/sh that caused this to go wrong.
But that's where my expertise ends.

I can easily reproduce it on my board, so if someone has a patch for me
to test, then that's no problem.

For now I am just reverting this for the time being so that I can continue
testing some v4l2 drivers.

Regards,

        Hans

Reply via email to