Re: sh7724 regression: commit 8222dbe21e79338de92d5e1956cd1e3994cc9f93

2016-03-29 Thread David Hildenbrand 
> On Wed, Mar 16, 2016 at 08:35:20PM -0400, Rich Felker wrote:
> > On Sun, Mar 13, 2016 at 03:08:42PM -0400, Rich Felker wrote:  
> > > On Fri, Mar 11, 2016 at 12:06:22PM +0100, David Hildenbrand wrote:  
> > > >   
> > > > > > > That fixes it for me:
> > > > > > > 
> > > > > > > Tested-by: Hans Verkuil 
> > > > > > > 
> > > > > > > BTW, your patch is garbled and I had to manually make the change 
> > > > > > > (not a big
> > > > > > > deal for a simple change like this).
> > > > > > > 
> > > > > > 
> > > > > > Thanks for testing. I just copy-pasted the patch, so this was 
> > > > > > somehow
> > > > > > expected :)
> > > > > > 
> > > > > > @maintainers, how to proceed with this? Shall I send that patch 
> > > > > > again directly
> > > > > > to the linux-sh list?
> > > > > > 
> > > > > > David
> > > > >   
> > > > 
> > > > How to proceed with this patch? Anyone?  
> > > 
> > > Sorry for not getting you a response sooner. I don't yet have the
> > > hardware to test this fix on (would like to find some), but it looks
> > > reasonable to me and like it doesn't risk introducing other
> > > regressions. Sato-san, do you have any thoughts or objections to the
> > > patch?  
> > 
> > Can you follow up with a well-formed patch that I can apply. No
> > promises since I'm new to kernel maintainership workflow but I'll try
> > to get it in this merge window if I can.  
> 
> I was able to clean it up (looks like terminal copy just botched
> all the spaces) so I'm applying it to my tree, since it seems likely
> that most SH models with MMU are broken without it. Thanks!
> 
> Rich
> 

Hi Rich,

sorry, was on vacation and could respond quickly ;)

Thanks for applying this!

David

Re: sh7724 regression: commit 8222dbe21e79338de92d5e1956cd1e3994cc9f93

2016-03-20 Thread Rich Felker 
On Wed, Mar 16, 2016 at 08:35:20PM -0400, Rich Felker wrote:
> On Sun, Mar 13, 2016 at 03:08:42PM -0400, Rich Felker wrote:
> > On Fri, Mar 11, 2016 at 12:06:22PM +0100, David Hildenbrand wrote:
> > > 
> > > > > > That fixes it for me:
> > > > > > 
> > > > > > Tested-by: Hans Verkuil 
> > > > > > 
> > > > > > BTW, your patch is garbled and I had to manually make the change 
> > > > > > (not a big
> > > > > > deal for a simple change like this).
> > > > > >   
> > > > > 
> > > > > Thanks for testing. I just copy-pasted the patch, so this was somehow
> > > > > expected :)
> > > > > 
> > > > > @maintainers, how to proceed with this? Shall I send that patch again 
> > > > > directly
> > > > > to the linux-sh list?
> > > > > 
> > > > > David  
> > > > 
> > > 
> > > How to proceed with this patch? Anyone?
> > 
> > Sorry for not getting you a response sooner. I don't yet have the
> > hardware to test this fix on (would like to find some), but it looks
> > reasonable to me and like it doesn't risk introducing other
> > regressions. Sato-san, do you have any thoughts or objections to the
> > patch?
> 
> Can you follow up with a well-formed patch that I can apply. No
> promises since I'm new to kernel maintainership workflow but I'll try
> to get it in this merge window if I can.

I was able to clean it up (looks like terminal copy just botched
all the spaces) so I'm applying it to my tree, since it seems likely
that most SH models with MMU are broken without it. Thanks!

Rich

Re: sh7724 regression: commit 8222dbe21e79338de92d5e1956cd1e3994cc9f93

2016-03-13 Thread Rich Felker 
On Fri, Mar 11, 2016 at 12:06:22PM +0100, David Hildenbrand wrote:
> 
> > > > That fixes it for me:
> > > > 
> > > > Tested-by: Hans Verkuil 
> > > > 
> > > > BTW, your patch is garbled and I had to manually make the change (not a 
> > > > big
> > > > deal for a simple change like this).
> > > >   
> > > 
> > > Thanks for testing. I just copy-pasted the patch, so this was somehow
> > > expected :)
> > > 
> > > @maintainers, how to proceed with this? Shall I send that patch again 
> > > directly
> > > to the linux-sh list?
> > > 
> > > David  
> > 
> 
> How to proceed with this patch? Anyone?

