在 2008-08-05二的 11:36 +0900,Hisashi Hifumi写道: > >> > >> diff -Nrup linux-2.6.27-rc1.org/fs/jbd/transaction.c > >linux-2.6.27-rc1/fs/jbd/transaction.c > >> --- linux-2.6.27-rc1.org/fs/jbd/transaction.c 2008-07-29 > >19:28:47.000000000 +0900 > >> +++ linux-2.6.27-rc1/fs/jbd/transaction.c 2008-07-29 20:40:12.000000000 +0900 > >> @@ -1764,6 +1764,12 @@ int journal_try_to_free_buffers(journal_ > >> */ > >> if (ret == 0 && (gfp_mask & __GFP_WAIT) && (gfp_mask & __GFP_FS)) { > >> journal_wait_for_transaction_sync_data(journal); > >> + > >> + bh = head; > >> + do { > >> + while (atomic_read(&bh->b_count)) > >> + schedule(); > >> + } while ((bh = bh->b_this_page) != head); > >> ret = try_to_free_buffers(page); > >> } > > > >The loop is problematic. If the scheduler decides to keep running this > >task then we have a busy loop. If this task has realtime policy then > >it might even lock up the kernel. > > > >Perhaps we can use wait_on_page_writeback()? > > > > We cannot use wait_on_page_writeback() to wait for releasing bh ref because > in ext3_ordered_writepage() bh ref is grabbed and released through walk_page_buffers > so between both walk_page_buffers, it remains taking a bh ref even if end_page_writeback > is performed. > ->ext3_ordered_writepage() > walk_page_buffers() <- take a bh ref > block_write_full_page() <- unlock_page > : <- end_page_writeback > : <- race! (dio write->try_to_release_page fails): ---> remains taking a bh ref > walk_page_buffers() <-release a bh ref > Okay, I see the race window, DIO could come in before walk_page_buffers() release the bh reference. So far I don't see a nicer way to sync between background writeout with DIO path yet... Mingming > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html