Hi, > > Ugh! Are you sure? For this path the buffer must be attached (only) to > > the running transaction. But then how the commit code comes to it? > > Somebody would have to even manage to refile the buffer from the > > committing transaction to the running one while the buffer is in wbuf[]. > > Could you check whether someone does __journal_refile_buffer() on your > > marked buffers, please? Or whether we move buffer to BJ_Locked list in > > the write_out_data: loop? Thanks. > > > > > > I added more debug in __journal_refile_buffer() to see if the marked > buffers are getting refiled. I am able to reproduce the problem, > but I don't see any debug including my original prints. (It looks as > if none of my debug code exists) - its really confusing. > > I will keep looking and get back to you. > > I may try Andrew's buffer debug patch - if I get desperate. Ho, hum, I think I see what is hapenning. I think we steal the buffer from commit in journal_dirty_data() (called e.g. from ext3_writepage()). There we also take care of writing out the buffer so it's mostly OK. Except that the commit code still keeps the reference to the buffer in wbuf[]. So the right solution along the lines of your one would be to check that each buffer in wbuf[] is buffer_jbd(), belongs to the right transaction and list and only in that case run submit_bh() on it... Honza -- Jan Kara <jack@xxxxxxx> SuSE CR Labs - 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