Sorry for not getting you a response sooner. I don't yet have the
hardware to test this fix on (would like to find some), but it looks
reasonable to me and like it doesn't risk introducing other
regressions. Sato-san, do you have any thoughts or objections to the
patch?

Rich

Re: sh7724 regression: commit 8222dbe21e79338de92d5e1956cd1e3994cc9f93

2016-03-11 Thread David Hildenbrand 

> > > That fixes it for me:
> > > 
> > > Tested-by: Hans Verkuil 
> > > 
> > > BTW, your patch is garbled and I had to manually make the change (not a 
> > > big
> > > deal for a simple change like this).
> > >   
> > 
> > Thanks for testing. I just copy-pasted the patch, so this was somehow
> > expected :)
> > 
> > @maintainers, how to proceed with this? Shall I send that patch again 
> > directly
> > to the linux-sh list?
> > 
> > David  
> 

How to proceed with this patch? Anyone?

David

Re: sh7724 regression: commit 8222dbe21e79338de92d5e1956cd1e3994cc9f93

2016-03-01 Thread Simon Horman 
[CC Super H maintainers: Sato-san and Rich Felker]

On Mon, Feb 29, 2016 at 12:03:38PM +0100, David Hildenbrand wrote:
> > On 02/29/2016 09:24 AM, David Hildenbrand wrote:
> > >> On 02/27/2016 03:28 PM, John Paul Adrian Glaubitz wrote:  
> > >>> Hi Hans!
> > >>>
> > >>> On 02/27/2016 03:20 PM, Geert Uytterhoeven wrote:
> > > 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.
> > >>>
> > >>> If you like, please report this the kernel bug tracker and set
> > >>> "Hardware" to "SuperH". This way we are able to keep track of
> > >>> the issue.
> > >>>
> > >>> I think Yoshinori Sato and Rich Felker will have a look at this.
> > >>>
> > >>> Adrian
> > >>> 
> > >>
> > >> Done: https://bugzilla.kernel.org/show_bug.cgi?id=113321
> > >>
> > >> Regards,
> > >>
> > >>  Hans
> > >>  
> > > 
> > > Looks like the code then requires to not be allowed to sleep/preempt in 
> > > these
> > > sections (just like kmap_atomic, or kmap_coherent on mips).
> > > 
> > > So the fix should be simple as (untested):  
> > 
> > That fixes it for me:
> > 
> > Tested-by: Hans Verkuil 
> > 
> > BTW, your patch is garbled and I had to manually make the change (not a big
> > deal for a simple change like this).
> > 
> 
> Thanks for testing. I just copy-pasted the patch, so this was somehow
> expected :)
> 
> @maintainers, how to proceed with this? Shall I send that patch again directly
> to the linux-sh list?
> 
> David

Re: sh7724 regression: commit 8222dbe21e79338de92d5e1956cd1e3994cc9f93

2016-02-29 Thread David Hildenbrand 
> On 02/29/2016 09:24 AM, David Hildenbrand wrote:
> >> On 02/27/2016 03:28 PM, John Paul Adrian Glaubitz wrote:  
> >>> Hi Hans!
> >>>
> >>> On 02/27/2016 03:20 PM, Geert Uytterhoeven wrote:
> > 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.
> >>>
> >>> If you like, please report this the kernel bug tracker and set
> >>> "Hardware" to "SuperH". This way we are able to keep track of
> >>> the issue.
> >>>
> >>> I think Yoshinori Sato and Rich Felker will have a look at this.
> >>>
> >>> Adrian
> >>> 
> >>
> >> Done: https://bugzilla.kernel.org/show_bug.cgi?id=113321
> >>
> >> Regards,
> >>
> >>Hans
> >>  
> > 
> > Looks like the code then requires to not be allowed to sleep/preempt in 
> > these
> > sections (just like kmap_atomic, or kmap_coherent on mips).
> > 
> > So the fix should be simple as (untested):  
> 
> That fixes it for me:
> 
> Tested-by: Hans Verkuil 
> 
> BTW, your patch is garbled and I had to manually make the change (not a big
> deal for a simple change like this).
> 

Thanks for testing. I just copy-pasted the patch, so this was somehow
expected :)

@maintainers, how to proceed with this? Shall I send that patch again directly
to the linux-sh list?

David

Re: sh7724 regression: commit 8222dbe21e79338de92d5e1956cd1e3994cc9f93

