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
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
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).
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---