title: What are the possible causes of "BUG: scheduling while atomic?"
body: <p>There is another process continuously creating files that need processing by this code.
  This code constantly scans the file-system for new files that need processing by comparing the contents of the file-system against a sqlite database that contains the processing results - one record for each file. This process is running at <code>nice -n 19</code> so as not to interfere with the creation of new files by the other process.
  It all works perfectly for a large number (>1k) of files, but then blows up with <code>BUG: scheduling while atomic</code>. 
  According to <a href="https://stackoverflow.com/questions/3537252/how-to-solve-bug-scheduling-while-atomic-swapper-0x00000103-0-cpu0-in-ts">this</a> </p>
  
  <blockquote>
    <p>"Scheduling while atomic" indicates that you've tried to sleep
    somewhere that you shouldn't</p>
  </blockquote>
  
  <p>But the only sleep in the code is like this</p>
  
  <pre><code>void doFiles(void) {
      for (...) { // for each file in the file-system
          ... // check database - do processing if needed
      }
      sleep(1);
  }
  int main(int argc, char *argv[], char *envp[]) {
      while (true) doFiles();
      return -1;
  }
  </code></pre>
  
  <p>The code will hit this sleep after it has checked every file in the file-system against the database. The process needs to be repeated since new files will be added from time to time. There is no multi-threading in this code. Are there other possible causes for "BUG: scheduling while atomic" besides a misplaced sleep?</p>
  
  <p>Edit: additional error output:</p>
  
  <pre><code>note: mirlin[1083] exited with preempt_count 1
  BUG: scheduling while atomic: mirlin/1083/0x40000002
  Modules linked in: g_cdc_ms musb_hdrc nop_usb_xceiv irqk edmak dm365mmap cmemk
  Backtrace: 
  [&lt;c002a5a0&gt;] (dump_backtrace+0x0/0x110) from [&lt;c028e56c&gt;] (dump_stack+0x18/0x1c)
   r6:c1099460 r5:c04ea000 r4:00000000 r3:20000013
  [&lt;c028e554&gt;] (dump_stack+0x0/0x1c) from [&lt;c00337b8&gt;] (__schedule_bug+0x58/0x64)
  [&lt;c0033760&gt;] (__schedule_bug+0x0/0x64) from [&lt;c028e864&gt;] (schedule+0x84/0x378)
   r4:c10992c0 r3:00000000
  [&lt;c028e7e0&gt;] (schedule+0x0/0x378) from [&lt;c0033a80&gt;] (__cond_resched+0x28/0x38)
  [&lt;c0033a58&gt;] (__cond_resched+0x0/0x38) from [&lt;c028ec6c&gt;] (_cond_resched+0x34/0x44)
   r4:00013000 r3:00000001
  [&lt;c028ec38&gt;] (_cond_resched+0x0/0x44) from [&lt;c0082f64&gt;] (unmap_vmas+0x570/0x620)
  [&lt;c00829f4&gt;] (unmap_vmas+0x0/0x620) from [&lt;c0085c10&gt;] (exit_mmap+0xc0/0x1ec)
  [&lt;c0085b50&gt;] (exit_mmap+0x0/0x1ec) from [&lt;c0037610&gt;] (mmput+0x40/0xfc)
   r9:00000001 r8:80000005 r6:c04ea000 r5:00000000 r4:c0427300
  [&lt;c00375d0&gt;] (mmput+0x0/0xfc) from [&lt;c003b5e4&gt;] (exit_mm+0x150/0x158)
   r5:c10992c0 r4:c0427300
  [&lt;c003b494&gt;] (exit_mm+0x0/0x158) from [&lt;c003cd44&gt;] (do_exit+0x198/0x67c)
   r7:c03120d1 r6:c10992c0 r5:0000000b r4:c10992c0
  ...
  </code></pre>