2016-02-29 Thread Hans Verkuil 
On 02/29/2016 09:24 AM, David Hildenbrand wrote:
>> On 02/27/2016 03:28 PM, John Paul Adrian Glaubitz wrote:
>>> Hi Hans!
>>>
>>> On 02/27/2016 03:20 PM, Geert Uytterhoeven wrote:  
> 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.  
>>>
>>> If you like, please report this the kernel bug tracker and set
>>> "Hardware" to "SuperH". This way we are able to keep track of
>>> the issue.
>>>
>>> I think Yoshinori Sato and Rich Felker will have a look at this.
>>>
>>> Adrian
>>>   
>>
>> Done: https://bugzilla.kernel.org/show_bug.cgi?id=113321
>>
>> Regards,
>>
>>  Hans
>>
> 
> Looks like the code then requires to not be allowed to sleep/preempt in these
> sections (just like kmap_atomic, or kmap_coherent on mips).
> 
> So the fix should be simple as (untested):

That fixes it for me:

Tested-by: Hans Verkuil 

BTW, your patch is garbled and I had to manually make the change (not a big
deal for a simple change like this).

Thanks!

Hans

> 
> From d29f0d0cb670175c688cdd181c7a693d28b27a33 Mon Sep 17 00:00:00 2001
>  
> From: David Hildenbrand  
>  
> Date: Mon, 29 Feb 2016 09:19:24 +0100 
>  
> Subject: [PATCH] sched/preempt, sh: kmap_coherent relies on disabled  
>  
>  preemption   
>  
>   
>  
> kmap_coherent needs disabled preemption to not schedule in the critical   
>  
> section, just like kmap_coherent on mips and kmap_atomic in general.  
>  
>   
>  
> Fixes: 8222dbe21e79 "sched/preempt, mm/fault: Decouple preemption from the 
> page fault logic"
> Reported-by: Hans Verkuil 
>  
> Signed-off-by: David Hildenbrand 
>  
> ---   
>  
>  arch/sh/mm/kmap.c | 2 ++ 
>  
>  1 file changed, 2 insertions(+)  
>  
>   
>  
> diff --git a/arch/sh/mm/kmap.c b/arch/sh/mm/kmap.c
>  
> index ec29e14..bf25d7c 100644 
>  
> --- a/arch/sh/mm/kmap.c   
>  
> +++ b/arch/sh/mm/kmap.c   
>  
> @@ -36,6 +36,7 @@ void *kmap_coherent(struct page *page, unsigned long addr)  
>   
>   
>  
> BUG_ON(!test_bit(PG_dcache_clean, >flags)); 
>  
>   
>  
> +   preempt_disable();
>  
> pagefault_disable();  
>  
>   
>  
> idx = FIX_CMAP_END -  
>  
> @@ -64,4 +65,5 @@ void kunmap_coherent(void *kvaddr)  
>  
> } 
>  
>   
>  
> pagefault_enable();   
>  
> +   preempt_enable(); 
>  
>  }
>  
> --
>  
> 2.3.9 
>  
>  
> 
> David
>

Re: sh7724 regression: commit 8222dbe21e79338de92d5e1956cd1e3994cc9f93

2016-02-29 Thread David Hildenbrand 
> On 02/27/2016 03:28 PM, John Paul Adrian Glaubitz wrote:
> > Hi Hans!
> > 
> > On 02/27/2016 03:20 PM, Geert Uytterhoeven wrote:  
> >>> 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.  
> > 
> > If you like, please report this the kernel bug tracker and set
> > "Hardware" to "SuperH". This way we are able to keep track of
> > the issue.
> > 
> > I think Yoshinori Sato and Rich Felker will have a look at this.
> > 
> > Adrian
> >   
> 
> Done: https://bugzilla.kernel.org/show_bug.cgi?id=113321
> 
> Regards,
> 
>   Hans
> 

Looks like the code then requires to not be allowed to sleep/preempt in these
sections (just like kmap_atomic, or kmap_coherent on mips).

So the fix should be simple as (untested):

>From d29f0d0cb670175c688cdd181c7a693d28b27a33 Mon Sep 17 00:00:00 2001 
>
From: David Hildenbrand    
   
Date: Mon, 29 Feb 2016 09:19:24 +0100   
   
Subject: [PATCH] sched/preempt, sh: kmap_coherent relies on disabled
   
 preemption 
   

   
kmap_coherent needs disabled preemption to not schedule in the critical 
   
section, just like kmap_coherent on mips and kmap_atomic in general.
   

   
Fixes: 8222dbe21e79 "sched/preempt, mm/fault: Decouple preemption from the page 
fault logic"
Reported-by: Hans Verkuil   
   
Signed-off-by: David Hildenbrand   
   
--- 
   
 arch/sh/mm/kmap.c | 2 ++   
   
 1 file changed, 2 insertions(+)
   

   
