From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
While running the stress-kernel test suite. An error is printed to /var/log/messages file.

   Debug: sleeping function called from invalid context at   
   include/linux/rwsem.h:43
   in_atomic():0[expected: 0], irqs_disabled():1 
   Call Trace:<ffffffff80132297>{__might_sleep+173}                   
              <ffffffff80138041>{profile_task_exit+33}
              <ffffffff8013928a>{do_exit+34}

 

Version-Release number of selected component (if applicable):
kernel-2.6.9-25.EL

How reproducible:
Sometimes

Steps to Reproduce:
1. Run the stress-kernel RPM on the x86_64 smp.
2. Monitor the /var/log/messages file.

  

Actual Results:  System continues to run normally. The test passes. Trying to figure out if this is an actual problem or it is benign based on the testing.

Expected Results:  Unknown at this time

Additional info:

The Following text is from several emails from Dave Anderson:

  I note also that RHEL3 doesn't make the irqs_disabled() check in 
  its down_read(). But it still seems unusual at best...

  Since profile_task_exit() is unconditionally called upon every do_exit()
  regardless whether profiling is being done, this does seem a bit strange
  that interrupts are disabled:

  void profile_task_exit(struct task_struct * task)
        {
        down_read(&profile_rwsem);
        notifier_call_chain(&task_exit_notifier, 0, task);
        up_read(&profile_rwsem);
        }

        For that matter, *any* time *any* semaphore is invoked for reading,
        the might_sleep() check is invoked:

        static inline void down_read(struct rw_semaphore *sem)
        {
        might_sleep();
        rwsemtrace(sem,"Entering down_read");
        __down_read(sem);
        rwsemtrace(sem,"Leaving down_read");
        }

  So that implies that semaphores should never be taken when
  IRQs are disabled -- although I'm not really clear on what the                 
  ramifications would be if the process does sleep and then goes on to    
  schedule() with IRQ's disabled.  It appears that upon the process switch, it
  will unconditionally do a spin_unlock_irq(rq->lock) upon rescheduling 
  thenext task.  And when it eventually wakes up, it will also do an
  unconditional spin_unlock_irq(rq->lock), so when it returns back
  to do_exit() it will be with IRQ's enabled again.

  But, again, entering do_exit() with IRQs disabled is, at a minimum,
  extremely rare.       

  AFAICT it's harmless, but it would be interesting to know why
  that exiting process has IRQ's disabled, and perhaps what the
  process is.  I don't understand why the back trace only goes
  back as far as do_exit() unless it was called from the x86_64
  entry.S code, which is hard to understand but seems to have
  something to do with kernel threads.  For that, the kernel will
  have to be instrumented, and the symptom reproduced.

  So I don't know.  Jason should probably make the call as to
  whether it's worth the effort to pursue.