Bug 442595 - fast_gup, scheduling with IRQs disabled
Summary: fast_gup, scheduling with IRQs disabled
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: realtime-kernel
Version: 1.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Michal Schmidt
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-15 18:39 UTC by Michal Schmidt
Modified: 2008-05-27 22:03 UTC (History)
3 users (show)

Fixed In Version: 2.6.24.7-47.el5rt
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-05-27 22:03:34 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Michal Schmidt 2008-04-15 18:39:31 UTC
Description of problem:
from gozen's report in https://bugzilla.redhat.com/show_bug.cgi?id=438878#c8 :

There are some issues with -42 , I
can't even get this to be tested. Here are some backtraces from dmesg:

BUG: scheduling with irqs disabled: auditd/0x00000000/12737
caller is rt_spin_lock_slowlock+0xcf/0x14f
Pid: 12737, comm: auditd Not tainted 2.6.24.4-42.el5rt #1
 [<c0633b59>] schedule+0x8e/0x114
 [<c06343ef>] rt_spin_lock_slowlock+0xcf/0x14f
 [<c0634a65>] __rt_spin_lock+0x4c/0x4e
 [<c0634a6f>] rt_spin_lock+0x8/0xa
 [<c04770bf>] page_address+0x4d/0x80
 [<c047730d>] kmap_high+0xf0/0x463
 [<c0403226>] ? __switch_to+0xa3/0x125
 [<c042a515>] ? finish_task_switch+0x29/0xc4
 [<c042c6cd>] ? __wake_up+0x34/0x4f
 [<c0477191>] ? kunmap_high+0x9f/0xa1
 [<c0424140>] ? kunmap+0x52/0x54
 [<c0424180>] kmap+0x3e/0x49
 [<c0421398>] kmap_atomic_func+0x12/0x15
 [<c0423802>] gup_pte_range+0x4f/0x135
 [<c0423a86>] fast_gup+0x19e/0x264
 [<c0449c96>] get_futex_key+0x70/0xa2
 [<c044b1e5>] do_futex+0x383/0xa4b
 [<c048e0bd>] ? do_readv_writev+0x16d/0x178
 [<c044b994>] sys_futex+0xe7/0xfa
 [<c048e5d8>] ? sys_writev+0x58/0x8f
 [<c0404226>] syscall_call+0x7/0xb
 =======================
WARNING: at arch/x86/kernel/smp_32.c:580 native_smp_call_function_mask()
Pid: 13593, comm: automount Not tainted 2.6.24.4-42.el5rt #1
 [<c0419d61>] ? do_flush_tlb_all+0x0/0x3f
 [<c0419f4e>] native_smp_call_function_mask+0x4c/0x12a
 [<c0419d61>] ? do_flush_tlb_all+0x0/0x3f
 [<c0476f78>] ? __set_page_address+0x8b/0x95
 [<c0419d61>] ? do_flush_tlb_all+0x0/0x3f
 [<c0419d61>] ? do_flush_tlb_all+0x0/0x3f
 [<c041b4e5>] smp_call_function+0x1e/0x22
 [<c0434059>] on_each_cpu+0x24/0x5c
 [<c0419c75>] flush_tlb_all+0x1e/0x20
 [<c04774ba>] kmap_high+0x29d/0x463
 [<c0424180>] kmap+0x3e/0x49
 [<c0421398>] kmap_atomic_func+0x12/0x15
 [<c0423802>] gup_pte_range+0x4f/0x135
 [<c047bb7e>] ? handle_mm_fault+0xb7a/0xbb3
 [<c0423a86>] fast_gup+0x19e/0x264
 [<c0449c96>] get_futex_key+0x70/0xa2
 [<c044a302>] futex_wake+0x38/0xbe
 [<c044aee7>] do_futex+0x85/0xa4b
 [<c0493d0a>] ? pipe_write+0x36f/0x3c4
 [<c046fcf8>] ? __pagevec_free+0x17/0x1e
 [<c048d9fb>] ? do_sync_write+0xc5/0x102
 [<c044b994>] sys_futex+0xe7/0xfa
 [<c0468c99>] ? __delayacct_add_tsk+0x205/0x210
 [<c042cdd0>] mm_release+0x84/0x8b
 [<c0430c01>] exit_mm+0x15/0xfd
 [<c0432128>] do_exit+0x213/0x716
 [<c04070a8>] ? do_syscall_trace+0x14c/0x198
 [<c04326bb>] complete_and_exit+0x0/0x16
 [<c0404226>] syscall_call+0x7/0xb
 =======================

Version-Release number of selected component (if applicable):
kernel-rt-2.6.24.4-42.el5rt

How reproducible:
reliably for gozen at least

Steps to Reproduce:
Try to boot the 32 bit kernel.
  
Actual results:
crash with the backtrace

Expected results:
should boot without problems

Additional info:
No problems with x86_64 reported so far. Only 32 bit machines seem to be affected.
Recently futex-fast_gup was merged in kernel-rt and fast_gup can be seen in the
stack trace, so it seems to be the primary suspect.

Comment 1 Gurhan Ozen 2008-04-15 19:30:21 UTC
Ok so a little bit more info..
I tested kernel-rt-2.6.24.4-{39,41,42} with same results. 

However kernel-rt-2.6.24.4-37 seems to boot and run sane though.





Comment 2 Clark Williams 2008-04-23 20:53:18 UTC
is this the bug that requires a HIGHPTE fix?



Comment 3 Michal Schmidt 2008-05-05 20:01:53 UTC
I believe this should be fixed in -47. When Gurhan tests bug 438878, he'll 
know if this one is fixed too.

Comment 4 Gurhan Ozen 2008-05-07 15:17:38 UTC
-47 kernel boots fine. 

Comment 5 Clark Williams 2008-05-27 22:03:34 UTC
closing


Note You need to log in before you can comment on or make changes to this bug.