diff --git a/arch/sh/mm/kmap.c b/arch/sh/mm/kmap.c  
   
index ec29e14..bf25d7c 100644   
   
--- a/arch/sh/mm/kmap.c 
   
+++ b/arch/sh/mm/kmap.c 
   
@@ -36,6 +36,7 @@ void *kmap_coherent(struct page *page, unsigned long addr)

   
BUG_ON(!test_bit(PG_dcache_clean, >flags));   
   

   
+   preempt_disable();  
   
pagefault_disable();
   

   
idx = FIX_CMAP_END -
   
@@ -64,4 +65,5 @@ void kunmap_coherent(void *kvaddr)
   
}   
   

   
pagefault_enable(); 
   
+   preempt_enable();   
   
 }  
   
--  
   
2.3.9   
   
 

David

Re: sh7724 regression: commit 8222dbe21e79338de92d5e1956cd1e3994cc9f93

2016-02-27 Thread John Paul Adrian Glaubitz 
Hi Hans!

On 02/27/2016 03:20 PM, Geert Uytterhoeven wrote:
>> 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.

If you like, please report this the kernel bug tracker and set
"Hardware" to "SuperH". This way we are able to keep track of
the issue.

I think Yoshinori Sato and Rich Felker will have a look at this.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: sh7724 regression: commit 8222dbe21e79338de92d5e1956cd1e3994cc9f93

2016-02-27 Thread Geert Uytterhoeven 
CC linux-sh

On Sat, Feb 27, 2016 at 2:50 PM, Hans Verkuil  wrote:
> 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  : d000 R1  : 88664ff8 R2  : 3810 R3  : 134a750e
> R4  : 885a68c4 R5  :  R6  : 134ae50c R7  : 3f10
> R8  : 887ce5c0 R9  : 0007bfff R10 : 1000 R11 : 1040
> R12 : 0001 R13 : 9569230c R14 : 
> MACH: 0002 MACL:  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 , 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 0x9569)
> fea0: 88011806 887ce5c0 934ae000 1040
> fec0: 880ae268 7bc2 887ce5c0 968ac4a0 95620020 0001 0010 
> fee0: 880d58d6 0002  968b9010 f000 7bc2 9697dd7c 9697dd00
> ff00: 0017 9568ff34   003a 880d619e 9697ddb0 
> ff20:  0ffc   0080 887ce5c0 880d5db2 0080
> ff40: 9697dd7c 9697dd00 7b90feec 7b90fb5c 880d5b40 8000 880d75cc 968b9000
> ff60: 9569230c 95620058   880d77f8 7b90fb5c 52be8914 296dac54
> ff80:  0071 0100 880d7a80  8800927e 00ec fec2
> ffa0: fff4 00ec fec2 fff4 000b 52bf2438 7b90fb5c 7b90feec
> ffc0: 2957b940 52be9e44 7b90fb34 52bf2438 52be6034 296dac54 52be8914 7b90fb5c
> ffe0: 7b90fb2c 29636be4 29636d1e 8001 2957bd50 0a136394 0040 004c
> [ 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

sh7724 regression: commit 8222dbe21e79338de92d5e1956cd1e3994cc9f93

2016-02-27 Thread Hans Verkuil 
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  : d000 R1  : 88664ff8 R2  : 3810 R3  : 134a750e
R4  : 885a68c4 R5  :  R6  : 134ae50c R7  : 3f10
R8  : 887ce5c0 R9  : 0007bfff R10 : 1000 R11 : 1040
R12 : 0001 R13 : 9569230c R14 : 
MACH: 0002 MACL:  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 , 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 0x9569)
fea0: 88011806 887ce5c0 934ae000 1040
fec0: 880ae268 7bc2 887ce5c0 968ac4a0 95620020 0001 0010 
fee0: 880d58d6 0002  968b9010 f000 7bc2 9697dd7c 9697dd00
ff00: 0017 9568ff34   003a 880d619e 9697ddb0 
ff20:  0ffc   0080 887ce5c0 880d5db2 0080
ff40: 9697dd7c 9697dd00 7b90feec 7b90fb5c 880d5b40 8000 880d75cc 968b9000
ff60: 9569230c 95620058   880d77f8 7b90fb5c 52be8914 296dac54
ff80:  0071 0100 880d7a80  8800927e 00ec fec2
ffa0: fff4 00ec fec2 fff4 000b 52bf2438 7b90fb5c 7b90feec
ffc0: 2957b940 52be9e44 7b90fb34 52bf2438 52be6034 296dac54 52be8914 7b90fb5c
ffe0: 7b90fb2c 29636be4 29636d1e 8001 2957bd50 0a136394 0040 004c
[ 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