2.6.28-rc2: Unable to handle kernel paging request at iov_iter_copy_from_user_atomic

2.6.28-rc2: Unable to handle kernel paging request at iov_iter_copy_from_user_atomic

[Alexander Beregalov]

 2.6.28-rc2-00452-gf891caf on sparc64

How to reproduce: run dbench on tmpfs


Unable to handle kernel paging request at virtual address fffff80037c1c000
tsk->{mm,active_mm}->context = 0000000000001ae7
tsk->{mm,active_mm}->pgd = fffff8000ec8c000
              \|/ ____ \|/
              "@'/ .. \`@"
              /_| \__/ |_\
                 \__U_/
dbench(5007): Oops [#1]
TSTATE: 0000000011009604 TPC: 00000000005acbac TNPC: 00000000005acbb0
Y: 00000000    Not tainted
TPC: <__bzero+0x20/0xc0>
g0: 0000000000000016 g1: 0000000000000000 g2: 0000000000000000 g3:
0000000000033ae7
g4: fffff8000ec9c380 g5: 0000000000000020 g6: fffff8003b834000 g7:
ffffffffffffe8b1
o0: fffff80037c1c8b1 o1: 00000000000008b1 o2: 0000000000000000 o3:
fffff80037c1c8b1
o4: 0000000000000000 o5: 0000000000034398 sp: fffff8003b836e41 ret_pc:
00000000005ae73c
RPC: <copy_from_user_fixup+0x4c/0x70>
l0: 0000000000852800 l1: 0000000011009603 l2: 0000000000827ff4 l3:
0000000000000400
l4: 0000000000000000 l5: 0000000000000001 l6: 0000000000000000 l7:
0000000000000008
i0: fffff80037c1e000 i1: 0000000000032398 i2: 00000000000008b1 i3:
fffff80037c3e398
i4: fffff80037c1e000 i5: 0000000000000000 i6: fffff8003b836f01 i7:
0000000000486f28
I7: <iov_iter_copy_from_user_atomic+0x90/0xe0>
Caller[0000000000486f28]: iov_iter_copy_from_user_atomic+0x90/0xe0
Caller[0000000000488a58]: generic_file_buffered_write+0x108/0x2a8
Caller[0000000000489140]: __generic_file_aio_write_nolock+0x35c/0x380
Caller[00000000004899b4]: generic_file_aio_write+0x58/0xc8
Caller[00000000004b23d4]: do_sync_write+0x90/0xe0
Caller[00000000004b2ca4]: vfs_write+0x7c/0x11c
Caller[00000000004b2d98]: sys_pwrite64+0x54/0x80
Caller[000000000043efa4]: sys32_pwrite64+0x20/0x34
Caller[0000000000406154]: linux_sparc_syscall32+0x34/0x40
Caller[00000000f7e8df80]: 0xf7e8df80
Instruction DUMP: c56a2000  808a2003  02480006 <d42a2000> 90022001
808a2003  1247fffd  92226001  808a2007
note: dbench[5007] exited with preempt_count 2
BUG: sleeping function called from invalid context at kernel/rwsem.c:21
in_atomic(): 1, irqs_disabled(): 0, pid: 5007, name: dbench
INFO: lockdep is turned off.
Call Trace:
 [000000000044b79c] __might_sleep+0x104/0x114
 [00000000006d81b4] down_read+0x18/0x50
 [0000000000451b08] exit_mm+0x28/0x128
 [000000000045359c] do_exit+0x1c4/0x7a4
 [0000000000429044] die_if_kernel+0x270/0x29c
 [00000000006da6d0] unhandled_fault+0x90/0x9c
 [00000000006dac38] do_sparc64_fault+0x55c/0x64c
 [0000000000407854] sparc64_realfault_common+0x10/0x20
 [00000000005acbac] __bzero+0x20/0xc0
 [0000000000486f28] iov_iter_copy_from_user_atomic+0x90/0xe0
 [0000000000488a58] generic_file_buffered_write+0x108/0x2a8
 [0000000000489140] __generic_file_aio_write_nolock+0x35c/0x380
 [00000000004899b4] generic_file_aio_write+0x58/0xc8
 [00000000004b23d4] do_sync_write+0x90/0xe0
 [00000000004b2ca4] vfs_write+0x7c/0x11c
 [00000000004b2d98] sys_pwrite64+0x54/0x80
BUG: scheduling while atomic: dbench/5007/0x04000003
INFO: lockdep is turned off.
Modules linked in:
Call Trace:
 [000000000044cc2c] __schedule_bug+0x6c/0x7c
 [00000000006d66b8] schedule+0xa0/0x484
 [000000000044d6d8] __cond_resched+0x2c/0x54
 [00000000006d6c80] _cond_resched+0x40/0x60
 [0000000000498c88] unmap_vmas+0x53c/0x644
 [000000000049d0f4] exit_mmap+0xc4/0x1b4
 [000000000044e24c] mmput+0x40/0xc4
 [0000000000451bf8] exit_mm+0x118/0x128
 [000000000045359c] do_exit+0x1c4/0x7a4
 [0000000000429044] die_if_kernel+0x270/0x29c
 [00000000006da6d0] unhandled_fault+0x90/0x9c
 [00000000006dac38] do_sparc64_fault+0x55c/0x64c
 [0000000000407854] sparc64_realfault_common+0x10/0x20
 [00000000005acbac] __bzero+0x20/0xc0
 [0000000000486f28] iov_iter_copy_from_user_atomic+0x90/0xe0
 [0000000000488a58] generic_file_buffered_write+0x108/0x2a8
BUG: scheduling while atomic: dbench/5007/0x04000003
INFO: lockdep is turned off.
Modules linked in:
Call Trace:
 [000000000044cc2c] __schedule_bug+0x6c/0x7c
 [00000000006d66b8] schedule+0xa0/0x484
 [000000000044d6d8] __cond_resched+0x2c/0x54
 [00000000006d6c80] _cond_resched+0x40/0x60
 [0000000000451ec4] put_files_struct+0xa8/0x104
 [0000000000451f50] exit_files+0x30/0x40
 [00000000004535ac] do_exit+0x1d4/0x7a4
 [0000000000429044] die_if_kernel+0x270/0x29c
 [00000000006da6d0] unhandled_fault+0x90/0x9c
 [00000000006dac38] do_sparc64_fault+0x55c/0x64c
 [0000000000407854] sparc64_realfault_common+0x10/0x20
 [00000000005acbac] __bzero+0x20/0xc0
 [0000000000486f28] iov_iter_copy_from_user_atomic+0x90/0xe0
 [0000000000488a58] generic_file_buffered_write+0x108/0x2a8
 [0000000000489140] __generic_file_aio_write_nolock+0x35c/0x380
 [00000000004899b4] generic_file_aio_write+0x58/0xc8
Unable to handle kernel paging request at virtual address fffff8003632a000
tsk->{mm,active_mm}->context = 0000000000001af9
tsk->{mm,active_mm}->pgd = fffff8000eca2000
              \|/ ____ \|/
              "@'/ .. \`@"
              /_| \__/ |_\
                 \__U_/
dbench(5025): Oops [#2]
TSTATE: 0000000011009604 TPC: 00000000005acbac TNPC: 00000000005acbb0
Y: 00000000    Tainted: G      D
TPC: <__bzero+0x20/0xc0>
g0: 0000000000000000 g1: 0000000000000000 g2: 0000000000000000 g3:
0000000000031af9
g4: fffff8000ed86c00 g5: 0000000000000020 g6: fffff8003b6c8000 g7:
ffffffffffffe897
o0: fffff8003632a897 o1: 0000000000000897 o2: 0000000000000000 o3:
fffff8003632a897
o4: 0000000000000000 o5: 0000000000032390 sp: fffff8003b6cae41 ret_pc:
00000000005ae73c
RPC: <copy_from_user_fixup+0x4c/0x70>
l0: 0000000000852800 l1: 0000000011009603 l2: 0000000000827ff4 l3:
0000000000000400
l4: 0000000000000000 l5: 0000000000000001 l6: 0000000000000000 l7:
0000000000000008
i0: fffff8003632c000 i1: 0000000000030390 i2: 0000000000000897 i3:
fffff8003633c390
i4: fffff8003632c000 i5: 0000000000000000 i6: fffff8003b6caf01 i7:
0000000000486f28
I7: <iov_iter_copy_from_user_atomic+0x90/0xe0>

and so on..

Re: 2.6.28-rc2: Unable to handle kernel paging request at iov_iter_copy_from_user_atomic

[Hugh Dickins]

On Sat, 1 Nov 2008, Alexander Beregalov wrote:
>  2.6.28-rc2-00452-gf891caf on sparc64
> 
> How to reproduce: run dbench on tmpfs
> 
> 
> Unable to handle kernel paging request at virtual address fffff80037c1c000
> tsk->{mm,active_mm}->context = 0000000000001ae7
> tsk->{mm,active_mm}->pgd = fffff8000ec8c000
>               \|/ ____ \|/
>               "@'/ .. \`@"
>               /_| \__/ |_\
>                  \__U_/
> dbench(5007): Oops [#1]
> TSTATE: 0000000011009604 TPC: 00000000005acbac TNPC: 00000000005acbb0
> Y: 00000000    Not tainted
> TPC: <__bzero+0x20/0xc0>
> g0: 0000000000000016 g1: 0000000000000000 g2: 0000000000000000 g3:
> 0000000000033ae7
> g4: fffff8000ec9c380 g5: 0000000000000020 g6: fffff8003b834000 g7:
> ffffffffffffe8b1
> o0: fffff80037c1c8b1 o1: 00000000000008b1 o2: 0000000000000000 o3:
> fffff80037c1c8b1
> o4: 0000000000000000 o5: 0000000000034398 sp: fffff8003b836e41 ret_pc:
> 00000000005ae73c
> RPC: <copy_from_user_fixup+0x4c/0x70>
> l0: 0000000000852800 l1: 0000000011009603 l2: 0000000000827ff4 l3:
> 0000000000000400
> l4: 0000000000000000 l5: 0000000000000001 l6: 0000000000000000 l7:
> 0000000000000008
> i0: fffff80037c1e000 i1: 0000000000032398 i2: 00000000000008b1 i3:
> fffff80037c3e398
> i4: fffff80037c1e000 i5: 0000000000000000 i6: fffff8003b836f01 i7:
> 0000000000486f28
> I7: <iov_iter_copy_from_user_atomic+0x90/0xe0>
> Caller[0000000000486f28]: iov_iter_copy_from_user_atomic+0x90/0xe0
> Caller[0000000000488a58]: generic_file_buffered_write+0x108/0x2a8
> Caller[0000000000489140]: __generic_file_aio_write_nolock+0x35c/0x380
> Caller[00000000004899b4]: generic_file_aio_write+0x58/0xc8
> Caller[00000000004b23d4]: do_sync_write+0x90/0xe0
> Caller[00000000004b2ca4]: vfs_write+0x7c/0x11c
> Caller[00000000004b2d98]: sys_pwrite64+0x54/0x80
> Caller[000000000043efa4]: sys32_pwrite64+0x20/0x34
> Caller[0000000000406154]: linux_sparc_syscall32+0x34/0x40
> Caller[00000000f7e8df80]: 0xf7e8df80
> Instruction DUMP: c56a2000  808a2003  02480006 <d42a2000> 90022001
> 808a2003  1247fffd  92226001  808a2007

[ Snipped the rest of it, which is just a consequence of oopsing
  there, then a repeat of this one on a different address ]

Good find!  Though surprising it's not been found before: something
for -stable I suspect.  Please don't take my signoff too seriously,
I cannot test this myself and it needs confirmation from DaveM...


Alexander Beregalov reports oops in __bzero() called from
copy_from_user_fixup() called from iov_iter_copy_from_user_atomic(),
when running dbench on tmpfs on sparc64: its __copy_from_user_inatomic
and __copy_to_user_inatomic should be avoiding, not calling, the fixups.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
---

 arch/sparc/include/asm/uaccess_64.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- 2.6.28-rc2/arch/sparc/include/asm/uaccess_64.h	2008-10-09 23:13:53.000000000 +0100
+++ linux/arch/sparc/include/asm/uaccess_64.h	2008-11-01 18:33:59.000000000 +0000
@@ -265,8 +265,8 @@ extern long __strnlen_user(const char __
 
 #define strlen_user __strlen_user
 #define strnlen_user __strnlen_user
-#define __copy_to_user_inatomic __copy_to_user
-#define __copy_from_user_inatomic __copy_from_user
+#define __copy_to_user_inatomic ___copy_to_user
+#define __copy_from_user_inatomic ___copy_from_user
 
 #endif  /* __ASSEMBLY__ */
 

Re: 2.6.28-rc2: Unable to handle kernel paging request at iov_iter_copy_from_user_atomic

[Alexander Beregalov]

2008/11/1 Hugh Dickins <hugh@veritas.com>:
> On Sat, 1 Nov 2008, Alexander Beregalov wrote:
>>  2.6.28-rc2-00452-gf891caf on sparc64
>>
>> How to reproduce: run dbench on tmpfs
>>
>>
>> Unable to handle kernel paging request at virtual address fffff80037c1c000
>> tsk->{mm,active_mm}->context = 0000000000001ae7
>> tsk->{mm,active_mm}->pgd = fffff8000ec8c000
>>               \|/ ____ \|/
>>               "@'/ .. \`@"
>>               /_| \__/ |_\
>>                  \__U_/
>> dbench(5007): Oops [#1]
>> TSTATE: 0000000011009604 TPC: 00000000005acbac TNPC: 00000000005acbb0
>> Y: 00000000    Not tainted
>> TPC: <__bzero+0x20/0xc0>
>> g0: 0000000000000016 g1: 0000000000000000 g2: 0000000000000000 g3:
>> 0000000000033ae7
>> g4: fffff8000ec9c380 g5: 0000000000000020 g6: fffff8003b834000 g7:
>> ffffffffffffe8b1
>> o0: fffff80037c1c8b1 o1: 00000000000008b1 o2: 0000000000000000 o3:
>> fffff80037c1c8b1
>> o4: 0000000000000000 o5: 0000000000034398 sp: fffff8003b836e41 ret_pc:
>> 00000000005ae73c
>> RPC: <copy_from_user_fixup+0x4c/0x70>
>> l0: 0000000000852800 l1: 0000000011009603 l2: 0000000000827ff4 l3:
>> 0000000000000400
>> l4: 0000000000000000 l5: 0000000000000001 l6: 0000000000000000 l7:
>> 0000000000000008
>> i0: fffff80037c1e000 i1: 0000000000032398 i2: 00000000000008b1 i3:
>> fffff80037c3e398
>> i4: fffff80037c1e000 i5: 0000000000000000 i6: fffff8003b836f01 i7:
>> 0000000000486f28
>> I7: <iov_iter_copy_from_user_atomic+0x90/0xe0>
>> Caller[0000000000486f28]: iov_iter_copy_from_user_atomic+0x90/0xe0
>> Caller[0000000000488a58]: generic_file_buffered_write+0x108/0x2a8
>> Caller[0000000000489140]: __generic_file_aio_write_nolock+0x35c/0x380
>> Caller[00000000004899b4]: generic_file_aio_write+0x58/0xc8
>> Caller[00000000004b23d4]: do_sync_write+0x90/0xe0
>> Caller[00000000004b2ca4]: vfs_write+0x7c/0x11c
>> Caller[00000000004b2d98]: sys_pwrite64+0x54/0x80
>> Caller[000000000043efa4]: sys32_pwrite64+0x20/0x34
>> Caller[0000000000406154]: linux_sparc_syscall32+0x34/0x40
>> Caller[00000000f7e8df80]: 0xf7e8df80
>> Instruction DUMP: c56a2000  808a2003  02480006 <d42a2000> 90022001
>> 808a2003  1247fffd  92226001  808a2007
>
> [ Snipped the rest of it, which is just a consequence of oopsing
>  there, then a repeat of this one on a different address ]
>
> Good find!  Though surprising it's not been found before: something
> for -stable I suspect.  Please don't take my signoff too seriously,
> I cannot test this myself and it needs confirmation from DaveM...
>
>
> Alexander Beregalov reports oops in __bzero() called from
> copy_from_user_fixup() called from iov_iter_copy_from_user_atomic(),
> when running dbench on tmpfs on sparc64: its __copy_from_user_inatomic
> and __copy_to_user_inatomic should be avoiding, not calling, the fixups.
>
> Signed-off-by: Hugh Dickins <hugh@veritas.com>
> ---
>
>  arch/sparc/include/asm/uaccess_64.h |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- 2.6.28-rc2/arch/sparc/include/asm/uaccess_64.h      2008-10-09 23:13:53.000000000 +0100
> +++ linux/arch/sparc/include/asm/uaccess_64.h   2008-11-01 18:33:59.000000000 +0000
> @@ -265,8 +265,8 @@ extern long __strnlen_user(const char __
>
>  #define strlen_user __strlen_user
>  #define strnlen_user __strnlen_user
> -#define __copy_to_user_inatomic __copy_to_user
> -#define __copy_from_user_inatomic __copy_from_user
> +#define __copy_to_user_inatomic ___copy_to_user
> +#define __copy_from_user_inatomic ___copy_from_user
>
>  #endif  /* __ASSEMBLY__ */
>
>
It helps, thanks.

Should we fix also sparc32?

diff --git a/arch/sparc/include/asm/uaccess_32.h
b/arch/sparc/include/asm/uaccess_32.h
index 47d5619..e878eb4 100644
--- a/arch/sparc/include/asm/uaccess_32.h
+++ b/arch/sparc/include/asm/uaccess_32.h
@@ -270,8 +270,8 @@ static inline unsigned long __copy_from_user(void
*to, const void __user *from,
        return __copy_user((__force void __user *) to, from, n);
 }

-#define __copy_to_user_inatomic __copy_to_user
-#define __copy_from_user_inatomic __copy_from_user
+#define __copy_to_user_inatomic ___copy_to_user
+#define __copy_from_user_inatomic ___copy_from_user

 static inline unsigned long __clear_user(void __user *addr, unsigned long size)
 {

Re: 2.6.28-rc2: Unable to handle kernel paging request at iov_iter_copy_from_user_atomic

[David Miller]

From: Hugh Dickins <hugh@veritas.com>
Date: Sat, 1 Nov 2008 18:59:24 +0000 (GMT)

> Alexander Beregalov reports oops in __bzero() called from
> copy_from_user_fixup() called from iov_iter_copy_from_user_atomic(),
> when running dbench on tmpfs on sparc64: its __copy_from_user_inatomic
> and __copy_to_user_inatomic should be avoiding, not calling, the fixups.
> 
> Signed-off-by: Hugh Dickins <hugh@veritas.com>

This looks great, applied, thanks Hugh.

Re: 2.6.28-rc2: Unable to handle kernel paging request at iov_iter_copy_from_user_atomic

[David Miller]

From: "Alexander Beregalov" <a.beregalov@gmail.com>
Date: Sun, 2 Nov 2008 07:02:40 +0300

> Should we fix also sparc32?

Sparc32 uses a different scheme for all of this stuff.
I don't think your patch will even compile.