Re: Race in wb_do_writeback() ???

Re: Race in wb_do_writeback() ???

[Christoph Hellwig]

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

Race in wb_do_writeback() ???

[Larry Woodman]

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

Re: Race in wb_do_writeback() ???

[Brian Bloniarz]

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

Re: Race in wb_do_writeback() ???

[Christoph Hellwig]

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