From: Larry Woodman on 29 Jun 2010 16:30 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Brian Bloniarz on 30 Jun 2010 15:20 On 06/29/2010 04:26 PM, Christoph Hellwig wrote: > On Tue, Jun 29, 2010 at 04:28:16PM -0400, Larry Woodman wrote: >> 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()??? > > 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=79338d2a78ab78efdc1698f1309766a039addf9d 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). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on 2 Jul 2010 10:10 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. On Tue, Jun 29, 2010 at 04:26:50PM -0400, Christoph Hellwig wrote: > On Tue, Jun 29, 2010 at 04:28:16PM -0400, Larry Woodman wrote: > > Can you have one unconditional call to wb_clear_pending() after the > > calling wb_writeback()??? > > 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=79338d2a78ab78efdc1698f1309766a039addf9d > ---end quoted text--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: Race in wb_do_writeback() ??? Next: Extended file stat functions |