This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 223134 - write_ldt() race leads to BUG_ON() panic in __kmap_atomic()
write_ldt() race leads to BUG_ON() panic in __kmap_atomic()
Status: CLOSED DUPLICATE of bug 223851
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.4
i386 Linux
medium Severity urgent
: ---
: ---
Assigned To: Jerome Marchand
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-17 17:45 EST by Kurtis D. Rader
Modified: 2007-11-16 20:14 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-13 10:47:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kurtis D. Rader 2007-01-17 17:45:21 EST
Description of problem:

kernel BUG at include/asm/atomic_kmap.h:60!

Version-Release number of selected component (if applicable):

RHEL4.4 kernel 2.6.9-42.0.3.ELsmp i686

How reproducible:

Four panics in two months

Steps to Reproduce:

This is a very subtle, difficult to hit, race. I have dumps from the two most 
recent failures (the first two dumps are no longer available). In both cases we 
have two new, independent, tasks created within one millisecond of each other. 
One task has just gone to sleep in io_schedule(). The other is on-proc 
executing a modify_ldt() syscall. All other CPUs are idle.

The crux of the problem is that when one CPU executes

    smp_call_function(flush_ldt, NULL, 1, 1);

in alloc_ldt() there is no guarantee any of the other CPUs will still be 
running another thread of the same process. But more to the point, any of the 
other CPUs could be in the middle of a write_ldt() -> alloc_ldt() -> 
load_LDT_nolock() -> __kunmap_atomic_type() sequence for a different mm 
context. The resulting recursive load_LDT() call (via the 
IPI flush_ldt() function call) can trigger the assertion in 
__kunmap_atomic_type(). The disabling of preemption doesn't help since the IPI 
can still be delivered.

Additional info:

This is the same as RHbug#160539 (which was against RHEL3).

It appears to me that the preempt_enable()/preempt_disable() in alloc_ldt() 
bounding the "if(reload){" block should be replaced with local_irq_disable()/
_enable() calls. That will both inhibit preemption and prevent the recursive 
load_LDT() call.
Comment 1 Jerome Marchand 2007-02-13 10:47:17 EST

*** This bug has been marked as a duplicate of 223851 ***

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