Chistoph, I am seeing slabcache corruption.  wb_do_writeback() calls
wb_clear_pending() which can queue up the freeing of the bdi_work. Then
it calls wb_writeback() which can block, resulting in using the bdi_work
after its freed.

------------------------------------------------------------------
  /*
   * If this isn't a data integrity operation, just notify
   * that we have seen this work and we are now starting it.
   */
  if (!test_bit(WS_ONSTACK, &work->state))
         wb_clear_pending(wb, work);

  wrote += wb_writeback(wb, &args);

 /*
  * This is a data integrity writeback, so only do the
  * notification when we have completed the work.
  */
  if (test_bit(WS_ONSTACK, &work->state))
         wb_clear_pending(wb, work);
------------------------------------------------------------------

Can you have one unconditional call to wb_clear_pending() after the
calling wb_writeback()???

Larry


--

[ message continues ]

In fact we should only have a conditional call after wb_writeback.
I've done that already and it's in Jens' tree for 2.6.36:

	http://git.kernel.dk/?p=linux-2.6-block.git;a=commitdiff;h=79338d2a78ab78efdc1698f1309...

--

[ message continues ]

Hi Christoph, 

Is this a problem that was introduced by your writeback patch
series which just got merged for 2.6.35?
Are you going to try to get a fix for this into 2.6.35?

(CCing some people who were interested in your writeback series).
--

[ message continues ]

Jens, I think we need to pull this patch into 2.6.35 still.  While
we could fix the various races with the kfree and wakeup vs ->state
manipulation in a slightly smaller way at least this patch has gotten
lots of testing in linux-next and targeted stress testing.

---end quoted text---
--

[ message continues ]